DietPi
DietPi copied to clipboard
Migration script Pi4 - umount: /boot: target is busy.
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:
- ...
- ...
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
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
.
Gonna try it. And let you know the results. Thx bro.
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 ...
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.
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
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
vmtouch
is now purged for everyone, if it is this old DietPi-RAMdisk replacement: https://github.com/MichaIng/DietPi/commit/bdf526f