Open MenacingPerson opened 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)
nor is there an option to skip the ESP check in sbctl
Specifying ESP_PATH
omits the checks in sbctl
.
nor is there an option to skip the ESP check in sbctl
Specifying
ESP_PATH
omits the checks insbctl
.
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.
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)
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
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 incfdisk
(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.