I'm sorry I'm already doing the third thread about this issue but I want this to be isolated in the correct section because it persists after so many reinstalls and updates.
I first discovered this and wrote
here where Eric confirms in post # 6 that this is a reported bug and I'm not the only one. I then again mentioned it after reinstalling a fresh system with an updated Obarun ISO
here. I didn't have access to my Obarun rig for a while so that's why I'm back at this until now.
The expected behavior
After a successful boot to the system almost any Linux distribution will call a virtual console known as tty to provide a means to log in to the system and prompt a user and a password.
The failing behavior
After a successful boot to the system no tty is shown/loaded (I cannot tell whether it's the one or the other) other than the Obarun emergency console tty6 if switched to it.
The completed boot process will just sit there and not give any prompt.
The workaround
Repetitive random keyboard input has to be provided to make the login prompt show up.
The analysis
In the before mentioned thread in
this post I posted full debug boot logs. These somehow made Eric and me think that it might be an issue with entropy at boot time which is a known issue for some display managers. And although this issue is not related to any display manager I still
did install haveged and enable it as a root service just to try it out. This did not have any effect on this bug. It did reduce the needed amount of keystrokes though (so maybe technically it did have an effect...?)
Also the logs made Eric tell me to check my memory and change my root to mount with RO instead of RW which I both did and some passes of Memtest86 showed absolutely no errors (thank god...)
The specs
MSI H97I AC Mini-ITX booting in UEFI mode only
Samsung 850EVO 250GB booting Obarun from EFISTUB without the need for syslinux or any other bootloader
Intel(R) Pentium(R) CPU G3258 @ 3.20GHz
ATI Radeon HD7700 (R7 250X) CAPE VERDE
Kingston DDR3 1333MHz 4GB (x2)
Somehow personally I suspect this is connected to booting with EFISTUB. It would be interesting to see other peoples experiences with this if there are any around here.
There are two possible test cases that come to my mind which I'm honestly not determined to try out since my system is up and running:
- Install Obarun minimal instead with EFISTUB booting and see if it prompts for a login
- Install with syslinux and compare
The following is a list of services enabled for root on this system:
marian@ s6 ~ % sudo s6opts list
current -> Live
previous -> Live.backup
Classic service(s)
consolekit :: up (pid 977) 29417 seconds
dbus :: up (pid 787) 29418 seconds
haveged :: up (pid 785) 29418 seconds
networkmanager :: up (pid 779) 29418 seconds
ntpd :: up (pid 776) 29418 seconds
sddm :: up (pid 778) 29418 seconds
syslogds6 :: up (pid 781) 29418 seconds, ready 29418 seconds
Rc longruns service(s)
s6rc-fdholder :: down (exitcode 0) 29424 seconds, ready 29424 seconds
s6rc-oneshot-runner :: up (pid 236) 29424 seconds, ready 29424 seconds
Rc oneshots service(s)
zfs-oneshot
Rc bundles
All
Update
As a follow up I tried to change to load ConsoleKit on a different unused tty
as outlined in the Arch wiki on ConsoleKit "Consolekit blocks active TTY". For this I added the mentioned code to the root service file:
GNU nano 3.2 /etc/s6-serv/available/classic/consolekit/run
# !/bin/bash
if ! [ -d /run/ConsoleKit ]; then
mkdir -p -m0755 /run/ConsoleKit
fi
exec 2>&1
exec /usr/bin/openvt -c 63 -f -- /usr/bin/console-kit-daemon --no-daemon
This had no effect either. Although I don't know whether I would have to rebuild the s6 database for this to take effect?
Furthermore a link to the current uncaught log can be found
here. Although it doesn't show any unusual. For a far better insight the before mentioned logs with kernel debug enabled are way more complete and could give hints to somebody with profound knowledge (not me).
Also
Arch wiki has a mention on a bug where "when using two or more ATI cards on the same PC" the console might not come up. Although I do not use two GPUs I do have one dedicated ATI card, so I tried both fbcon=map:1 and fbcon=map:' to no avail.
Most reports on similar behavior involve some process in the foreground blocking the console from being loaded. I don't know where to start debugging this though. I repeat: Eric stated that this started to happen after an Obarun update some time ago and that this did not happen before. I will keep looking into this.
In the run file for the root dbus service I read that the service is defined by design to work in the foreground. I do know nothing about dbus, is this supposed to run like this? Could this block the console? Can it run different at all?