/boot not mounted by PARTUUID
Creating a bug report/issue
- [x] I have searched the existing open and closed issues
Required Information
- DietPi version | 9.5.1
- Distro version | bookworm 0
- Kernel version |
Linux DietPi 6.1.21-v8+ #1642 SMP PREEMPT Mon Apr 3 17:24:16 BST 2023 aarch64 GNU/Linux - SBC model | RPi 4 Model B (aarch64)
- Power supply used | 5V 5A
- SD card used | none, booting from 2G Kingston USB
Additional Information (if applicable)
- Software title | bare System
- Was the software title installed freshly or updated/migrated?
- Updated from the latest 9.4.? to 9.5.1
- Can this issue be replicated on a fresh installation of DietPi?
- Yes, repeated two times with different USB flash devices
Steps to reproduce
- dd if=DietPi_RPi-ARMv8-Bookworm.img of=/dev/
- mount first partition
- edit config.txt to change resolution to VGA
- edit dietpi-config.txt to enable wifi, disable ethernet, set country code and keyboard to "de"
- boot on rpi4 4gb
- fulfill the init wizard with 9.5.1 update and install vim and git with dietpi-software
- shutdown
- power cycle
- got stuck in ...ifupdown_online... and ...dev-disk-by...
- enter recovery shell by root password
- mount shows /boot is missing, root is fine
-
cat /etc/fstaband compare /boot withblkid- all fine - replace
PARTUUID=f0cf2e93-01with/dev/sda1 - works again
Expected behaviour
mounting by PARTUUID shold by possible
Actual behaviour
mount needs partition device file
Extra details
- rebooted between 12 and 13
- fsck'ed both partitions on an other pc
- have NOT tried to get the problem back after successful boot
Did you check whether the actual PARTUUID of the boot partition matches the one in /etc/fstab?
You can do so from another Linux system, e.g. via
lsblk -no PARTUUID /dev/sda1
There you can also test to mount it with this PARTUUID, like so
mount PARTUUID=9f102456-01 /mnt/mountpoint
Replace the values accordingly.
Please see action item 12 : "cat /etc/fstab and compare /boot with blkid - all fine" blkid also shows the partuuid and they matched up perfectly. That is the reason for the first "Extra detail" - I've meant it should have worked....
I am not sure how it can have this effect, but since it was one change in DietPi v9.5 and you mentioned it is stuck at ifupdown-sonething, can you try this, before reboot:
sed -i '/^[^#].*network-pre.target/s/^/#/' /etc/systemd/system/ifupdown-pre.service.d/dietpi.conf
systemctl daemon-reload
reboot
Respectively remove/comment the two network-pre.target lines in /etc/systemd/system/ifupdown-pre.service.d/dietpi.conf?
And can you rule out that it is a powering/voltage issue? I.e. those are USB sticks only, no 2.5" drives, otherwise have a dedicated PSU? And there are no voltage or I/O errors in kernel logs?
dmesg -l 0,1,2,3
Closing this issue. Feel free to reopen if the problem persists.