On 1/14/2020 7:39 AM, Xi Ruoyao wrote:
On 2020-01-13 13:41 -0700, Alan Feuerbacher wrote:
I'm building the LFS systemd development version, and having some
difficulty deciding how to configure some UEFI things.

I'm using GPT partitions and LVM (Logical Volume Management).
Using LVM for root FS would require an initramfs:


/* snip */

Building an initramfs was the key: I can now boot up using rEFInd.

I still can't boot with grub, though, even though I used some concepts from the rEFInd configure file to modify grub.cfg.

The rEFInd refind.conf is now:

menuentry Linux-LFS-foooo {
    icon EFI/refind/icons/os_linux.png
    volume efi-boot
    loader /vmlinuz-5.4.8-lfs-20200109-systemd
    initrd /initrd.img-5.4.8
    options "ro root=UUID=f7309704-012d-4115-884d-403c6e06a989 

The grub.cfg is now:

 # Begin /boot/grub/grub.cfg
    set default=0
    set timeout=5

    insmod gzio
    insmod part_gpt
    insmod ext2
#    set root=(hd1, gpt1)
#    set root=(hd1, gpt3)
    set root=UUID="08122b74-5c84-4aa5-947e-0d2952db1ecd"
#    set root=(lvm/lfslvm-boot)

    insmod efi_gop
    insmod efi_uga
    insmod font
    if loadfont /boot/grub/fonts/unicode.pf2; then
      loadfont /boot/grub/fonts/unicode.pf2
      set gfxmode=auto
      insmod gfxterm
      set gfxpayload=keep
      terminal_output gfxterm

    menuentry "GNU/Linux, Linux vmlinuz-5.4.8-lfs-20200109-systemd"  {
      linux   /vmlinuz-5.4.8-lfs-20200109-systemd 
root=UUID=f7309704-012d-4115-884d-403c6e06a989 initrd=/initrd.img-5.4.8 ro
      initrd /initrd.img-5.4.8

Here are the relevant bits from blkid on the host system:
[root@localhost Buildscripts-sysd9]# blkid
/dev/sdb1: LABEL_FATBOOT="efi-boot" LABEL="efi-boot" UUID="000A-CAC9"
TYPE="vfat" PARTLABEL="EFI System" PARTUUID="3ae2214c-3cf6-4324-80cf-
/dev/sdb3: UUID="VzWWbo-7FXe-LfrH-vMkK-ewze-y0kQ-vFV395"
TYPE="LVM2_member" PARTLABEL="Linux LVM" PARTUUID="b0ce9087-639c-4487-
/dev/sdb4: UUID="u3BU8P-G1GU-FqWS-sm2q-5xpe-tvUb-68s3zX"
TYPE="LVM2_member" PARTLABEL="Linux LVM" PARTUUID="35e97922-0128-453a-
/dev/mapper/lfslvm-boot: UUID="08122b74-5c84-4aa5-947e-0d2952db1ecd"
/dev/mapper/lfslvm-root: UUID="f7309704-012d-4115-884d-403c6e06a989"

When I try to boot with grub, the grub command interpreter puts out this error 

error: disk '08122b74-5c84...' not found.
error: you need to load the kernel first.

I get a similar error no matter what "set root=..." line I use. For example, when I use:

set root=(hd1, gpt3)

I get:

error: disk '(hd1, ' not found.

I have no clue what " '(hd1, ' " represents.

See grub.cfg above for my attempts.

I've been unable to find relevant information on the Net.

I've had trouble with the "efivarfs" stuff in builds years ago. In
particular, is the line in /etc/fstab necessary or not? I think it is
necessary in my system, partly because efibootmgr (running in the chroot
environment) gives an error complaining about "efivars not defined"
without it. But when I mount an efi directory like so (the stuff below
is all run from the host system, not in the chroot environment):

mkdir -pv /sys/firmware/efi/efivars
mount -t efivars efivars /sys/firmware/efi/efivars

efibootmgr runs ok and seems to give reasonable output.
Old kernels have /sys/firmware/efi/efivars as a part of sysfs.  In newer kernel
builds firmware/efi/efivars is an empty directory in sysfs and efivarfs should
be mounted here.  The old way is CONFIG_EFI_VARS and the new way is
CONFIG_EFIVAR_FS, in kconfig.  We're using the latter, in the hint:

      ## CONFIG_EFI_VARS is not set

          -> Firmware Drivers
            -> EFI (Extensible Firmware Interface) Support
              < > EFI Variable Support via sysfs
              [*] Export efi runtime maps to sysfs

      ## CONFIG_EFIVAR_FS=y/m

           -> File systems
             -> Pseudo filesystems
               [*] EFI Variable filesystem
My .config is the same, except for CONFIG_EFI_VARS which is set. It all appears to be working, but I'm checking out a lot of stuff.
/* snip */

      menuentry "GNU/Linux, Linux vmlinuz-5.4.8-lfs-20200109-systemd"  {
#      linux   /vmlinuz-5.4.8-lfs-20200109-systemd root=/dev/sdb4 ro
        linux   /vmlinuz-5.4.8-lfs-20200109-systemd
root=35e97922-0128-453a-afbf-3f0dd75d98b2 ro
/* snip */

The last Boot entry eventually puts out an error message:

error: disk '3ae2214c-3cf6-4324-80cf-a01741ccbccc' not found
Using UUID as the value of "root" in kernel command line would require an
initramfs.  So in LFS book we just use root=/dev/sd[a-z][1-9].

Yes, as I said above, that worked with rEFInd, but not grub. Any ideas?

I noticed something very strange. I have separate partitions for /boot and /boot/efi. In the Fedora 31 host system, /boot is populated as expected:

(lfs chroot) root:/boot# ll
total 39092
-rw-r--r-- 1 root root  5293922 Jan 14 12:16 System.map-5.4.8
-rw-r--r-- 1 root root   132145 Jan 14 12:17 config-5.4.8
drwxr-xr-x 3 root root     4096 Dec 31  1969 efi
drwxr-xr-x 4 root root     4096 Jan 14 14:13 grub
drwxr-xr-x 2 root root     4096 Jan 14 14:39 grubexp
-rw-r--r-- 1 root root 22604288 Jan 14 11:29 initrd.img-5.4.8
drwx------ 2 root root    16384 Jan  2 14:26 lost+found
-rw-r--r-- 1 root root      511 Jan 10 20:38 refind_linux.conf
-rw-r--r-- 1 root root 11957120 Jan 14 12:16 vmlinuz-5.4.8-lfs-20200109-systemd

But in my newly booted LFS system, nothing but the efi entry is there. What's 
going on?


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?


Reply via email to