fix(native): loop unmount until /mnt stack is clean + tmpfs debug log
Post-mortem from lemon-martin's /mnt/install-debug.log showed the real
root cause of the BLKRRPART EBUSY loop: /mnt has a TWO-LEVEL mount
stack on the X1 Nano. init.sh found config.json on /dev/nvme0n1p1
first (USB enumeration slow) and mounted it at /mnt. Then ac-native's
setup_logging() mounted /dev/sda1 on top of /mnt (mount stacking).
/proc/mounts showed only one nvme entry (the underlying one) but the
TOPMOST fs at /mnt was sda1.
force_unmount_disk() grabbed the nvme target from /proc/mounts and
called umount2("/mnt", MNT_DETACH). But umount2 by PATH unmounts the
topmost mount at that path — which was sda1, not nvme. After one
unmount sda1 was gone but nvme was still the topmost at /mnt, still
referenced, still making BLKRRPART return EBUSY.
Fix:
1. force_unmount_disk now LOOPS (up to 16 iterations):
- Re-read /proc/mounts each iteration
- If any entry still matches /dev/<parent>, umount2 its target
- Continue until no matching entries remain
Each iteration pops one layer of the stack.
2. Log the full /proc/mounts (not just filtered) at the start and end
of force_unmount_disk so post-mortem can see the complete picture.
3. DLOG moved from /mnt/install-debug.log to /tmp/install-debug.log.
Tmpfs can't be affected by the nvme repartition, so the log
survives even if /mnt gets fully popped off the stack. After the
install attempt finishes (success or failure), copy the tmpfs log
back to /mnt/install-debug.log for next-boot post-mortem.
This should finally clear the BLKRRPART EBUSY on the X1 Nano and
similar laptops whose init.sh accidentally finds a stale config.json
on an internal ESP during slow USB enumeration.