It’s a 65W 6 port USB power supply with 2 RPIs on it for now
SD card used | (EG: SanDisk ultra) SanDisj Ultra 16Gb
SanDisk 32GB Ultra Fit USB 3.2 Flash Drive Up to 130 MB/s Read
or Seagate 2TB USB Disk
or Western Digital 2TB USB Disk
Additional Information (if applicable)
Software title | Operating system
Was the software title installed freshly or updated/migrated? Brand new install from fresh download
Can this issue be replicated on a fresh installation of DietPi?
← If you sent a “dietpi-bugreport”, please paste the ID here → Don’t know what this means
Bug report ID | echo $G_HW_UUID
Steps to reproduce
Download fresh image (RPI 2/3/4 in this case) released 2026-04-20
Burn to SD Card
Install - minimal installation as I want to recover from a backup… hopefully
Insert a USB disk, I have tried 2 USB HDDs and one USB SSD - All fail in the exact same way
Use Dietpi-drive_manager to select the drive or partition you want to move the rootfs to
Let it complete
Reboot
Expected behaviour
The system should restart using the USB drive as the rootfs
Actual behaviour
68110\] Kernel panic not syncing: UFS: Unable to mount root fs on unknown-block(0,0)
69457\] CPU: 2 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.75+rpt-rpi-08 #1 Debian 1:6.12.75-1+rpt1
170825\] Hardware name: Raspberry Pi 3 Model B Rev 1.2 (DT)
172194\] Call trace:
173531\] dump_backtrace.part.0+0xe0/0x100
174873\] show_stack+0x20/0x40
176188\] dump_stack_lul+0x60/0x80
177505\] dump_stack+0x18/0x28
1788121 panic+0x170/0x370
180109\] mount_root_generic+0x200/0x2c0
181415\] mount_root+0x210/0x258
182714\] prepare_namespace+0x1e0/0x250
184002\] kernel_init_freeable+0x270/0x2a0
1852671 kernel_init+0x28/0x150
186510\] ret_from_fork+0x10/0x20
187743\] SMP: stopping secondary CPUs
1889641 Kernel Offset: 0x1db2c00000 from Oxffffffc080000000
190181\] PHYS_OFFSET: 0x0
191398\] CPU features: 0x00,00000000, 00200000,0200421b
192631\] Memory Limit: none
193860\] \[ end Kernel panic not syncing: UFS: Unable to mount root fs on unknown-block(0,0) \]
Extra details
until recently, I have been using a USB HDD to run the rootfs. This has worked for a few months until I rebooted today after a patch/fix/update.
I have tried 2 USB disks and 1 brand new USB SSD stick and they all fail in the same way - with a kernel panic. I have tried both Armv8 and Armv7 builds and notice they were both released yesterday which was when I did the update
I have a 2TB USB Drive that has an ext4 partition for the O/S and the rest of the disk is an NTFS partition for data (I’m using it as a NAS)
/dev/sda1 - FAT for boot
/dev/sda2 - etx4 for o/s
/dev/sda3 - ntfs for data (historical really but means the drive can be removed and used on Windows)
When you normally use ‘Transfer rootfs’ in drive_manager I think it tries to use the whole disk and not a partition which means I will loose my data.
I would like to be able to get dietpi rootfs into /dev/sda2 and until this last firmware update it all worked very well.
The instructions for the one time program will allow usb boot from my disk but will it want the whole disk for the O/S or can it be pointed at /dev/sda2
Would you mind to test it? Before moving the rootfs, switch to the dev branch:
G_DEV_BRANCH dev
So your guess was going into the right direction. /etc/fstab was updated correctly, but /boot/firmware/cmdline.txt not. Using UUIDs there (instead of PARTUUIDs) would require an initramfs, which we intentionally disable in our RPi images.
EDIT: Skip that, I see it already. Will push a commit.
More importantly:
cat /boot/firmware/cmdline.txt
That does not seem to have been updated. The /etc/fstab entries (on the SD card) are correct, hence also the /dev/sda1 mount. Only the /etc/fstab on the USB drive should have that as rootfs mount. But the kernel still mounted the SD card.
I have done the same and achieved the following result:
root@DietPi:\~# lsblk -o name,fstype,label,size,ro,type,mountpoint,partuuid,uuid
NAME FSTYPE LABEL SIZE RO TYPE MOUNTPOINT PARTUUID UUID
sda 28.7G 0 disk
└─sda1 ext4 28.7G 0 part / c22eb475-99dc-4a80-8dcf-f0d319eb187d d7c6b1f3-b0ed-4178-a948-e5b884572a27
mmcblk0 7.3G 0 disk
├─mmcblk0p1 vfat 128M 0 part /boot/firmware b3155547-01 624C-F49C
└─mmcblk0p2 ext4 7.2G 0 part b3155547-02 1dc35a30-9ee3-44fd-88f5-77c5b564eeca
root@DietPi:\~# cat /etc/fstab
You can use "dietpi-drive_manager" to setup mounts.
tmpfs /tmp tmpfs size=1024M,noatime,lazytime,nodev,nosuid,mode=1777
tmpfs /var/log tmpfs size=50M,noatime,lazytime,nodev,nosuid
UUID=d7c6b1f3-b0ed-4178-a948-e5b884572a27 / ext4 noatime,lazytime,rw 0 1
UUID=624C-F49C /boot/firmware vfat noatime,lazytime,rw 0 2
/var/swap none swap sw
I have a couple of points though.
It is interesting to see that the disk UUID has been mounted as root and not the PARTUUID. I don’t know if that is because I transferred the O/S to the whole disk and not the sda1 parition?
In this setup, what would happen when there is a firmware update.. previously when I was trying to get my now dead Rock64 to work, a firmware update killed the O/S .