iso-scan.sh is racing with udev on newer kernels

[LaszloGombos]

Redhat bug: https://bugzilla.redhat.com/show_bug.cgi?id=2131852
Void Linux: void-linux/void-mklive#294

Seems there is a lot of value in cross referencing bugs and discussing it upstream.

Issue could be related to a change in kernel 5.19+ which leads to a udev race to figure out the label of the ISO.

Intermittent. rd.live.debug makes successful boots possible/more reliable.

CC @FGrose @pvalena @pmensik @0x5c @splate07

[LaszloGombos]

Kind of wondering if some of the "fallbacks" introduced in #2130 would inadvertently would help here as well.

[0x5c]

(from the void-mklive issue)

Please try to autoload modules that this use case needs from the bootloader command line arguments - e.g. "rd.driver.pre= loop,cdrom,isofs, squashfs"
You could also try this patch that debian carries: https://salsa.debian.org/debian/dracut/-/blob/master/debian/patches/udevsettle

Unfortunately, both of these have no effect

[0x5c]

Kind of wondering if some of the "fallbacks" introduced in #2130 would inadvertently would help here as well.

Tried that too just now, no change observed

A patch was made from the PR and applied on top of dracut 59.

[0x5c]

I'm still trying to find where in dmsquash (or other module) is the check for the label happening, I want to see if adding settle/trigger right before that point helps.

[LaszloGombos]

@0x5c poke around modules.d/90dmsquash-live/parse-dmsquash-live.sh or modules.d/90dmsquash-live/dmsquash-live-genrules.sh

[FGrose]

The isofile is set up as a loop device here:
https://github.com/dracutdevs/dracut/blob/master/modules.d/90dmsquash-live/iso-scan.sh#L24
Try the udevadm settle after that.
Since F36 has PTTYPE='dos' and F37 PTTYPE='gpt', you might try
losetup -f -P "/run/initramfs/isoscan/$isofile"
to see if that makes a difference.

[0x5c]

I just now tried 3 images with added udevadm call after losetup, one with udevadm trigger, one with udevadm settle, and one with both. The image that only settled did not boot, but the two others were successful.

It seems to me like trigger is the proper thing to run here. The computer I tested these on is a particularly slow Pentium D machine; I'd expect such a computer to make the race with udev as worse as possible.

--- a/modules.d/90dmsquash-live/iso-scan.sh
+++ b/modules.d/90dmsquash-live/iso-scan.sh
@@ -22,6 +22,8 @@
         mount -t auto -o ro "$dev" "/run/initramfs/isoscan" || continue
         if [ -f "/run/initramfs/isoscan/$isofile" ]; then
             losetup -f "/run/initramfs/isoscan/$isofile"
+            udevadm trigger
             ln -s "$dev" /run/initramfs/isoscandev
             rm -f -- "$job"
             exit 0

[LaszloGombos]

The fips module seems to wait until the path settles - https://github.com/dracutdevs/dracut/blob/master/modules.d/01fips/fips.sh#L32

Perhaps for dmsquash-live this is not necessary as there is a settle call in https://github.com/dracutdevs/dracut/blob/master/modules.d/90dmsquash-live/dmsquash-live-root.sh#L88 . This seems a bit odd place to me to call settle.

@0x5c can you perhaps try this more specific line instead ?

udevadm trigger --action=add > /dev/null 2>&1

Are you planning to upload a PR later or ?

Thank you very much .

[0x5c]

I'm definitely open to making that PR

@0x5c Please do, and let us know if you need help with making the PR.

[0x5c]

Made the PR, #2196