Comment 9 for bug 1899993

I tried to prove whether or not this is a firmware issue or, perhaps, a bug in efibootmgr or curtin's calling of it. I deployed an affected system w/ MAAS w/ init=/bin/bash on the cmdline, and was surprised to see that efibootmgr showed the full expected set of Boot variables. However, if I ssh'd in while MAAS was deploying, efibootmgr was missing some. Turns out this depends on which virtual file system efibootmgr is using.

efivarfs is commonly mounted under /sys/firmware/efi/efivars, and is what efibootmgr prefers:

$ ls /sys/firmware/efi/efivars | grep ^Boot
ls: reading directory '/sys/firmware/efi/efivars': Input/output error
Boot mode select-7683c190-9523-4402-81ff-a11e93dc389c
Boot0000-8be4df61-93ca-11d2-aa0d-00e098032b8c
BootCurrent-8be4df61-93ca-11d2-aa0d-00e098032b8c
BootOptionSupport-8be4df61-93ca-11d2-aa0d-00e098032b8c
BootOrder-8be4df61-93ca-11d2-aa0d-00e098032b8c

If /sys/firmware/efi/efivars is not there, efibootmgr appears to fallback to /sys/firmware/efi/vars which the kernel always exposes:

$ ls /sys/firmware/efi/vars | grep ^Boot
Boot mode select-7683c190-9523-4402-81ff-a11e93dc389c
Boot0000-8be4df61-93ca-11d2-aa0d-00e098032b8c
Boot0001-8be4df61-93ca-11d2-aa0d-00e098032b8c
Boot0003-8be4df61-93ca-11d2-aa0d-00e098032b8c
Boot0004-8be4df61-93ca-11d2-aa0d-00e098032b8c
Boot0005-8be4df61-93ca-11d2-aa0d-00e098032b8c
Boot0006-8be4df61-93ca-11d2-aa0d-00e098032b8c
BootCurrent-8be4df61-93ca-11d2-aa0d-00e098032b8c
BootOptionSupport-8be4df61-93ca-11d2-aa0d-00e098032b8c
BootOrder-8be4df61-93ca-11d2-aa0d-00e098032b8c

With init=/bin/bash, efivarfs is not yet mounted, which is why I see the full set at that point.

So why are these variables not visible in efivarfs? And does the "Input/output error" ls reports have something to do with it?

strace shows that the -EIO is coming from a getdents64() call:

openat(AT_FDCWD, "/sys/firmware/efi/efivars/", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 3
fstat(3, {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
getdents64(3, /* 65 entries */, 32768) = 4800
getdents64(3, 0x5625e2d36510, 32768) = -1 EIO (Input/output error)

I built a 5.10-rc1+ kernel to see if this is maybe a kernel but that was already fixed upstream.
Turns out, the issue goes away there:

$ ls /sys/firmware/efi/efivars | grep ^Boot
Boot mode select-7683c190-9523-4402-81ff-a11e93dc389c
Boot0000-8be4df61-93ca-11d2-aa0d-00e098032b8c
Boot0001-8be4df61-93ca-11d2-aa0d-00e098032b8c
Boot0003-8be4df61-93ca-11d2-aa0d-00e098032b8c
Boot0004-8be4df61-93ca-11d2-aa0d-00e098032b8c
Boot0005-8be4df61-93ca-11d2-aa0d-00e098032b8c
Boot0006-8be4df61-93ca-11d2-aa0d-00e098032b8c
BootCurrent-8be4df61-93ca-11d2-aa0d-00e098032b8c
BootOptionSupport-8be4df61-93ca-11d2-aa0d-00e098032b8c
BootOrder-8be4df61-93ca-11d2-aa0d-00e098032b8c

I'm now trying to determine what changed in the kernel.