EFI: Fails when BootCurrent entry does not exist
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
curtin (Ubuntu) |
Invalid
|
Medium
|
Unassigned | ||
Xenial |
Invalid
|
Undecided
|
Unassigned | ||
Bionic |
Invalid
|
Undecided
|
Unassigned | ||
Focal |
Invalid
|
Undecided
|
Unassigned | ||
Groovy |
Invalid
|
Undecided
|
Unassigned | ||
Hirsute |
Invalid
|
Medium
|
Unassigned | ||
linux (Ubuntu) |
Fix Released
|
Medium
|
dann frazier | ||
Xenial |
Fix Released
|
Medium
|
dann frazier | ||
Bionic |
Fix Released
|
Medium
|
dann frazier | ||
Focal |
Fix Released
|
Medium
|
dann frazier | ||
Groovy |
Fix Released
|
Medium
|
dann frazier | ||
Hirsute |
Fix Released
|
Medium
|
dann frazier |
Bug Description
[Impact]
MAAS installs fail on systems that have EFI Variables that include a "/" in the name.
Split out of bug 1894217.
[Test Case]
Using an OVMF-based VM, create a boot variable with a "/" character. For example:
Shell> setvar FOO/BAR -guid 8ed72b3f-
Then, in Linux:
$ ls /sys/firmware/
ls: reading directory '/sys/firmware/
BootOrder-
ConIn-8be4df61-
ConOut-
ErrOut-
MTC-eb704011-
The Input/output error is the key symptom. See below to see how that percolates up to MAAS install failures.
[Regression Risk]
There's a very tiny chance that someone has written code that depends on an the -EIO error for some reason. It's hard to guess why such a script would do that.
CVE References
Changed in linux (Ubuntu): | |
assignee: | nobody → dann frazier (dannf) |
Changed in linux (Ubuntu Groovy): | |
status: | New → In Progress |
Changed in linux (Ubuntu Focal): | |
assignee: | nobody → dann frazier (dannf) |
status: | New → In Progress |
Changed in linux (Ubuntu Xenial): | |
assignee: | nobody → dann frazier (dannf) |
status: | New → In Progress |
Changed in linux (Ubuntu Groovy): | |
assignee: | nobody → dann frazier (dannf) |
Changed in curtin (Ubuntu Groovy): | |
status: | New → Invalid |
Changed in curtin (Ubuntu Focal): | |
status: | New → Invalid |
Changed in curtin (Ubuntu Bionic): | |
status: | New → Invalid |
Changed in curtin (Ubuntu Xenial): | |
status: | New → Invalid |
Changed in linux (Ubuntu Bionic): | |
assignee: | nobody → dann frazier (dannf) |
status: | New → In Progress |
Changed in linux (Ubuntu Hirsute): | |
status: | Triaged → In Progress |
Changed in linux (Ubuntu Hirsute): | |
importance: | Undecided → Medium |
Changed in linux (Ubuntu Xenial): | |
importance: | Undecided → Medium |
Changed in linux (Ubuntu Bionic): | |
importance: | Undecided → Medium |
Changed in linux (Ubuntu Focal): | |
importance: | Undecided → Medium |
Changed in linux (Ubuntu Groovy): | |
importance: | Undecided → Medium |
Changed in linux (Ubuntu Xenial): | |
status: | In Progress → Fix Committed |
Changed in linux (Ubuntu Bionic): | |
status: | In Progress → Fix Committed |
Changed in linux (Ubuntu Focal): | |
status: | In Progress → Fix Committed |
Changed in linux (Ubuntu Groovy): | |
status: | In Progress → Fix Committed |
description: | updated |
description: | updated |
tags: |
added: verification-done-focal removed: verification-needed-focal |
Looking back at your patch:
Index: curtin-20.1-29-g81144052/curtin/util.py============================================================20.1-29-g81144052.orig/curtin/util.py20.1-29-g81144052/curtin/util.pytarget=None):t(target=target) as in_chroot:subp(['efibootmgr', '-v'], capture=True)"DANNF:\n%s", stdout)r(stdout)
=======
--- curtin-
+++ curtin-
@@ -886,6 +886,7 @@ def get_efibootmgr(
"""
with ChrootableTarge
stdout, _ = in_chroot.
+ LOG.info(
output = parse_efibootmg
return output
And the logs:
Running command ['unshare', '--fork', '--pid', '--', 'chroot', '/tmp/tmp6ha4_iz2/target', 'efibootmgr', '-v'] with allowed return codes [0] (capture=True)0005,0006,0001
DANNF:
BootCurrent: 0003
Timeout: 10 seconds
BootOrder: 0003,0004,
The firmware appears to have no entries at all; but somehow has a BootCurrent and a BootOrder pointing to entries that don't exist. This certainly has to be a firmware bug no?