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:
http://svn.linuxfromscratch.org/hints/trunk/Root_FS_on_RAID+encryption+LVM.txt
/* 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
initrd=/initrd.img-5.4.8"
}
########
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
fi
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-
a01741ccbccc"
/dev/sdb3: UUID="VzWWbo-7FXe-LfrH-vMkK-ewze-y0kQ-vFV395"
TYPE="LVM2_member" PARTLABEL="Linux LVM" PARTUUID="b0ce9087-639c-4487-
97dc-5c947aec3603"
/dev/sdb4: UUID="u3BU8P-G1GU-FqWS-sm2q-5xpe-tvUb-68s3zX"
TYPE="LVM2_member" PARTLABEL="Linux LVM" PARTUUID="35e97922-0128-453a-
afbf-3f0dd75d98b2"
/dev/mapper/lfslvm-boot: UUID="08122b74-5c84-4aa5-947e-0d2952db1ecd"
TYPE="ext4"
/dev/mapper/lfslvm-root: UUID="f7309704-012d-4115-884d-403c6e06a989"
TYPE="ext4"
#########
When I try to boot with grub, the grub command interpreter puts out this error
message:
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
## CONFIG_EFI_RUNTIME_MAP=y
Location:
-> Firmware Drivers
-> EFI (Extensible Firmware Interface) Support
< > EFI Variable Support via sysfs
[*] Export efi runtime maps to sysfs
## CONFIG_EFIVAR_FS=y/m
Location:
-> 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?
Alan
--
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
