firmware update breaks Ubuntu
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Fwupd |
Fix Released
|
Unknown
|
|||
fwupd (Ubuntu) |
Invalid
|
Undecided
|
Unassigned | ||
Xenial |
Invalid
|
Undecided
|
Unassigned | ||
Zesty |
Invalid
|
Undecided
|
Unassigned | ||
Artful |
Invalid
|
Undecided
|
Unassigned | ||
Bionic |
Invalid
|
Undecided
|
Unassigned | ||
fwupdate (Ubuntu) |
Fix Released
|
High
|
Unassigned | ||
Xenial |
Fix Released
|
Undecided
|
Unassigned | ||
Zesty |
Won't Fix
|
Undecided
|
Unassigned | ||
Artful |
Fix Released
|
Undecided
|
Unassigned | ||
Bionic |
Fix Released
|
High
|
Unassigned | ||
fwupdate-signed (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
Xenial |
Fix Released
|
Undecided
|
Unassigned | ||
Zesty |
Won't Fix
|
Undecided
|
Unassigned | ||
Artful |
Fix Released
|
Undecided
|
Unassigned | ||
Bionic |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
[Impact]
* A few users have reported instances of not being able to boot into Ubuntu after a firmware update. This is suspected to be caused by a missing Ubuntu boot entry.
* fwupdate adds an entry for doing the update to the BootOrder, but doesn't remove it. BIOS auto-creation for making boot entries typically depends on the BootOrder being empty.
* This affects all releases of fwupdate since the code to add to BootOrder was
also backported into the Ubuntu 16.04 release of fwupdate (0.5-2ubuntu5)
[Test Case]
* Perform a UEFI BIOS update after installing this package.
* Ensure the system boots and there is no longer a "Linux Firmware Updater" entry
present in the efibootmgr -v output.
[Regression Potential]
* Regressions are possible to manifest if any BIOS depends on the previous behavior.
* The fixes that were backported have been upstream for a few months and no
concerns have been raised upstream from them.
[Other Info]
Two users have reported that fwupd breaks their Ubuntu installation because the "Ubuntu" EFI boot option disappears after an update.
Upstream issue: https:/
affects: | gnome-software → fwupd |
Changed in fwupd: | |
status: | Unknown → New |
Changed in fwupd: | |
status: | New → Unknown |
description: | updated |
Changed in fwupd: | |
status: | Unknown → New |
no longer affects: | ubiquity |
affects: | gnome-software (Ubuntu) → fwupd (Ubuntu) |
Changed in fwupd (Ubuntu Xenial): | |
status: | New → Invalid |
Changed in fwupd (Ubuntu Zesty): | |
status: | New → Invalid |
Changed in fwupd (Ubuntu Artful): | |
status: | New → Invalid |
description: | updated |
Changed in fwupdate (Ubuntu Xenial): | |
status: | New → Triaged |
Changed in fwupdate (Ubuntu Zesty): | |
status: | New → Triaged |
Changed in fwupdate (Ubuntu Artful): | |
status: | New → Triaged |
tags: |
added: verification-done-artful removed: verification-failed-artful |
tags: | removed: verification-failed-zesty |
tags: | added: verification-done-zesty |
tags: |
added: verification-failed-artful removed: verification-done-artful |
Changed in fwupdate-signed (Ubuntu Artful): | |
status: | Fix Committed → In Progress |
Changed in fwupdate (Ubuntu Artful): | |
status: | Fix Committed → In Progress |
Changed in fwupd: | |
status: | New → Fix Released |
Adjusting various tasks for the relevant components. I'm pretty sure this is a regression that is only getting exercised in certain situations of boot entries.
Most notably there was a change was that fwupdate was effectively updated to the "9" release in 0.5-2ubuntu5. This version adds the "Linux Firmware Updater" entry to the boot entry list at the end. If there isn't an "ubuntu" entry earlier on, it's possible that entry is sticking around. The BIOS will only try to build automatic entries if the list was empty, which it's not now.
There are two fixes in upstream for this that may help, but that's predicated on my hypothesis being correct. /github. com/rhboot/ fwupdate/ commit/ 9bebde2c8b8960d 86326f805743edb 9293a6d173 /github. com/rhboot/ fwupdate/ commit/ cd9ea4cbdc93da9 22ce9abc45c7de6 3fe252ecc8
https:/
https:/
My hypothesis can be confirmed by seeing efibootmgr -v output before a failed update. If currently in a failed state, booting a USB key in UEFI mode (without creating a boot entry in BIOS setup) should be able to indicate this too.