race on boot between multiple invocations of grub-editenv
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
grub2 (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
Focal |
Fix Released
|
Undecided
|
Unassigned | ||
Groovy |
Fix Released
|
Undecided
|
Unassigned | ||
Hirsute |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
[Impact]
* two grub systemd units run in parallel.
* ensure they are serialzed.
[Test Case]
* boot on initrdless systems (such as modern/recent public cloud instances)
* observe that grub-initrd-
* observe that both are successful
this is easy to view using
$ sudo journalctl -u grub-initrd-
the output should be in order, not interleaved, with grub-common first and then grub-initrd-
[Where problems could occur]
* The boot is slightly slower as the two jobs are serialized, but they are not computationally intensive and shouldn't affect bootspeed at all, especially on multicore systems where other things are happening in parallel to these.
[Other Info]
* Original bug report
On focal, it appears systemd can run /etc/init.
Jan 08 18:07:15 asr-host systemd[1]: Starting LSB: Record successful boot for GRUB...
Jan 08 18:07:15 asr-host systemd[1]: Starting GRUB failed boot detection...
[..]
Jan 08 18:07:15 asr-host grub-common[1822]: * Recording successful boot for GRUB
[..]
Jan 08 18:07:16 asr-host grub-editenv[1886]: /usr/bin/
Jan 08 18:07:16 asr-host systemd[1]: grub-initrd-
Jan 08 18:07:16 asr-host systemd[1]: grub-initrd-
Jan 08 18:07:16 asr-host systemd[1]: Failed to start GRUB failed boot detection.
Jan 08 18:07:16 asr-host grub-common[1822]: ...done.
Jan 08 18:07:16 asr-host systemd[1]: Started LSB: Record successful boot for GRUB.
Google search for "Failed to start GRUB failed boot detection" throws up a few hits, which suggests this isn't necessarily something to weird about the machine I'm running on:
https:/
ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: grub-common 2.04-1ubuntu26.7
ProcVersionSign
Uname: Linux 5.4.0-59-generic x86_64
ApportVersion: 2.20.11-
Architecture: amd64
CasperMD5CheckR
Date: Fri Jan 8 20:19:42 2021
ProcEnviron:
TERM=screen.
PATH=(custom, no user)
LANG=en_GB.UTF-8
SHELL=/bin/bash
SourcePackage: grub2
UpgradeStatus: Upgraded to focal on 2020-12-23 (15 days ago)
Related branches
- Dimitri John Ledkov: Approve
-
Diff: 52 lines (+30/-0)3 files modifieddebian/changelog (+7/-0)
debian/patches/series (+1/-0)
debian/patches/ubuntu-systemd-service-ordering.patch (+22/-0)
- Ubuntu Core Development Team: Pending requested
-
Diff: 18 lines (+7/-0)1 file modifiedlive-build/ubuntu-cpc/hooks.d/base/disk-image.binary (+7/-0)
tags: | added: rls-hh-incoming |
Changed in grub2 (Ubuntu): | |
status: | Confirmed → Fix Committed |
tags: | removed: rls-hh-incoming |
Changed in grub2 (Ubuntu Focal): | |
status: | New → Fix Committed |
Changed in grub2 (Ubuntu Groovy): | |
status: | New → In Progress |
Changed in grub2 (Ubuntu Focal): | |
status: | Fix Committed → In Progress |
description: | updated |
Fix might well be as simple as adding "After= grub-common. service" to /lib/systemd/ system/ grub-initrd- fallback. service - it's worked for one boot so far, which is obviously not a great test of a race condition :) It does seem to lead to sequential ordering of the two jobs, though:
Jan 08 20:31:26 asr-host systemd[1]: Starting LSB: Record successful boot for GRUB... fallback. service: Succeeded.
Jan 08 20:31:26 asr-host grub-common[1816]: * Recording successful boot for GRUB
Jan 08 20:31:27 asr-host grub-common[1816]: ...done.
Jan 08 20:31:27 asr-host systemd[1]: Started LSB: Record successful boot for GRUB.
Jan 08 20:31:27 asr-host systemd[1]: Starting GRUB failed boot detection...
Jan 08 20:31:27 asr-host systemd[1]: grub-initrd-
Jan 08 20:31:27 asr-host systemd[1]: Finished GRUB failed boot detection.