kexec can happen before all changes are written to disk

[GeertJohan]

Description

Unmount errors are ignored, giving us this interesting series of logs:

{"time":"2026-07-04T13:12:40.058317894Z","level":"INFO","msg":"unmounting","machineID":"00000000-0000-0000-0000-905a0817af7d","mountpoint":"/rootfs"}
{"time":"2026-07-04T13:12:40.058321911Z","level":"ERROR","msg":"unable to unmount","machineID":"00000000-0000-0000-0000-905a0817af7d","path":"/rootfs","error":"device or resource busy"}
{"time":"2026-07-04T13:12:40.096712484Z","level":"INFO","msg":"report image installation was successful","machineID":"00000000-0000-0000-0000-905a0817af7d"}

After which the machine kexecs and the new filesystem has an empty /etc/fstab and is missing /var/lib mounted.

I have just opened a PR that does a (fairly dirty) quick fix; #185 But I would prefer a more durable fix for this.

We could consider:

• Dropping MNT_FORCE; I dont think that's helping us although it seems to be only relevant for networked file systems.
• Actually have metal-hammer error if unmount fails.
• Find what processes keep the mount busy (fd leak?) and make sure they have completed before calling unmount.

[GeertJohan]

It seems the issue only lived on 0.14.1 (and before?).

How I found out: I created a new branch off master that, instead of sync, tried unmount strictly (not ignoring errors) and was supposed to report any open fd (so I could fix those). However, the issue just vanished. I asked claude to investigate changes between 0.14.1 and master and it pointed to child processes with cwd in /rootfs that were not awaited fully, which was causing the EBUSY. According to Claude:

install-go ran as an exec'd child; its own children (grub probes, dpkg triggers, systemd helpers) were not waited for beyond the direct child - a straggler kept its root inside /rootfs for a few racy seconds after "installation succeeded".

I decided to cleanup the unmount retry mechanism and the 'find which processes are holding fd' debug code, and created a new PR that simply makes unmount strict, so we would get an error instead of rebooting into a filesystem that's incomplete/corrupt.