[Bug 2045586] Re: livecd-rootfs uses losetup -P for theoretically reliable/synchronous partition setup but it's not reliable in noble

[Steve Langasek]

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 Ubuntu
Foundations Bugs, which is subscribed to util-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