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

[John Chittum]

Public bug reported:

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.

** Affects: livecd-rootfs (Ubuntu)
     Importance: Undecided
         Status: New

-- 
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:
  New

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.

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