Migration script Pi4 - umount: /boot: target is busy.

[KapriQ]

Details:

• Date | Mon Dec 25 15:58:41 CET 2023
• DietPi version | v8.25.1 (MichaIng/beta)
• Image creator |
• Pre-image |
• Hardware | RPi 4 Model B (aarch64) (ID=4)
• Kernel version | Linux pi 6.1.21-v8+ #1642 SMP PREEMPT Mon Apr 3 17:24:16 BST 2023 aarch64 GNU/Linux
• Distro | bookworm (ID=7,RASPBIAN=0)
• Command | umount /boot
• Exit code | 32
• Software title | dietpi-rpi-firmware-migration

Steps to reproduce:

1. ...
2. ...

Expected behaviour:

• ...

Actual behaviour:

• ...

Extra details:

• ...

Additional logs:

umount: /boot: target is busy.
----------------
[FAILED] dietpi-rpi-firmware-migration | Unable to continue, dietpi-rpi-firmware-migration will now terminate.
rm: cannot remove '/tmp/dietpi-rpi-firmware-migration/rootfs/tmp': Device or resource busy
rm: cannot remove '/tmp/dietpi-rpi-firmware-migration/rootfs/run': Device or resource busy
rm: cannot remove '/tmp/dietpi-rpi-firmware-migration/rootfs/proc': Device or resource busy
rm: cannot remove '/tmp/dietpi-rpi-firmware-migration/rootfs/sys': Device or resource busy
rm: cannot remove '/tmp/dietpi-rpi-firmware-migration/rootfs/mnt/dietpi_userdata/docker-data/overlay2/6663d3cec446046df41bb8ea20d244251bf4fed52c0395a9f01518c78fe0a58b/merged': Device or resource busy

[MichaIng]

Probably there was a concurrent cron job execution.

Oh, I see we need to unmount the temporary rootfs mount on failure. Please run umount /tmp/dietpi-rpi-firmware-migration/rootfs && rm -R /tmp/dietpi-rpi-firmware-migration before retrying the script.

If it fails again please check e.g. via htop which other process runs and accesses files in /boot.

[KapriQ]

Gonna try it. And let you know the results. Thx bro.

[KapriQ]

root@pi:~# umount /tmp/dietpi-rpi-firmware-migration/rootfs && rm -R /tmp/dietpi-rpi-firmware-migration umount: /tmp/dietpi-rpi-firmware-migration/rootfs: no mount point specified.
After i run script, the same issue: umount: /boot: target is busy.

So I have tried to add -l to umount. And now it is running. "umount -l ...."

...
Script FINISHED. Gonna try to put SD Card to Pi5- ... ALL DONE! Wroking ...

[MichaIng]

It generally makes sense to check which process actually accesses /boot, before breaking something potentially unintended 😉. Usually nothing but our scripts and APT commands should access this mount point.

However, whatever it was should continue as before after a reboot.

[terminet85]

Check if vmtouch is holding the dietpi.txt

ps aux | grep vmtouch

lsof -c vmtouch

If there is match stop vmtouch

systemctl stop vmtouch.service

[MichaIng]

Oh right, we used vmtouch a long time ago when removing the /boot tmpfs. I'll have a look whether we can identify our build/config and in case remove it. Something like:

[[ -f '/etc/default/vmtouch' ]] && grep -q dietpi /etc/default/vmtouch && G_AGP vmtouch

[MichaIng]

vmtouch is now purged for everyone, if it is this old DietPi-RAMdisk replacement: bdf526f