I ran the above test:
https://autopkgtest.ubuntu.com/results/autopkgtest-jammy-dannf-test/jammy/amd64/l/livecd-rootfs/20240123_035147_6470b@/log.gz
It does appear that systemd-udevd is trying to scan partitions at the
same time as losetup:
1599s ++ losetup --show -f -P -v binary/boot/disk-uefi.ext4
1600s + loop_device=/dev/loop0
1600s + '[' '!' -b /dev/loop0 ']'
1600s + rootfs_dev_mapper=/dev/loop0p1
1600s + '[' '!' -b /dev/loop0p1 ']'
1600s + echo '/dev/loop0p1 is not a block device'
1600s /dev/loop0p1 is not a block device
1600s + echo '=== dmesg ==='
1600s === dmesg ===
1600s + dmesg -c
1600s [ 986.014824] EXT4-fs (loop0p1): mounted filesystem with ordered data
mode. Opts: (null). Quota mode: none.
1600s [ 992.684380] EXT4-fs (loop0p1): mounted filesystem with ordered data
mode. Opts: (null). Quota mode: none.
1600s [ 1043.171603] loop0: detected capacity change from 0 to 4612096
1600s [ 1043.171924] loop0: p1 p14 p15
1600s [ 1043.190421] loop0: p1 p14 p15
1600s + cat /sys/kernel/debug/tracing/trace
1600s # tracer: function
1600s #
1600s # entries-in-buffer/entries-written: 2/2 #P:4
1600s #
1600s # _-----=> irqs-off
1600s # / _----=> need-resched
1600s # | / _---=> hardirq/softirq
1600s # || / _--=> preempt-depth
1600s # ||| / _-=> migrate-disable
1600s # |||| / delay
1600s # TASK-PID CPU# ||||| TIMESTAMP FUNCTION
1600s # | | | ||||| | |
1600s losetup-50167 [002] ..... 1043.176845: bdev_disk_changed
<-loop_reread_partitions
1600s systemd-udevd-321 [000] ..... 1043.195003: bdev_disk_changed
<-blkdev_get_whole
1600s + echo 0
1600s + ls -l /dev/loop0p1
1600s brw------- 1 root root 259, 3 Jan 23 03:51 /dev/loop0p1
1600s + exit 1
1600s + clean_loops
Maybe we just need something like this?
diff --git a/drivers/block/loop.c b/drivers/block/loop.c
index 48c530b83000e..52fda87f5d674 100644
--- a/drivers/block/loop.c
+++ b/drivers/block/loop.c
@@ -1366,13 +1366,13 @@ static int loop_configure(struct loop_device *lo,
fmode_t mode,
if (partscan)
lo->lo_disk->flags &= ~GENHD_FL_NO_PART_SCAN;
- /* enable and uncork uevent now that we are done */
- dev_set_uevent_suppress(disk_to_dev(lo->lo_disk), 0);
-
loop_global_unlock(lo, is_loop);
if (partscan)
loop_reread_partitions(lo);
+ /* enable and uncork uevent now that we are done */
+ dev_set_uevent_suppress(disk_to_dev(lo->lo_disk), 0);
+
if (!(mode & FMODE_EXCL))
bd_abort_claiming(bdev, loop_configure);
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/2045586
Title:
livecd-rootfs uses losetup -P for theoretically reliable/synchronous
partition setup but it's not reliable in noble
Status in linux package in Ubuntu:
New
Status in livecd-rootfs package in Ubuntu:
New
Status in util-linux package in Ubuntu:
New
Bug description:
In mantic, we migrated livecd-rootfs to use losetup -P instead of
kpartx, with the expectation that this would give us a reliable, race-
free way of loop-mounting partitions from a disk image during image
build.
In noble, we are finding that it is no longer reliable, and in fact
fails rather often.
It is most noticeable with riscv64 builds, which is the architecture
where we most frequently ran into problems before with kpartx. The
first riscv64+generic build in noble where the expected loop partition
device is not available is
https://launchpad.net/~ubuntu-
cdimage/+livefs/ubuntu/noble/cpc/+build/531790
The failure is however not unique to riscv64, and the autopkgtest for
the latest version of livecd-rootfs (24.04.7) - an update that
specifically tries to add more debugging code for this scenario - has
also failed on ppc64el.
https://autopkgtest.ubuntu.com/packages/l/livecd-
rootfs/noble/ppc64el
The first failure happened on November 16. While there has been an
update to the util-linux package in noble, this did not land until
November 23.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2045586/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
