Page 1 of 2
setting hostname breaks X login in porteus4.0 [SOLVED]
Posted: 01 Dec 2019, 08:51
by 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
..
another workaround: boot to text(cheatcode 3) login USER(guest or whatever) and startx ..
setting hostname breaks X login in porteus4.0
Posted: 01 Dec 2019, 08:56
by Blaze
Yep, plus need to install hostname package:
and copy xzm module of hostname to modules folder.
setting hostname breaks X login in porteus4.0
Posted: 01 Dec 2019, 09:45
by ncmprhnsbl
Blaze wrote: ↑01 Dec 2019, 08:56
Yep, plus need to install hostname package:
yes, did that
ncmprhnsbl wrote: ↑01 Dec 2019, 08:51
add package hostname
i extracted the module and added tweaked /etc/rc.d/rc.M to it .. dir2xzm and so on..
setting hostname breaks X login in porteus4.0
Posted: 01 Dec 2019, 09:49
by Blaze
setting hostname breaks X login in porteus4.0
Posted: 01 Dec 2019, 10:41
by 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
setting hostname breaks X login in porteus4.0
Posted: 01 Dec 2019, 19:41
by omero
donald wrote: ↑01 Dec 2019, 10:41
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
setting hostname breaks X login in porteus4.0
Posted: 01 Dec 2019, 20:08
by 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 ....
setting hostname breaks X login in porteus4.0
Posted: 02 Dec 2019, 05:12
by 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 ...
setting hostname breaks X login in porteus4.0
Posted: 02 Dec 2019, 07:03
by 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?
setting hostname breaks X login in porteus4.0
Posted: 02 Dec 2019, 12:11
by ncmprhnsbl
donald wrote: ↑02 Dec 2019, 07:03
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..
setting hostname breaks X login in porteus4.0
Posted: 02 Dec 2019, 20:34
by 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
setting hostname breaks X login in porteus4.0
Posted: 02 Dec 2019, 20:51
by omero
ncmprhnsbl wrote: ↑02 Dec 2019, 12:11
donald wrote: ↑02 Dec 2019, 07:03
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)
setting hostname breaks X login in porteus4.0
Posted: 03 Dec 2019, 02:00
by 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 ..
setting hostname breaks X login in porteus4.0
Posted: 03 Dec 2019, 03:16
by ncmprhnsbl
ncmprhnsbl wrote: ↑03 Dec 2019, 02:00
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
setting hostname breaks X login in porteus4.0
Posted: 03 Dec 2019, 03:52
by omero
ncmprhnsbl wrote: ↑03 Dec 2019, 03:16
ncmprhnsbl wrote: ↑03 Dec 2019, 02:00
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