setting hostname breaks X login in porteus4.0 [SOLVED]

[ncmprhnsbl]

EDIT: solution and patch module here: setting hostname breaks X login in porteus4.0 (Post by ncmprhnsbl #74911)

to reproduce:
do at boot: cheatcode: cliexec=echo~somehostname~>~/etc/HOSTNAME (or if you're using changes just edit HOSTNAME or use rootcopy)
result: X fails to start properly ie blank screen
then: ctrl+alt+backspc > then X starts and hostname is as set
the failed X session(seen by ctrl+alt+F1) seemed to get stuck on :"No Protocol Specified"

the suggested fix:
add package hostname and add section to /etc/rc.d/rc.M :

Code: Select all

# Set the hostname.
if [ -r /etc/HOSTNAME ]; then
  /bin/hostname $(cat /etc/HOSTNAME) &
else
  # fall back on this old default:
  echo "porteus.example.net" > /etc/HOSTNAME
  /bin/hostname porteus.example.net &
fi

not only didn't work, it also brought about the same result as above without changing the hostname ..

another workaround: boot to text(cheatcode 3) login USER(guest or whatever) and startx ..

[Blaze]

Yep, plus need to install hostname package:

Code: Select all

su
toor
getpkg hostname

and copy xzm module of hostname to modules folder.

[ncmprhnsbl]

Yep, plus need to install hostname package:

yes, did that

add package hostname

i extracted the module and added tweaked /etc/rc.d/rc.M to it .. dir2xzm and so on..

[Blaze]

Well, do you tried to compile SLiM again?
https://slackbuilds.org/repository/14.2/system/slim/

[donald]

When you login through a display manager,a MIT-MAGIC-COOKIE-1 authentication cookie
is created and written into your ~/.Xauthority file.

Code: Select all

guest@porteus:~$ xauth list
porteus/unix:0  MIT-MAGIC-COOKIE-1  5e348ef69a99cxxxxxxxxxxxxxxxx

If you change the host name, the X11 client library will no longer find a matching
cookie and the X11 server will reject the unauthenticated connection.

For porteus 4 (you have to save changes)
boot into desktop > run xauth list and copy the cookie string
e.g. 5e348ef69a99cxxxxxxxxxxxxxxxx

edit /etc/HOSTNAME -- put in the hostname you like e.g. kokomiko

now make a matching cookie
(set the hostname "kokomiko" (in this case) and use the same cookie string as before.
Example:

Code: Select all

$ xauth add "kokomiko/unix:0" MIT-MAGIC-COOKIE-1 5e348ef69a99cxxxxxxxxxxxxxxxx

[omero]

When you login through a display manager,a MIT-MAGIC-COOKIE-1 authentication cookie
is created and written into your ~/.Xauthority file.

Code: Select all

guest@porteus:~$ xauth list
porteus/unix:0  MIT-MAGIC-COOKIE-1  5e348ef69a99cxxxxxxxxxxxxxxxx

If you change the host name, the X11 client library will no longer find a matching
cookie and the X11 server will reject the unauthenticated connection.

For porteus 4 (you have to save changes)
boot into desktop > run xauth list and copy the cookie string
e.g. 5e348ef69a99cxxxxxxxxxxxxxxxx

edit /etc/HOSTNAME -- put in the hostname you like e.g. kokomiko

now make a matching cookie
(set the hostname "kokomiko" (in this case) and use the same cookie string as before.
Example:

Code: Select all

$ xauth add "kokomiko/unix:0" MIT-MAGIC-COOKIE-1 5e348ef69a99cxxxxxxxxxxxxxxxx

this is not supposed to be necessary on a sane system>
hostname has nothing to do with X11 and X11 should catch up a sane hostname set for the system after restarting X11

this means> something is surviving the X server restart

[donald]

These settings survive a reboot, so problem (thread title) solved - i think.
And yes, it could be better but as you already know, the hostname package
is missing in 4.0 ....

[ncmprhnsbl]

@donald
hmmm, i've followed your instructions: setup changes, edit HOSTNAME, xauth list ,copy cookie code to xauth add, reboot .... no discernable change..
i'll just add that the DE does eventually start(as it does without doing any of the above), but this is because slim gives up waiting and has another go.. effectively the same as ctrl+alt+backspc ...

[donald]

@ ncmprhnsbl
I'm a bit confused at the moment.
I tried to reproduce the brake of the x login, doing what is posted in the 1st post.

I boot a stock 4.0-XFCE-x86_64,nothing installed except the nvidia driver.
> changed the hostname in /etc/HOSTNAME (nothing else) > reboot > the system
boots straight into the desktop, no hang,no blank screen and the MIT-MAGIC-COOKIE-1
has been created according to the changed hostname.

Is this "hang of the x login" DE specific? If yes, which one?

[ncmprhnsbl]

Is this "hang of the x login" DE specific? If yes, which one?

good question. i did some tests and for me: all DEs except KDE display this behaviour with modified HOSTNAME..
this machine uses the radeon driver. what difference the nvidia driver could make i have no idea.. and what is different with kde may provide some insight..
also tested a custom DE module that uses lxdm that doesn't present this problem, although i believe lxdm crashes and restarts itself in quick succession so might bypass whatever might be happening this way..

[omero]

A missing hostname binary prevents the system initialization scripts to ´properly set hostname´ for the system during the init phase.

Proof? All the /var/log/* logs still are reporting ´porteus´ as their reporting hostname,
even after /etc/HOSTNAME and /etc/hosts have been altered with a ´host-X´ arbitrary hostname,

The /etc/HOSTNAME and /etc/hosts changes only result in a (Xorg/X) long start delay at initdefault=4
The /etc/HOSTNAME and /etc/hosts changes are not causing troubles at initdefault=3, login and startx

The MIT-MAGIC-COOKIE is only relevant to allow the user to connect to a properly running X server on the host (system)

initdefault=4 with an altered HOSTNAME/hosts causes X to not start correctly unless
a) ctl+alt+backspace
b) wait a long delay time (session manager eventually sends sigkill to X and retries)

initdefault=3 with an altered HOSTNAME/hosts
a) user login and startx --> All goes well with no delay whatsoever. X starts immediately and user is dropped into a sane DE/session

Im strongly suspecting we´re having two distinct problems here.
a) hostname binary missing
b) Xserver delay start due to a) but not to
c) MIT-MAGIC-COOKIE *user only*

The system should be able to present the login session manager straight away just at the end of the initialization (cold boot/restart)
The MIT-MAGIC-COOKIE is not something system related in general

[omero]

Is this "hang of the x login" DE specific? If yes, which one?

good question. i did some tests and for me: all DEs except KDE display this behaviour with modified HOSTNAME..
this machine uses the radeon driver. what difference the nvidia driver could make i have no idea.. and what is different with kde may provide some insight..
also tested a custom DE module that uses lxdm that doesn't present this problem, although i believe lxdm crashes and restarts itself in quick succession so might bypass whatever might be happening this way..

any clues in the logs related to lxdm restarting/crashing?
but ... the focus should be on why xorg server is delayed after something as trivial as a change in a couple text files (/etc/HOSTNAME isnt even a standard, its a custom file historically only used by slackware (ok and maybe HP-UX/SOLARIS)... Any clue would be helpful restricting down to where things are going bad (and only if initdefault=4)

[ncmprhnsbl]

if using the nvidia driver is affecting this at all .. this line in nvidia settings>X Server Information: Display Name: <hostname>:0 (where <hostname> is whatever is set as hostname)
i need to compile the nvidia driver for 4.0 to test this ..

[ncmprhnsbl]

if using the nvidia driver is affecting this at all

well.. preliminary test with nvidia driver shows no difference here ie. still getting the hang..
although, now , if i change HOSTNAME the present X session is broken:

Code: Select all

guest@doobie:~$ su
Password: 
root@doobie:/home/guest# echo floobie > /etc/HOSTNAME
root@doobie:/home/guest# xterm
No protocol specified
Warning: This program is an suid-root program or is being run by the root user.
The full text of the error or warning message cannot be safely formatted
in this environment. You may get a more descriptive message by running the
program as a non-root user or by removing the suid bit on the executable.
xterm: Xt error: Can't open display: %s

so cannot open gui apps without crt+alt+backspce ... this does seem to be peculiar to using the nvidia driver... here at least.. in openbox

[omero]

if using the nvidia driver is affecting this at all

well.. preliminary test with nvidia driver shows no difference here ie. still getting the hang..
although, now , if i change HOSTNAME the present X session is broken:

Code: Select all

guest@doobie:~$ su
Password: 
root@doobie:/home/guest# echo floobie > /etc/HOSTNAME
root@doobie:/home/guest# xterm
No protocol specified
Warning: This program is an suid-root program or is being run by the root user.
The full text of the error or warning message cannot be safely formatted
in this environment. You may get a more descriptive message by running the
program as a non-root user or by removing the suid bit on the executable.
xterm: Xt error: Can't open display: %s

so cannot open gui apps without crt+alt+backspce ... this does seem to be peculiar to using the nvidia driver... here at least.. in openbox

No, it is not a problem with drivers or magic-cookies...
You will get the 'no protocol specified error' because apparently after altering /etc/HOSTNAME, the X server cannot talk to himself anymore (even when localhost 127.0.0.1)
My wonder is: why this happens only after altering /etc/HOSTNAME alone?
I did altered both /etc/HOSTNAME and match change in /etc/hosts...

When restarting with initdefault=4 --> problem (blank screen, delay, no specified protocol error in console)
When restarting with initdefault=3 --> no problem (no blank screen, user can login and then startx. A breeze, you are now in a valid X session/Desktop Environment)

This is interesting>

Code: Select all

Warning: This program is an suid-root program or is being run by the root user.
The full text of the error or warning message cannot be safely formatted
in this environment. You may get a more descriptive message by running the
program as a non-root user or by removing the suid bit on the executable.

This is interesting too>

Code: Select all

xterm: Xt error: Can't open display: %s