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
--
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Do not top post on this list.
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
http://en.wikipedia.org/wiki/Posting_style
