Joined: 19 Jun 2003
|Posted: Mon May 27, 2019 7:04 pm Post subject: Gentoo install stops on loading initrd (solved)
|I am attempting to do a fresh install of gentoo on a ThinkPad X1 Gen 6. I am doing it with an encrypted disk using lvm, following the directions here. I have successfully built the system and built the initrd following the directions. Unfortunately, the system goes into grub but then stops at the dreaded "Loading initial ramdisk..." stage.
My grub.cfg is below. As is the .config for my gentoo kernel.
I have tried debugging the problem following the advice in the following threads:
Disabling the ramdisk lines in my grub.cfg did nothing. Nor did any attempt to disable the framebuffer in grub. There is no option in the bios to disable graphical boot. I have confirmed that lvm and cryptsetup made it into the ramdisk but that apparently does me no good. At this point I begin to suspect that it cannot find the ramdisk at all.
EDIT: following some suggestions on Arch Linux forums I added sshd to the default bootup and attempted to log into the machine remotely. However there is no response on the connection which suggests that the kernel does not load at all (my current working hypothesis) or that sshd itself fails.
EDIT2: progress (of a form): I recompiled the kernel with ext4 and my i915 video drivers in the system and forced grub to use text mode booting via the GRUB_GFXPAYLOAD_LINUX=text as recommended here. That allows me to see that the luks header is not being found. So now on to a new problem.
Edit3: Following the advice of this thread I confirmed that some of the crypto packages needed were missing from my kernel but that did not completely solve my problem. It appears that the issue lies in the fact that I am trying to access via uuid but that the /dev/name is not being populated per this thread.
Edit4: Following the above I swapped out the UUID info for the raw dev node of the disk partition and the system prompts me for a password. However when I enter the correct password it throws an error about libgcc_so.1 missing for threads.
Success (after a fashion): Ultimately it appears that I was facing several overlapping issues.
- As noted above the framebuffer was not working independently of everything else. Setting the console output in /etc/default/grub did the trick there.
- The UUID was also a problem due to the lack of udev. While I found some notes about adding a custom udev to the ramdisk none was clear enough to satisfy me. I would still prefer to have /dev/disks/by-uuid mapped in the ramdisk but specifying the raw device node will do.
- The libgcc issue was solved by following this post which notes that include zfs will forces the inclusion of libgcc_so.1 in the ramdisk.
- That finally revealed that the system could still not open the crypto. However running the shell via the ramdisk allowed me to run cryptsetup luksOpen manually with the verbose and debug flags which showed that the userspace could not access the right crypto protocol as discussed here. That was solved by forcably adding all crypto libraries to the kernel.
Now it boots.
Linux, the OS for the obsessive-compulsive speed freak in all of us.