March 22nd, 2019

XDM/SDDM Slow Startup Followup

As reference previously, recently, the XPS 15 9530 had an issue in startup where the login prompt in the shell was available but XDM/SDDM did not start until several key presses later. Waiting for it to start was a futile effort—once waited over 30 minutes to no avail. A full system reinstall did not help either.

Digging into the dmesg output revealed something interesting:

[83.413293] random: crng init done
[83.413299] random: 7 urandom warning(s) missed due to ratelimiting

It was taking over a minute and a half for random to generate enough entropy. And, this was with the keyboard getting mashed! Apparently, this is a relatively common issue to run into.

Since the XPS 15 9530 has a Haswell core CPU with RDRAND instruction support, an easy way around this is to enable “Trust CPU Vendor” in the kernel config:

CONFIG_RANDOM_TRUST_CPU=y

Now, this is not without consequence. There is concern that Intel’s RDRAND implementation was inappropriately influenced by external parties. An alternative workaround is to install haveged. This has its own issues—it is a software solution to inflate entropy. Finally, on the Gentoo forums, the recommendation is to continue to mash the keyboard until userland applications are updated with to more appropriate entropy requirements.

March 9th, 2019

Fix Linux Boot Halting on “Run /init as init process”

Posted by John Havlik in Guides

In the process of removing the remaining SandForce controller based SSDs from service, the opportunity to completely refresh the Funtoo install on the XPS 15 9530 was taken. Part of this was to try to figure out why recently sddm would not start until a bit of keyboard mashing occurred (literally pushing the enter key a dozen times in a row caused sddm to start, waiting was simply not enough).

The install was fairly painless—most problems tend to be involve getting the proper device drivers compiled into the kernel. Given there was already a known good kernel config, that was used for the building the kernel on the new install. However, on the first boot off of the new SSD, the boot process halted at:

[2.754164] Freeing unused kernel image memory: 1020K
[2.756196] Write protecting the kernel read-only data: 20480k
[2.758698] Freeing unused kernel image memory: 1980K
[2.760892] Freeing unused kernel image memory: 620K
[2.764980] Run /sbin/init as init process

The init system (OpenRC), for some reason, did not actually kick off. Plugging in a USB device confirmed that the kernel itself was still running. Thus, it was not something simple such as the root device being inaccessible (that causes a kernel panic). But, in this state, the system was not usable (no login prompt).

After a bit of sleuthing and stumbling, a solution was found. The following was added to the kernel config:

CONFIG_DEVTMPFS_MOUNT=y

After rebuilding the kernel and rebooting, the system finally booted completely. Still, this is a little unnerving. This machine never needed this setting before. Additionally, I have not needed this setting on any other machine.