Use autoclear for overlay loopback device
authorDavid Woodhouse <dwmw2@infradead.org>
Wed, 17 Jun 2020 18:29:56 +0000 (19:29 +0100)
committerJo-Philipp Wich <jo@mein.io>
Wed, 17 Jun 2020 21:20:48 +0000 (23:20 +0200)
commitd34ea8eb1e12259a315cdef7aa0cd3ceaea68e00
treeb8671c3e1bcc5e6b4857a0cb37940554ce2efcee
parent84269037b75de93bdd4ea75b7f50ba77ba976377
Use autoclear for overlay loopback device

During a sysupgrade on a block-based device, the partition table might
get updated.

The partitions have to be completely unused by the time partx is
invoked, or it fails thus:
partx: /dev/mmcblk1: error deleting partition 3
partx: /dev/mmcblk1: error adding partition 3

That's cosmetic in some cases, but in others where the old root
partition overlaps with the new partition where the config is stored
during the reboot, it causes a sysugprade failure (resulting in the
backup being lost and a completely clean system image).

Although we carefully unmount the root and overlay file systems, the
problem is that the loopback device used for the overlay isn't being
torn down, and it still has a refcount on the root block partition (in
the above case, /dev/mmcblk1p3).

Installing losetup and adding 'losetup -D' to the switch_to_ramfs()
function makes it work nicely. But the better option that doesn't add a
new dependency is to use the autoclear flag when setting up the loop
device, so it goes away automatically when the overlay file system is
unmounted.

To make that work sanely, we have to *not* close the fd right after
configuring it â€” or it'll go away immediately. We could store the fd in
the volume struct and either add destructor method or close it after
performing the mount… but honestly it just seems simpler and saner to
"leak" the fd in the knowledge that it'll get closed when the process
exits in a few milliseconds anyway. We can revisit that if anyone
really feels strongly about it. Dissent is best expressed in 'diff -up'
form.

Signed-off-by: David Woodhouse <dwmw2@infradead.org>
libfstools/rootdisk.c