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.
** Also affects: linux (Ubuntu)
Importance: Undecided
Status: New
** Changed in: linux (Ubuntu)
Status: New => Triaged
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1899993
Title:
EFI: Fails when BootCurrent entry does not exist
Status in curtin package in Ubuntu:
Incomplete
Status in linux package in Ubuntu:
Triaged
Bug description:
Split out of bug 1894217.
We're seeing a situation where curtin fails when the variable
BootCurrent references does not exist.
At boot, efibootmgr -v shows:
BootCurrent: 0003
Timeout: 10 seconds
BootOrder: 0003,0004,0005,0006,0001
Note that there are actually no individual boot entries in this
output. BootCurrent and BootOrder are referencing Boot entries that do
not apepar to exist.
Later, curtin tries to set a new BootOrder that places the value of
BootCurrent at the front. This causes efibootmgr to error out,
apparently escalating to an installation failure:
UEFI efibootmgr output after install:
{'current': '0003', 'timeout': '10 seconds', 'order': ['0000'],
'entries': {'0000': {'name
': 'ubuntu', 'path':
'HD(1,GPT,0937ffdf-628c-4161-8b2f-5920235669c6,0x800,0x100000)/File(\\EFI\\ub
untu\\shimx64.efi)'}}}
Setting currently booted 0003 as the first UEFI loader.
New UEFI boot order: 0003,0000
Running command ['mount', '--bind', '/dev',
'/tmp/tmp6ha4_iz2/target/dev'] with allowed re
turn codes [0] (capture=False)
Running command ['mount', '--bind', '/proc',
'/tmp/tmp6ha4_iz2/target/proc'] with allowed
return codes [0] (capture=False)
Running command ['mount', '--bind', '/run',
'/tmp/tmp6ha4_iz2/target/run'] with allowed re
turn codes [0] (capture=False)
Running command ['mount', '--bind', '/sys',
'/tmp/tmp6ha4_iz2/target/sys'] with allowed re
turn codes [0] (capture=False)
Running command ['mount', '--bind', '/sys/firmware/efi/efivars',
'/tmp/tmp6ha4_iz2/target/
sys/firmware/efi/efivars'] with allowed return codes [0] (capture=False)
Running command ['unshare', '--fork', '--pid', '--', 'chroot',
'/tmp/tmp6ha4_iz2/target',
'efibootmgr', '-o', '0003,0000'] with allowed return codes [0] (capture=False)
Invalid BootOrder order entry value0003
^
efibootmgr: entry 0003 does not exist
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/curtin/+bug/1899993/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
