https://launchpad.net/~ubuntu- cdimage/+livefs/ubuntu/noble/cpc/+build/544490 is a log from a build with a new livecd-rootfs that spits out more debugging info on failure.
+ sgdisk binary/boot/disk-uefi.ext4 --print Disk binary/boot/disk-uefi.ext4: 9437184 sectors, 4.5 GiB Sector size (logical): 512 bytes Disk identifier (GUID): CD1DD3AE-E4C8-4C5F-BD64-9236C39B9824 Partition table holds up to 128 entries Main partition table begins at sector 2 and ends at sector 33 First usable sector is 34, last usable sector is 9437150 Partitions will be aligned on 2-sector boundaries Total free space is 0 sectors (0 bytes) Number Start (sector) End (sector) Size Code Name 1 235520 9437150 4.4 GiB 8300 12 227328 235519 4.0 MiB 8300 CIDATA 13 34 2081 1024.0 KiB FFFF loader1 14 2082 10239 4.0 MiB FFFF loader2 15 10240 227327 106.0 MiB EF00 + mount_image binary/boot/disk-uefi.ext4 1 + trap clean_loops EXIT + backing_img=binary/boot/disk-uefi.ext4 + local rootpart=1 ++ losetup --show -f -P -v binary/boot/disk-uefi.ext4 + loop_device=/dev/loop5 + '[' '!' -b /dev/loop5 ']' + rootfs_dev_mapper=/dev/loop5p1 + '[' '!' -b /dev/loop5p1 ']' + echo '/dev/loop5p1 is not a block device' /dev/loop5p1 is not a block device + ls -l /dev/loop5p1 /dev/loop5p12 brw------- 1 root root 259, 2 Dec 9 04:16 /dev/loop5p1 brw------- 1 root root 259, 3 Dec 9 04:16 /dev/loop5p12 + exit 1 This clearly shows that: - there are 5 partitions on the image being passed to losetup - after losetup exits, /dev/loop5p1 is not present - after this check fails, an ls of /dev/loop5p* shows devices present for two of the partitions - including /dev/loop5p1 that we were looking for in the first place - but not all 5. So this definitely means we have a race after calling losetup -P. Is this the expected behavior from the kernel? How do we make this race-free? -- 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
