[lfs-support] Grub2 won't boot new UEFI LFS build

jacob jacob at cellsheet.me
Mon Oct 31 16:47:58 PDT 2016


> The LFS grub is probably incorrectly built for UEFI.  But unless you
> chainload, only one bootloader (i.e. Arch's grub, unless you
> overwrite it) is likely to be used.  Hmm, I suppose that might not
> be true for UEFI - but first you need to get both your LFS kernel
> and the stanza in Arch's grub.cfg to work.
> 
> Only after that should you think about installing grub from LFS.
> 

I compiled grub2 explicitly as stated in 
http://www.linuxfromscratch.org/hints/downloads/files/lfs-uefi.txt

          ./configure --prefix=/usr  \
             --sbindir=/sbin        \
             --sysconfdir=/etc      \
             --disable-grub-emu-usb \
             --disable-efiemu       \
             --enable-grub-mkfont   \
             --with-platform=efi    \
             --target=x86_64        \
             --program-prefix=""    \
             --with-bootdir="/boot" \
             --with-grubdir="grub" \
             --disable-werror

> 
>> root=UUID=d6788259-f948-4164-ae29-d1b996ffd6d9 rootfstype=ext4 ro
>> }
>> 
> 
> Is the UUID correct for the LFS partition ?

It is unless there's something I'm overlooking. /dev/sdc2 is the root 
for which I installed LFS on according to arch.

The only behavior difference is when booted into the LFS grub, 
(hd2,gpt2) (/dev/sdc2) on arch becomes (hd0,gpt2) (effectively 
/dev/sda2) on LFS because the ordering given from booting off a separate 
drive.
I've also made sure this is the correct root by ls'ing in the grub 
command line on the hard drives to know what drive contains what files, 
while using UUID's to avoid this in fstab and grub2.

$ lsblk
sdc      8:32   0 931.5G  0 disk
├─sdc2   8:34   0 931.3G  0 part /mnt/lfs
└─sdc1   8:33   0   260M  0 part /mnt/lfs/boot/efi

$ ls -l /dev/disk/by-uuid
lrwxrwxrwx 1 root root 10 Oct 29 14:42 04ED-C3D3 -> ../../sdc1
lrwxrwxrwx 1 root root 10 Oct 29 14:42
d6788259-f948-4164-ae29-d1b996ffd6d9 -> ../../sdc2

>> Either way when booting from both entry's regardless of which grub it 
>> fails
>> to boot. linux /boot/vmlinuz-4.7.2-lfs-7.10-systemd
>> root=UUID=d6788259-f948-4164-ae29-d1b996ffd6d9 rootfstype=ext4 ro is 
>> the
>> exact same on the LFS grub entry even, with my latest slight 
>> modifications
>> for testing and revisioning.
> 
> Does the Arch grub give you a graphical screen ?  If so, try adding
> 'nomodeset' to the grub command line.

I tried nomodset actually as a suggestion from a friend of mine in grub, 
but only attempted in the LFS grub (if there's potentially a 
difference).
Afterwards I tried nomodset as well as nouveau.modset=0 (again, only in 
LFS grub). I don't know if this matters or not, but I'm running a GTX 
1080, Pascal based GPU.
I know the firmware binaries for this architecture aren't released in 
nouveau from nvidia as of yet, so I'm a bit curious.

>> > I note you don't care about the recent Dirty COW vulnerability.  But
>> > since it doesn't boot, that kernel version is the least of your problems.
>> > But when it does boot, safest to upgrade to any stable kernel
>> > released after 20th October - my notes say 4.7.9, 4.8.3, 4.4.26 or
>> > later - but for other people, some old stable kernels were also
>> > fixed.
>> >
>> 
>> He probably doesn't know about it.
>> 
> 
> He will do when he reads my reply ;-)

I've known about dirty cow as an avid phoronix reader, though I never 
payed close attention at the time.
I will be updating my kernel source however.

Thanks, Jacob


More information about the lfs-support mailing list