You are not logged in.
So I've been giving myself a heck of a headache here: I am pretty well versed in installing and configuring arch, but I am having serious trouble getting UEFI to work when I have a LUKS encrypted root, formatted btrfs, using a subvolume for root (with other subvolumes for /home, /var, and /usr).
At first I had /dev/sda1 mounted at /boot/efi, and the system would boot into grub but was unable to load the kernel, saying that it could not find the root device (which should have been my cryptouuid device /dev/sda2, which grub.cfg seemed to point to correctly)
So, I moved the mountpoint of /dev/sda1 to /boot, moved the files accordingly, reinstalled grub... and now when I select arch_grub from the boot options on my laptop, it just goes right back to the boot options...
I am pretty sure that btrfs in LUKS is set up correctly, and I'm pretty sure my grub.cfg is being generated correctly, and I'm pretty sure my fstab is correct, so I'm lost as to what to check next. Especially now that /boot has the unencrypted kernel and initramfs...
some code from my live environment:
parted -s /dev/sda p
Model: ATA Samsung SSD 840 (scsi)
Disk /dev/sda: 120GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:
Number Start End Size File system Name Flags
1 1049kB 300MB 299MB fat32
2 300MB 120GB 120GB
root@oitlive /btrfs-root # lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 111.8G 0 disk
├─sda1 8:1 0 285M 0 part /mnt/boot
└─sda2 8:2 0 111.5G 0 part
└─root (dm-1) 254:1 0 111.5G 0 crypt /btrfs-root
sdb 8:16 0 465.8G 0 disk
└─sdb1 8:17 0 465.8G 0 part
root@oitlive /btrfs-root # mount
... relevant bits:
/dev/mapper/root on /mnt type btrfs (rw,noatime,compress=lzo,ssd,discard,space_cache)
/dev/sda1 on /mnt/boot type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)
/dev/mapper/root on /btrfs-root type btrfs (rw,relatime,compress=lzo,ssd,discard,space_cache)changing the boot flag for /dev/sda1 did not matter (and shouldn't for EFI, it does not rely on boot flags)
mkinitcpio.conf snippits
MODULES="vfat btrfs crc32c-intel"
HOOKS="base udev autodetect modconf block encrypt btrfs filesystems keyboard fsck shutdown usr"/etc/fstab
# /dev/mapper/root LABEL=btrfs-root
UUID=d637cb43-cc54-4d67-a8dd-8f8b984881a9 / btrfs rw,noatime,compress=lzo,ssd,discard,space_cache,subvol=__active 0 0
# /dev/sda1
UUID=DE3A-537F /boot vfat rw,relatime,fmask=0022,dmask=0022,iocharset=iso8859-1,shortname=mixed,errors=remount-ro 0 2/boot/efi/EFI/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#
### BEGIN /etc/grub.d/00_header ###
insmod part_gpt
insmod part_msdos
if [ -s $prefix/grubenv ]; then
load_env
fi
set default="0"
if [ x"${feature_menuentry_id}" = xy ]; then
menuentry_id_option="--id"
else
menuentry_id_option=""
fi
export menuentry_id_option
if [ "${prev_saved_entry}" ]; then
set saved_entry="${prev_saved_entry}"
save_env saved_entry
set prev_saved_entry=
save_env prev_saved_entry
set boot_once=true
fi
function savedefault {
if [ -z "${boot_once}" ]; then
saved_entry="${chosen}"
save_env saved_entry
fi
}
function load_video {
if [ x$feature_all_video_module = xy ]; then
insmod all_video
else
insmod efi_gop
insmod efi_uga
insmod ieee1275_fb
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
fi
}
set menu_color_normal=light-blue/black
set menu_color_highlight=light-cyan/blue
if loadfont unicode ; then
set gfxmode=auto
load_video
insmod gfxterm
set locale_dir=$prefix/locale
set lang=en_US
insmod gettext
fi
terminal_input console
terminal_output gfxterm
set timeout=5
### END /etc/grub.d/00_header ###
### BEGIN /etc/grub.d/10_linux ###
menuentry 'Arch GNU/Linux, with Linux core repo kernel' --class arch --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-core repo kernel-true-d637cb43-cc54-4d67-a8dd-8f8b984881a9' {
savedefault
load_video
set gfxpayload=keep
insmod gzio
insmod part_gpt
insmod fat
set root='hd0,gpt1'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt1 --hint-efi=hd0,gpt1 --hint-baremetal=ahci0,gpt1 DE3A-537F
else
search --no-floppy --fs-uuid --set=root DE3A-537F
fi
echo 'Loading Linux core repo kernel ...'
linux /vmlinuz-linux root=UUID=d637cb43-cc54-4d67-a8dd-8f8b984881a9 ro rootflags=subvol=__active cryptdevice=/dev/sda2:root:allow-discard quiet
echo 'Loading initial ramdisk ...'
initrd /initramfs-linux.img
}
menuentry 'Arch GNU/Linux, with Linux core repo kernel (Fallback initramfs)' --class arch --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-core repo kernel-fallback-d637cb43-cc54-4d67-a8dd-8f8b984881a9' {
load_video
set gfxpayload=keep
insmod gzio
insmod part_gpt
insmod fat
set root='hd0,gpt1'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt1 --hint-efi=hd0,gpt1 --hint-baremetal=ahci0,gpt1 DE3A-537F
else
search --no-floppy --fs-uuid --set=root DE3A-537F
fi
echo 'Loading Linux core repo kernel ...'
linux /vmlinuz-linux root=UUID=d637cb43-cc54-4d67-a8dd-8f8b984881a9 ro rootflags=subvol=__active cryptdevice=/dev/sda2:root:allow-discard quiet
echo 'Loading initial ramdisk ...'
initrd /initramfs-linux-fallback.img
}
### END /etc/grub.d/10_linux ###
### BEGIN /etc/grub.d/20_linux_xen ###
### END /etc/grub.d/20_linux_xen ###
### BEGIN /etc/grub.d/20_memtest86+ ###
### END /etc/grub.d/20_memtest86+ ###
### BEGIN /etc/grub.d/30_os-prober ###
### END /etc/grub.d/30_os-prober ###
### BEGIN /etc/grub.d/40_custom ###
# This file provides an easy way to add custom menu entries. Simply type the
# menu entries you want to add after this comment. Be careful not to change
# the 'exec tail' line above.
### END /etc/grub.d/40_custom ###
### BEGIN /etc/grub.d/41_custom ###
if [ -f ${config_directory}/custom.cfg ]; then
source ${config_directory}/custom.cfg
elif [ -z "${config_directory}" -a -f $prefix/custom.cfg ]; then
source $prefix/custom.cfg;
fi
### END /etc/grub.d/41_custom ###I have just noticed the output of this command:
root@oitlive /btrfs-root # btrfs subvolume list -p -u .
ID 257 gen 225 parent 5 top level 5 uuid 09cd8faa-d80b-9145-bc3e-984ed49f6b44 path __active
ID 258 gen 10 parent 257 top level 5 uuid a5d47937-84a9-2b47-a9ac-0f9e67810268 path __active/home
ID 259 gen 218 parent 257 top level 5 uuid a5ab17b6-aac9-a343-ac32-bb9c2bce28f9 path __active/var
ID 260 gen 218 parent 257 top level 5 uuid 85fa4332-93c2-414f-85e5-df00e41d4175 path __active/usrlists a different uuid for __active... but the uuid fstab and grub are referring to is my btrfs-root, which I believe is correct (rather than specifying the UUID of __active). Does anyone know if that is true?
Last edited by jakh (2013-04-24 22:48:49)
Offline
Your EFI partition should be at least 512M but I doubt that is causing the issue.
Last edited by cfr (2013-04-24 00:25:12)
CLI Paste | How To Ask Questions
Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L
Offline
changing the boot flag for /dev/sda1 did not matter (and shouldn't for EFI, it does not rely on boot flags)
That's not entirely true, at least not when referring to what parted calls a "boot flag." When using parted on GPT disks, the "boot flag" actually refers to a partition type code of C12A7328-F81F-11D2-BA4B-00A0C93EC93B -- in other words, the EFI System Partition (ESP). When you remove that flag from a FAT partition, its type code will be changed to EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 -- a Microsoft Basic Data partition. The EFI spec is pretty clear that boot loaders are supposed to appear on ESPs, not on other partition types. That said, most EFI implementations will boot from other partitions, so long as they contain FAT filesystems. I can't promise that this will be true of all EFIs, though, so you'd do well to set the boot flag (using parted or GParted) or change the type code to EF00 (using gdisk; "EF00" is gdisk's stand-in for the much more awkward C12A7328-F81F-11D2-BA4B-00A0C93EC93B) so as to ensure your partitions are set up properly. If you don't, you might make another change that should fix things, but still run into a boot failure because of the improper partition type code, which would make you think that your correct change was ineffective.
So, I moved the mountpoint of /dev/sda1 to /boot, moved the files accordingly, reinstalled grub...
...
/boot/efi/EFI/grub/grub.cfg
If the /boot/efi/EFI/grub/ path is the path after you moved /dev/sda1's mount point to /boot, then it's probably incorrect, and that could be a symptom of the problem. The EFI doesn't know a thing about Linux mount points; it just knows the partition's GUID and a file path within that filesystem. Thus, if you had GRUB installed at /boot/efi/EFI/grub/grub.efi, with /boot/efi being the ESP, and if you then changed the ESP's mount point to /boot, GRUB should now be at /boot/EFI/grub/grub.efi. If you've adjusted the paths so that GRUB remains at /boot/efi/EFI/grub/grub.efi in Linux, then from the ESP's perspective it will have moved -- from EFI\grub\grub.efi to efi\EFI\grub\grub.efi. This would render the NVRAM entry pointing to GRUB inaccurate and useless, and when the EFI tried to run GRUB, it would fail and you'd end up back at an EFI menu.
I can't be sure that this is what's happening, though. For more diagnostic information, please boot a Linux emergency system in EFI mode, mount /dev/sda1 to /mnt (or some other convenient location), and post the output of the following two commands, typed as root:
efibootmgr -v
ls -l `find /mnt -iname "*.efi"`If you mount the ESP somewhere other than /mnt, adjust the second command appropriately.
Offline
So, I moved the mountpoint of /dev/sda1 to /boot, moved the files accordingly, reinstalled grub...
...
/boot/efi/EFI/grub/grub.cfgIf the /boot/efi/EFI/grub/ path is the path after you moved /dev/sda1's mount point to /boot, then it's probably incorrect, and that could be a symptom of the problem. The EFI doesn't know a thing about Linux mount points; it just knows the partition's GUID and a file path within that filesystem. Thus, if you had GRUB installed at /boot/efi/EFI/grub/grub.efi, with /boot/efi being the ESP, and if you then changed the ESP's mount point to /boot, GRUB should now be at /boot/EFI/grub/grub.efi. If you've adjusted the paths so that GRUB remains at /boot/efi/EFI/grub/grub.efi in Linux, then from the ESP's perspective it will have moved -- from EFI\grub\grub.efi to efi\EFI\grub\grub.efi. This would render the NVRAM entry pointing to GRUB inaccurate and useless, and when the EFI tried to run GRUB, it would fail and you'd end up back at an EFI menu.
Okay, this makes sense (and my brain is telling me I knew it or something...).
efibootmgr -v
BootCurrent: 000C
Timeout: 0 seconds
BootOrder: 0019,001A,000A,0006,0007,0008,0009,000B,000C,000D,000E,000F,0010,0011,0012,0013
Boot0000 Setup
Boot0001 Boot Menu
Boot0002 Diagnostic Splash Screen
Boot0003 Startup Interrupt Menu
Boot0004 ME Configuration Menu
Boot0005 Rescue and Recovery
Boot0006* USB CD 030a2400d23878bc820f604d8316c068ee79d25b86701296aa5a7848b66cd49dd3ba6a55
Boot0007* USB FDD 030a2400d23878bc820f604d8316c068ee79d25b6ff015a28830b543a8b8641009461e49
Boot0008* ATAPI CD0 030a2500d23878bc820f604d8316c068ee79d25baea2090adfde214e8b3a5e471856a35401
Boot0009* ATA HDD2 030a2500d23878bc820f604d8316c068ee79d25b91af625956449f41a7b91f4f892ab0f602
Boot000A* ATA HDD0 030a2500d23878bc820f604d8316c068ee79d25b91af625956449f41a7b91f4f892ab0f600
Boot000B* ATA HDD1 030a2500d23878bc820f604d8316c068ee79d25b91af625956449f41a7b91f4f892ab0f601
Boot000C* USB HDD 030a2400d23878bc820f604d8316c068ee79d25b33e821aaaf33bc4789bd419f88c50803
Boot000D* PCI LAN 030a2400d23878bc820f604d8316c068ee79d25b78a84aaf2b2afc4ea79cf5cc8f3d3803
Boot000E* ATAPI CD1 030a2500d23878bc820f604d8316c068ee79d25baea2090adfde214e8b3a5e471856a35403
Boot000F* ATAPI CD2 030a2500d23878bc820f604d8316c068ee79d25baea2090adfde214e8b3a5e471856a35404
Boot0010 Other CD 030a2500d23878bc820f604d8316c068ee79d25baea2090adfde214e8b3a5e471856a35406
Boot0011* ATA HDD3 030a2500d23878bc820f604d8316c068ee79d25b91af625956449f41a7b91f4f892ab0f603
Boot0012* ATA HDD4 030a2500d23878bc820f604d8316c068ee79d25b91af625956449f41a7b91f4f892ab0f604
Boot0013 Other HDD 030a2500d23878bc820f604d8316c068ee79d25b91af625956449f41a7b91f4f892ab0f606
Boot0014* IDER BOOT CDROM ACPI(a0341d0,0)PCI(16,2)ATAPI(0,1,0)
Boot0015* IDER BOOT Floppy ACPI(a0341d0,0)PCI(16,2)ATAPI(0,0,0)
Boot0016* ATA HDD 030a2400d23878bc820f604d8316c068ee79d25b91af625956449f41a7b91f4f892ab0f6
Boot0017* ATAPI CD: 030a2400d23878bc820f604d8316c068ee79d25baea2090adfde214e8b3a5e471856a354
Boot0018* PCI LAN 030a2400d23878bc820f604d8316c068ee79d25b78a84aaf2b2afc4ea79cf5cc8f3d3803
Boot0019* arch_grub HD(1,800,8e800,a4f3614f-1436-4e16-bc3c-7147a5383d31)File(\EFI\arch_grub\grubx64.efi)
Boot001A* Windows Boot Manager HD(1,800,180000,5666ea1d-8759-425b-965a-418e893c2c43)File(\EFI\Microsoft\Boot\bootmgfw.efi)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}...a................Yes, I see here that arch_grub is looking for \EFI\arch_grub_grubx64.efi, but as this part here says:
ls -l `find /mnt -iname "*.efi"` :(
-rwxr-xr-x 1 root root 121856 Apr 23 15:58 /mnt/boot/efi/EFI/arch_grub/grubx64.efi*
-rwxr-xr-x 1 root root 121856 Apr 23 15:58 /mnt/boot/efi/EFI/grub/x86_64-efi/core.efi*
-rwxr-xr-x 1 root root 121856 Apr 23 15:58 /mnt/boot/efi/EFI/grub/x86_64-efi/grub.efi*
-rwxr-xr-x 1 root root 121856 Apr 23 15:59 /mnt/boot/shellx64.efi*the path is \efi\EFI\arch_grub\grubx64.efi
I will try moving the grub files and remaking the grub.cfg, you are probably right...
Edit:
YEP. That was a case of me reading the damned wiki for too long in one sitting :-)
I had typed the grub-install command straight from the wiki with --efi-directory=/boot/efi when it should have read
grub-install --target=x86_64-efi --efi-directory=/boot/ --bootloader-id=arch_grub --recheck --debugReinstalled grub, moved the grub.cfg (didn't need to remake it, no paths it referred to had changed), rebooted and restarted into grub, asked for my passphrase to decrypt /, and I am now looking at a fresh root terminal.
Thank you for the help!
Last edited by jakh (2013-04-24 01:05:24)
Offline
Please edit your original post and tag the subject line [solved]. Thanks.
CLI Paste | How To Ask Questions
Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L
Offline