[rhcos-4.9] buildextend-live: fix /run/media/iso mount flake booting from disk
#2460
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
When booting the RHCOS live ISO image from a USB stick or other disk
device, boot sometimes fails with the following error:
[ 9.410095] systemd[1]: Reached target Initrd Root Device.
[ 9.415226] systemd[1]: Mounting /run/media/iso...
[ 9.498191] ISOFS: Unable to identify CD-ROM format.
[ 9.499552] mount[722]: mount: /run/media/iso: wrong fs type, bad
option, bad superblock on /dev/sda2, missing codepage or helper
program, or other error.
Failed to mount /run/media/iso.
See 'systemctl status run-media-iso.mount' for details.
35coreos-live/live-generator creates run-media-iso.mount, which mounts
the ISO from /dev/disk/by-label/rhcos-<version>. The latter should point
to /dev/sda1, but in this case it's pointing to /dev/sda2, which is
efiboot.img. /dev/sda2 does not have a filesystem label, but because of
systemd/systemd#14408,
60-persistent-storage.rules falls back to using the filesystem label from
/dev/sda (the whole-disk device) when evaluating symlinks for /dev/sda2.
As a result, /dev/sda1 and /dev/sda2 race to own the /dev/disk/by-label
symlink, and if sda2 wins, the mount fails.
CD and virtual CD boot are not affected because CD-ROM devices are not
partitionable. FCOS is not affected because the udev rules on FCOS
include systemd/systemd#14485.
Fix the race by giving efiboot.img its own filesystem label, preventing
the buggy udev rules from reusing the label from the ISO 9660 filesystem.
This seems like a reasonable thing to do anyway (the non-live images
label the ESP as EFI-SYSTEM) and it's free.
Fixes https://bugzilla.redhat.com/show_bug.cgi?id=2007089.
ravanelli
approved these changes
Sep 23, 2021
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When booting the RHCOS live ISO image from a USB stick or other disk device, boot sometimes fails with the following error:
35coreos-live/live-generatorcreatesrun-media-iso.mount, which mounts the ISO from/dev/disk/by-label/rhcos-<version>. The latter should point to/dev/sda1, but in this case it's pointing to/dev/sda2, which isefiboot.img./dev/sda2does not have a filesystem label, but because of systemd/systemd#14408,60-persistent-storage.rulesfalls back to using the filesystem label from/dev/sda(the whole-disk device) when evaluating symlinks for/dev/sda2. As a result,/dev/sda1and/dev/sda2race to own the/dev/disk/by-labelsymlink, and ifsda2wins, the mount fails.CD and virtual CD boot are not affected because CD-ROM devices are not partitionable. FCOS is not affected because the udev rules on FCOS include systemd/systemd#14485.
Fix the race by giving
efiboot.imgits own filesystem label, preventing the buggy udev rules from reusing the label from the ISO 9660 filesystem. This seems like a reasonable thing to do anyway (the non-live images label the ESP asEFI-SYSTEM) and it's free.Fixes https://bugzilla.redhat.com/show_bug.cgi?id=2007089. Backports #2458.