[Bug 1960537] Re: umount_partition e2fsck call fails with ${rootfs_dev_mapper} in use

[Launchpad Bug Tracker]

This bug was fixed in the package livecd-rootfs - 2.755

---------------
livecd-rootfs (2.755) jammy; urgency=medium

  [ Brian Murray ]
  * Add the casper package instead of the lupin-casper package as the
    installer for Windows is a project that is no longer supported and lupin
    is being removed the archive in LP: 1960457.

  [ John Chittum ]
  *  Add sleep due to e2fsck error in umount_partition. LP: #1960537

 -- Brian Murray <brian at ubuntu.com>  Thu, 10 Feb 2022 13:54:42 -0800

** Changed in: livecd-rootfs (Ubuntu Jammy)
       Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to livecd-rootfs in Ubuntu.
https://bugs.launchpad.net/bugs/1960537

Title:
  umount_partition e2fsck call fails with ${rootfs_dev_mapper} in use

Status in livecd-rootfs package in Ubuntu:
  Fix Released
Status in livecd-rootfs source package in Bionic:
  Fix Committed
Status in livecd-rootfs source package in Focal:
  Fix Committed
Status in livecd-rootfs source package in Impish:
  Fix Committed
Status in livecd-rootfs source package in Jammy:
  Fix Released

Bug description:
  When running builds locally or within launchpad, cloud-images are
  starting to fail in many places with the following error:

  ```
  + udevadm settle
  + '[' -n /dev/mapper/loop0p1 -a -b /dev/mapper/loop0p1 ']'
  + '[' -e /etc/mtab ']'
  + e2fsck -y -E discard /dev/mapper/loop0p1
  e2fsck 1.45.5 (07-Jan-2020)
  /dev/mapper/loop0p1 is in use.
  e2fsck: Cannot continue, aborting.
  ```

  This call happens on calls to `umount_disk_image` which then calls
  `umount_partition`.

  `dmsetup info` reports (as an example)

  ```
  Name:              loop3p1
  State:             ACTIVE
  Read Ahead:        256
  Tables present:    LIVE
  Open count:        1
  Event number:      0
  Major, minor:      253, 0
  Number of targets: 1
  UUID: part1-devnode_7:3_Wh5pYvM
  ```

  This shows that there's an open file handle on loop3p1.

  This was first noticed in Jammy builds. After a fair amount of
  debugging by jchittum, no root cause was found. However, a workaround
  was added to the failing CPC hook:

  sleep 30

  Trial and error found that shorter sleeps still failed.

  Due to the ephemeral nature, I [jchittum] have been unable to find a
  root cause. The file handle cleans itself up quickly enough that even
  when I'm on a node watching the build, I haven't been able to track
  down an exact cause due to the handle releasing in a short time.

  [Test case]
  The autopkgtests should continue to pass.
  For focal, the daily image builds should continue to pass.
  For all series, the CPC team will need to confirm that this has not regressed their builds, as they downstream from the livecd-rootfs in the archive using cloud sauce scripts.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/livecd-rootfs/+bug/1960537/+subscriptions