Foxboron / sbctl

:computer: :lock: :key: Secure Boot key manager
MIT License
1.47k stars 85 forks source link

ESP not detected in VM, but detected in normal PC #164

Open MenacingPerson opened 2 years ago

MenacingPerson commented 2 years ago

So I've been making this script recently, but sbctl fails with an error:

https://github.com/Samisafool/strap/blob/f3947cb62a15eaa6810f2a87b2d28ca1cbfab7a4/lib/in-chroot.zsh#L32

"failed to find EFI system partition" <- All red color

But bootctl --print-esp-path prints out /boot/efi, and the type of the partition is set to ESP in cfdisk (Like the esp flag being turned on in GPT)

It's also mounted and in /etc/fstab.

The only thing that is probably the cause is being in a chroot, but it wasn't a problem before so idk what the cause is now.

The issue also occurs when omitting the -p flag.

Orochimarufan commented 2 years ago

I just ran into the same issue trying to setup a new install in arch-chroot. This is caused by lsblk relying on udev for the PARTTYPE info, which doesn't work since https://github.com/archlinux/arch-install-scripts/commit/8a5613392686a0f07d8664eecb78895b12bfb3e7 makes /run/udev inaccessible inside the chroot. It will hence not report PARTTYPE information which makes sbctl not detect any ESPs.

root@archiso ~ # lsblk -o NAME,TYPE,PARTTYPE,PARTTYPENAME
NAME      TYPE  PARTTYPE                             PARTTYPENAME
loop0     loop
sda       disk
├─sda1    part  4f68bce3-e8cd-4db1-96e7-fbcaf984b709 Linux root (x86-64)
│ └─crypt crypt
├─sda2    part  c12a7328-f81f-11d2-ba4b-00a0c93ec93b EFI System
sr0       rom
root@archiso ~ # arch-chroot /mnt
[root@archiso /]# lsblk -o NAME,TYPE,PARTTYPE,PARTTYPENAME
NAME      TYPE  PARTTYPE PARTTYPENAME
loop0     loop
sda       disk
├─sda1    part
│ └─crypt crypt
├─sda2    part
sr0       rom

Neither does arch-chroot provide an option to add custom bind mounts nor is there an option to skip the ESP check in sbctl, which makes it currently unusable in archiso/arch-chroot without modifying arch-chroot. Specifying -p should probably skip the ESP detection anyway (or atleast make failure non-fatail)

Foxboron commented 2 years ago

nor is there an option to skip the ESP check in sbctl

Specifying ESP_PATH omits the checks in sbctl.

Orochimarufan commented 2 years ago

nor is there an option to skip the ESP check in sbctl

Specifying ESP_PATH omits the checks in sbctl.

Ah I see I was too quick there. Sorry about that. Is there a reason -p doesn't have the same behavior? I do think it is still an issue if the defaults don't work inside arch-chroot.

Foxboron commented 2 years ago

bundles shouldn't really be used and the feature is half-baked at best as a replacement for the initrd generators that don't support it. So I'd prefer use of dracut or mkinitcpio instead of the bundle feature from sbctl.

I do think it is still an issue if the defaults don't work inside arch-chroot.

arch-chroot isn't a full system. It would probably be better if the homegrown chroot setup was replaced by systemd-nspawn longterm, but I don't think I'll consider it a bug. (It's also a bit besides this issue)

Orochimarufan commented 2 years ago

arch-chroot is (currently) the official way to do installs. FWIW, this issue also affects other things, so it is probably better fixed in arch-chroot: https://github.com/archlinux/arch-install-scripts/issues/24 Regardless, it might be a good idea to have some sort of second-source on ESP detection if lsblk is this easy to confuse.

Perhaps a comment about the readiness of sbctl's bundle feature should be added to https://wiki.archlinux.org/title/Unified_kernel_image#sbctl