sbctl
sbctl copied to clipboard
Foxboron
`sbctl verify` returns `failed to find EFI system partition` even though it's there
Hi,
sbctl verify returns failed to find EFI system partition even though it's there. Unmounting then mounting makes it work. There were no glaring issues with /efi (could read, write, no problem).
# cat /etc/fstab
UUID=F2D4-5BC4 /boot vfat rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro 0 2
UUID=F2D4-5BC4 /efi vfat rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro 0 2
Quick console session:
Console session
% findmnt /boot
TARGET SOURCE FSTYPE OPTIONS
/boot /dev/nvme0n1p1 vfat rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro
% findmnt /efi
TARGET SOURCE FSTYPE OPTIONS
/efi /dev/nvme0n1p1 vfat rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro
# sbctl verify
failed to find EFI system partition
% tree /efi
/efi
????????? EFI
??????? ????????? Boot
??????? ??????? ????????? BOOTX64.EFI
??????? ????????? Linux
??????? ??????? ????????? archlinux-linux-clear-fallback.efi
??????? ??????? ????????? archlinux-linux-clear.efi
??????? ??????? ????????? archlinux-linux-lts-fallback.efi
??????? ??????? ????????? archlinux-linux-lts.efi
??????? ????????? memtest86
??????? ??????? ????????? Benchmark
??????? ??????? ????????? MemTest86-20221014-153419.log
??????? ??????? ????????? MemTest86-20230105-174348.log
??????? ??????? ????????? MemTest86.log
??????? ??????? ????????? blacklist.cfg
??????? ??????? ????????? memtestx64.efi
??????? ??????? ????????? mt86.png
??????? ??????? ????????? unifont.bin
??????? ????????? systemd
??????? ????????? systemd-bootx64.efi
????????? amd-ucode.img
????????? f7522b4f7bc64ecb9c928c6a3f7e481e
????????? initramfs-linux-clear-fallback.img
????????? initramfs-linux-clear.img
????????? initramfs-linux-lts-fallback.img
????????? initramfs-linux-lts.img
????????? key
????????? loader
??????? ????????? entries
??????? ??????? ????????? memtest86-efi.conf
??????? ??????? ????????? toxo-clear-efi.conf.disabled
??????? ??????? ????????? toxo-clear.conf
??????? ??????? ????????? toxo-lts.conf
??????? ??????? ????????? toxo-lts.conf_20221014T151752Z
??????? ????????? entries.srel
??????? ????????? loader.conf
??????? ????????? random-seed
????????? vmlinuz-linux-clear
????????? vmlinuz-linux-lts
strace: https://gist.githubusercontent.com/moviuro/8e5f2553fca9e2612b11cb7dd5341eef/raw/df8e25b8cc3259c6e87abc3cc2c3c0ed81519c36/strace%2520sbctl%2520verify%2520(failed).txt
remount and rerun
# umount /efi
# mount /efi # doesn't work with mount -o remount /efi
# sbctl verify
Verifying file database and EFI images in /efi...
??? /boot/EFI/Linux/archlinux-linux-clear.efi is signed
??? /boot/EFI/Linux/archlinux-linux-lts.efi is signed
??? /efi/EFI/Boot/BOOTX64.EFI is not signed
??? /efi/EFI/Linux/archlinux-linux-clear-fallback.efi is not signed
??? /efi/EFI/Linux/archlinux-linux-lts-fallback.efi is not signed
??? /efi/EFI/memtest86/memtestx64.efi is not signed
??? /efi/EFI/systemd/systemd-bootx64.efi is not signed
??? /efi/vmlinuz-linux-clear is not signed
??? /efi/vmlinuz-linux-lts is not signed
strace: https://gist.githubusercontent.com/moviuro/2315b27c313a22d2b41018559482b27e/raw/809d6cb2b5d2de6171910cedc498ec061713ffe6/strace%2520sbctl%2520verify%2520(success).txt
Whats the output of lsblk --json --output PARTTYPE,MOUNTPOINT,PTTYPE,FSTYPE when sbctl fails?
And why are you mounting the esp on /boot and /efi?
{
"blockdevices": [
{
"parttype": null,
"mountpoint": "[SWAP]",
"pttype": null,
"fstype": null
},{
"parttype": null,
"mountpoint": "/mnt/bbb76c63-e4ac-4e39-8897-a120c5d30686",
"pttype": null,
"fstype": "btrfs"
},{
"parttype": null,
"mountpoint": null,
"pttype": "gpt",
"fstype": null
},{
"parttype": "c12a7328-f81f-11d2-ba4b-00a0c93ec93b",
"mountpoint": "/mnt/F2D4-5BC4",
"pttype": "gpt",
"fstype": "vfat"
},{
"parttype": "0fc63daf-8483-4772-8e79-3d69d8477de4",
"mountpoint": null,
"pttype": "gpt",
"fstype": "crypto_LUKS"
}
]
}
I'm mounting on /boot & /efi because sbctl would fail to find EFI system partition with only /boot mounted when I set it up (which sounds a lot like the same issue we're discussing now).
# gdisk -l /dev/nvme0n1
GPT fdisk (gdisk) version 1.0.9.1
Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: present
Found valid GPT with protective MBR; using GPT.
Disk /dev/nvme0n1: 488378646 sectors, 1.8 TiB
Model: Sabrent Rocket 4.0 2TB
Sector size (logical/physical): 4096/4096 bytes
Disk identifier (GUID): ...
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 5
First usable sector is 6, last usable sector is 488378640
Partitions will be aligned on 256-sector boundaries
Total free space is 250 sectors (1000.0 KiB)
Number Start (sector) End (sector) Size Code Name
1 256 262399 1024.0 MiB EF00 EFI system partition
2 262400 488378640 1.8 TiB 8300 Linux filesystem
{
"parttype": "c12a7328-f81f-11d2-ba4b-00a0c93ec93b",
"mountpoint": "/mnt/F2D4-5BC4",
"pttype": "gpt",
"fstype": "vfat"
}
Why is it mounted to /mnt/F2D4-5BC4? When sbctl tries to find valid mount points it assumes the fstype to be vfat and pttype to be gpt with parttype c12a7328-f81f-11d2-ba4b-00a0c93ec93b, on one of three mountpoints: /boot, /efi and /boot/efi.
So this ESP setup is quite weird?
So this ESP setup is quite weird?
No, I'm just mounting my disks where they make sense. /mnt/F2D4-5BC4 because it's its UUID, and to /boot because, well, it's the boot partition. See also /mnt/bbb76c63-e4ac-4e39-8897-a120c5d30686 which is also my root partition.
Why are you doing this?
From what I can tell this is mounted last and confuses sbctl as I think lsblk only lists the last mountpoint pr partition.
Why are you doing this?
Because why not? All local mountpoints are available in /mnt, makes it easier to travel to the "real" root of e.g. btrfs devices, etc.
sbctl should instead try to pull info from /boot, /efi, /boot/efi, check that they are mountpoints; and if they are, that they satisfy the set constraints (vfat, parttype, etc.).
sbctl should instead try to pull info from /boot, /efi, /boot/efi, check that they are mountpoints; and if they are, that they satisfy the set constraints (vfat, parttype, etc.).
Not possible as we use lsblk and it acts on blockdevices and not mountpoints. I'm not re-writing it to support a setup where people mount the ESP three places on a system.
Whats the output of lsblk --json --output PARTTYPE,MOUNTPOINT,PTTYPE,FSTYPE,MOUNTPOINTS?
# lsblk --json --output PARTTYPE,MOUNTPOINT,PTTYPE,FSTYPE,MOUNTPOINTS
{
"blockdevices": [
{
"parttype": null,
"mountpoint": "[SWAP]",
"pttype": null,
"fstype": null,
"mountpoints": [
"[SWAP]"
]
},{
"parttype": null,
"mountpoint": "/mnt/bbb76c63-e4ac-4e39-8897-a120c5d30686",
"pttype": null,
"fstype": "btrfs",
"mountpoints": [
"/mnt/bbb76c63-e4ac-4e39-8897-a120c5d30686", "/"
]
},{
"parttype": null,
"mountpoint": null,
"pttype": "gpt",
"fstype": null,
"mountpoints": [
null
]
},{
"parttype": "c12a7328-f81f-11d2-ba4b-00a0c93ec93b",
"mountpoint": "/mnt/F2D4-5BC4",
"pttype": "gpt",
"fstype": "vfat",
"mountpoints": [
"/mnt/F2D4-5BC4", "/efi", "/boot"
]
},{
"parttype": "0fc63daf-8483-4772-8e79-3d69d8477de4",
"mountpoint": null,
"pttype": "gpt",
"fstype": "crypto_LUKS",
"mountpoints": [
null
]
}
]
}
Looks promising!
Yes, so also check if it's present in MOUNTPOINTS then. That should be nice solution.
I have the same issue, however when running lsblk --json --output PARTTYPE,MOUNTPOINT,PTTYPE,FSTYPE my partitions show null as pttype and fstype and I have no idea how to fix them :
{
"blockdevices": [
{
"parttype": null,
"mountpoint": "[SWAP]",
"pttype": null,
"fstype": null
},{
"parttype": null,
"mountpoint": "/",
"pttype": null,
"fstype": null
},{
"parttype": null,
"mountpoint": "/home",
"pttype": null,
"fstype": null
},{
"parttype": null,
"mountpoint": null,
"pttype": null,
"fstype": null
},{
"parttype": null,
"mountpoint": "/efi",
"pttype": null,
"fstype": null
},{
"parttype": null,
"mountpoint": null,
"pttype": null,
"fstype": null
}
]
}
Please note that /efi is a regular partition, while the others are logical volumes on an encrypted partition. I don't know if that makes a difference.
If lsblk is reporting null I suspect udev has some issues. This isn't a sbctl issue, strictly speaking. You can set ESP_PATH manually.
What next steps could be taken by the part of the community that is experiencing this (such as me), to debug this and get the issue fixed (likely upstream in udev or lsblk)? Has it been reported upstream yet?
(yes I'm experiencing the null values, setting the mentioned environment variable silenced the error, and I was able to set up secure boot :tada:)
I think this has nothing to do with udev, it's just that the partition type is not set in the partition table. The GUID partition type is check in sbctl.go https://github.com/Foxboron/sbctl/blob/d3e9315907de0568f175f1ca9a6c617009a8323d/sbctl.go#L96
So if you're using a GPT disk, vfat on the esp (nothing you can really choose otherwise) and the correct partition type is set, it should work.
If you want to set that partition type GUID, you can use
sfdisk --part-type <disk with esp> <partition number of esp> "c12a7328-f81f-11d2-ba4b-00a0c93ec93b"
which will change the partition type. Be sure to unmount the ESP before running that command.
After that command, it should also not show null anymore in the lsblk output
I ran sfdisk --part-type /dev/nvme0n1 1 and the result was the (uppercased) "number" you specified.
At least in my case, the partition type is correct, and not the cause of the problem.
On a side note - not sure my system would have been able to boot if it wasn't correct in the first place. Secure boot is working for me (though the command still isn't without specifying the partition).
Different question: could it be that the code is doing a case-sensitive string comparison when it shouldn't be?
My problem appears to be lsblk -f doesn't show any UUIDs, and the JSON output has the null values in its output.
But I'm in the arch-chroot of a new install. All the other sbctl commands appear to have succeeded, and it's just sbctl verify which is failing. I'm installing a UKI and it's signed (installing the kernel ran the kernel-install hooks, and everything looked successful). When I exit the arch-chroot, lsblk -f shows the UUIDs, but there's not enough space in airootfs to install sbctl and all of its dependencies.
When I originally did this, I had the variable set to EFI_PATH=/efi, not ESP_PATH=/efi. Setting the latter allowed sbctl verify to work. I noticed the files installed by systemd-boot aren't yet signed, so I'm going to sign them, but I'm thinking being in the arch-chroot may be a clue to what's going on.
@tblancher Are you using udev?
I believe I am, but I didn't do anything to set it up. This was in the Arch chroot of a new install, so it's whatever the standard boot of the Arch ISO does automatically.
Artix at least (which is based on Arch, if you aren't familiar) uses udev by default. Seeing as moving to udev from something else isn't part of the Arch -> Artix system migration guide, I'd assume that Arch uses udev by default as well.
I'm also having a similar issue, lsblk is returning null for parttype, pttype, and fstype despite being set as a efi partition. Is there a way to specify a esp location?
See the manpage.
https://github.com/Foxboron/sbctl/blob/master/docs/sbctl.8.txt#L389
even with esp path set in environment variables I still seem to get the failed to find EFI system partition error
SHELL=/usr/bin/bash
COLORTERM=truecolor
HYPRLAND_CMD=Hyprland
XDG_BACKEND=wayland
KITTY_PID=4783
XCURSOR_SIZE=24
EDITOR=nano
XDG_SEAT=seat0
PWD=/home/neddey
LOGNAME=neddey
XDG_SESSION_DESKTOP=hyprland
QT_QPA_PLATFORMTHEME=qt6ct
XDG_SESSION_TYPE=wayland
KITTY_PUBLIC_KEY=1:kd}^YQjK@8;Q+B|=V;gM4)xq{XnFCMd+-ihaFM`R
MOTD_SHOWN=pam
HOME=/home/neddey
LANG=C
_JAVA_AWT_WM_NONREPARENTING=1
XDG_CURRENT_DESKTOP=Hyprland
WAYLAND_DISPLAY=wayland-1
KITTY_WINDOW_ID=1
ESP_PATH=/efi
XDG_SESSION_CLASS=user
TERMINFO=/usr/lib/kitty/terminfo
TERM=xterm-kitty
USER=neddey
HYPRLAND_INSTANCE_SIGNATURE=360ede79d124ffdeebbe8401f1ac4bc0dbec2c91_1713174123
VISUAL=nano
DISPLAY=:0
SHLVL=1
MOZ_ENABLE_WAYLAND=1
XDG_VTNR=2
XDG_SESSION_ID=1
LC_CTYPE=C.UTF-8
XDG_RUNTIME_DIR=/run/user/1000
DEBUGINFOD_URLS=https://debuginfod.artixlinux.org
XDG_DATA_DIRS=/home/neddey/.local/share/flatpak/exports/share:/var/lib/flatpak/exports/share:/usr/local/share:/usr/share
PATH=/sbin:/bin:/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/var/lib/flatpak/exports/bin:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl
MAIL=/var/spool/mail/neddey
KITTY_INSTALLATION_DIR=/usr/lib/kitty
_=/sbin/env
pttype is still referenced but it shows up on the physical disk, and it doesn't seem to be propagated to individual partitions.
you can check that with sudo lsblk --json --output-all on artix
test data from my framework laptop
{
"blockdevices": [
{
"alignment": 0,
"id-link": null,
"id": null,
"disc-aln": 0,
"dax": false,
"disc-gran": "4K",
"disk-seq": 3,
"disc-max": "2T",
"disc-zero": false,
"fsavail": null,
"fsroots": [
null
],
"fssize": null,
"fstype": "swap",
"fsused": null,
"fsuse%": null,
"fsver": null,
"group": "disk",
"hctl": null,
"hotplug": false,
"kname": "zram0",
"label": "zram0",
"log-sec": 4096,
"maj:min": "253:0",
"maj": "253",
"min": "0",
"min-io": 4096,
"mode": "brw-rw----",
"model": null,
"mq": "1",
"name": "zram0",
"opt-io": 4096,
"owner": "root",
"partflags": null,
"partlabel": null,
"partn": null,
"parttype": null,
"parttypename": null,
"partuuid": null,
"path": "/dev/zram0",
"phy-sec": 4096,
"pkname": null,
"pttype": null,
"ptuuid": null,
"ra": 128,
"rand": false,
"rev": null,
"rm": false,
"ro": false,
"rota": false,
"rq-size": null,
"sched": null,
"serial": null,
"size": "29,3G",
"start": null,
"state": null,
"subsystems": "block",
"mountpoint": "[SWAP]",
"mountpoints": [
"[SWAP]"
],
"tran": null,
"type": "disk",
"uuid": "redacted",
"vendor": null,
"wsame": "0B",
"wwn": null,
"zoned": "none",
"zone-sz": "0B",
"zone-wgran": "0B",
"zone-app": "0B",
"zone-nr": 0,
"zone-omax": 0,
"zone-amax": 0
},{
"alignment": 0,
"id-link": null,
"id": null,
"disc-aln": 0,
"dax": false,
"disc-gran": "512B",
"disk-seq": 1,
"disc-max": "2T",
"disc-zero": false,
"fsavail": null,
"fsroots": [
null
],
"fssize": null,
"fstype": null,
"fsused": null,
"fsuse%": null,
"fsver": null,
"group": "disk",
"hctl": null,
"hotplug": false,
"kname": "nvme0n1",
"label": null,
"log-sec": 512,
"maj:min": "259:0",
"maj": "259",
"min": "0",
"min-io": 512,
"mode": "brw-rw----",
"model": "WD_BLACK SN850X 2000GB ",
"mq": " 16",
"name": "nvme0n1",
"opt-io": 0,
"owner": "root",
"partflags": null,
"partlabel": null,
"partn": null,
"parttype": null,
"parttypename": null,
"partuuid": null,
"path": "/dev/nvme0n1",
"phy-sec": 512,
"pkname": null,
"pttype": "gpt",
"ptuuid": "this works too but i'm not risking it",
"ra": 128,
"rand": false,
"rev": null,
"rm": false,
"ro": false,
"rota": false,
"rq-size": 1023,
"sched": "none",
"serial": "there was a serial here and i had to redact it sorry",
"size": "1,8T",
"start": null,
"state": "live",
"subsystems": "block:nvme:pci",
"mountpoint": null,
"mountpoints": [
null
],
"tran": "nvme",
"type": "disk",
"uuid": null,
"vendor": null,
"wsame": "0B",
"wwn": null,
"zoned": "none",
"zone-sz": "0B",
"zone-wgran": "0B",
"zone-app": "0B",
"zone-nr": 0,
"zone-omax": 0,
"zone-amax": 0,
"children": [
{
"alignment": 0,
"id-link": null,
"id": null,
"disc-aln": 0,
"dax": false,
"disc-gran": "512B",
"disk-seq": 1,
"disc-max": "2T",
"disc-zero": false,
"fsavail": "313,1M",
"fsroots": [
"/"
],
"fssize": "511M",
"fstype": "vfat",
"fsused": "197,9M",
"fsuse%": "39%",
"fsver": null,
"group": "disk",
"hctl": null,
"hotplug": false,
"kname": "nvme0n1p1",
"label": null,
"log-sec": 512,
"maj:min": "259:1",
"maj": "259",
"min": "1",
"min-io": 512,
"mode": "brw-rw----",
"model": null,
"mq": " 16",
"name": "nvme0n1p1",
"opt-io": 0,
"owner": "root",
"partflags": null,
"partlabel": null,
"partn": 1,
"parttype": "c12a7328-f81f-11d2-ba4b-00a0c93ec93b",
"parttypename": null,
"partuuid": "this works but again redacting",
"path": "/dev/nvme0n1p1",
"phy-sec": 512,
"pkname": "nvme0n1",
"pttype": null,
"ptuuid": null,
"ra": 128,
"rand": false,
"rev": null,
"rm": false,
"ro": false,
"rota": false,
"rq-size": 1023,
"sched": "none",
"serial": null,
"size": "512M",
"start": 2048,
"state": null,
"subsystems": "block:nvme:pci",
"mountpoint": "/boot",
"mountpoints": [
"/boot"
],
"tran": "nvme",
"type": "part",
"uuid": "028A-00E7",
"vendor": null,
"wsame": "0B",
"wwn": null,
"zoned": "none",
"zone-sz": "0B",
"zone-wgran": "0B",
"zone-app": "0B",
"zone-nr": 0,
"zone-omax": 0,
"zone-amax": 0
},{
"alignment": 0,
"id-link": null,
"id": null,
"disc-aln": 0,
"dax": false,
"disc-gran": "512B",
"disk-seq": 1,
"disc-max": "2T",
"disc-zero": false,
"fsavail": null,
"fsroots": [
null
],
"fssize": null,
"fstype": "crypto_LUKS",
"fsused": null,
"fsuse%": null,
"fsver": null,
"group": "disk",
"hctl": null,
"hotplug": false,
"kname": "nvme0n1p2",
"label": null,
"log-sec": 512,
"maj:min": "259:2",
"maj": "259",
"min": "2",
"min-io": 512,
"mode": "brw-rw----",
"model": null,
"mq": " 16",
"name": "nvme0n1p2",
"opt-io": 0,
"owner": "root",
"partflags": null,
"partlabel": null,
"partn": 2,
"parttype": "0fc63daf-8483-4772-8e79-3d69d8477de4",
"parttypename": null,
"partuuid": "uh redacted",
"path": "/dev/nvme0n1p2",
"phy-sec": 512,
"pkname": "nvme0n1",
"pttype": null,
"ptuuid": null,
"ra": 128,
"rand": false,
"rev": null,
"rm": false,
"ro": false,
"rota": false,
"rq-size": 1023,
"sched": "none",
"serial": null,
"size": "1,8T",
"start": 1050624,
"state": null,
"subsystems": "block:nvme:pci",
"mountpoint": null,
"mountpoints": [
null
],
"tran": "nvme",
"type": "part",
"uuid": "redacted",
"vendor": null,
"wsame": "0B",
"wwn": null,
"zoned": "none",
"zone-sz": "0B",
"zone-wgran": "0B",
"zone-app": "0B",
"zone-nr": 0,
"zone-omax": 0,
"zone-amax": 0,
"children": [
{
"alignment": 0,
"id-link": null,
"id": null,
"disc-aln": 0,
"dax": false,
"disc-gran": "512B",
"disk-seq": 2,
"disc-max": "0B",
"disc-zero": false,
"fsavail": "1,6T",
"fsroots": [
"/@snapshots", "/@tmp", "/@var", "/@opt", "/@root", "/@home", "/@"
],
"fssize": "1,8T",
"fstype": "btrfs",
"fsused": "219,5G",
"fsuse%": "12%",
"fsver": null,
"group": "disk",
"hctl": null,
"hotplug": false,
"kname": "dm-0",
"label": null,
"log-sec": 512,
"maj:min": "254:0",
"maj": "254",
"min": "0",
"min-io": 512,
"mode": "brw-rw----",
"model": null,
"mq": "1",
"name": "root",
"opt-io": 0,
"owner": "root",
"partflags": null,
"partlabel": null,
"partn": null,
"parttype": null,
"parttypename": null,
"partuuid": null,
"path": "/dev/mapper/root",
"phy-sec": 512,
"pkname": "nvme0n1p2",
"pttype": null,
"ptuuid": null,
"ra": 128,
"rand": false,
"rev": null,
"rm": false,
"ro": false,
"rota": false,
"rq-size": null,
"sched": null,
"serial": null,
"size": "1,8T",
"start": null,
"state": "running",
"subsystems": "block",
"mountpoint": "/.snapshots",
"mountpoints": [
"/.snapshots", "/tmp", "/var", "/opt", "/root", "/home", "/"
],
"tran": null,
"type": "crypt",
"uuid": "redacted",
"vendor": null,
"wsame": "0B",
"wwn": null,
"zoned": "none",
"zone-sz": "0B",
"zone-wgran": "0B",
"zone-app": "0B",
"zone-nr": 0,
"zone-omax": 0,
"zone-amax": 0
}
]
}
]
}
]
}
.blockdevices[].pttype gets you the gpt partition type, then you can iterate on children using .blockdevices[].children[].parttype for the part type and .blockdevices[].children[].mountpoint or [...].mountpoints[0] to get the mountpoint.
it should be trivial to do this in a future release, I suppose
@Foxboron
oh by the way you can also use
# lsblk --tree --json --output PARTTYPE,MOUNTPOINT,PTTYPE,FSTYPE
and it would still be enough
Please test the proposed fix and give the complete, and unredacted output, of lsblk --tree --json --output PARTTYPE,MOUNTPOINT,PTTYPE,FSTYPE,MOUNTPOINTS if it still fails.
https://github.com/Foxboron/sbctl/pull/358