Latest version 20/04/2026 - Broken?

Troubleshooting
21

I’m not sure if it is or isn’t. on my live system which is an RPI4b I have a pair of disks that were partitioned years ago. (sda and sdc below, sdb beiong the disk with the O/S) The partitions have a PARTUUID which were created when I partitioned the disks and the partitions also have a UUID. It seems odd to me that linux would have two ID mechanisms for a partition.

Previously (pre-dietpi) these disks were mounted using the PARTUUID sda1 being for boot and sda2 being rootfs. The disks are copies and I used to be able to swap between them in case of drive failure. See below..

lsblk -o name,fstype,label,size,ro,type,mountpoint,partuuid,uuid
NAME   FSTYPE LABEL   SIZE RO TYPE MOUNTPOINT     PARTUUID                             UUID
sda                   1.8T  0 disk
├─sda1 vfat   boot    256M  0 part                992de8da-01                          84C6-6EBB
├─sda2 ext4          14.6G  0 part                992de8da-02                          9803377f-ef12-48f5-947a-99e07888e81d
├─sda3                  4K  0 part                992de8da-03
├─sda5 ntfs           1.8T  0 part /mnt/backup    992de8da-05                          146DB48C10EBCB01
└─sda6 ext4          39.1G  0 part                992de8da-06                          447735c7-0ef9-4640-a146-5ad1013f2de4
sdb                 149.1G  0 disk
├─sdb1 vfat           128M  0 part /boot/firmware 29267926-01                          7858-4F7B
└─sdb2 ext4         148.9G  0 part /              29267926-02                          72d8889f-6f05-4326-ba6f-0d65e699f146
sdc                   1.8T  0 disk
├─sdc1 vfat   boot    256M  0 part                c96c3fa2-01                          8D64-2011
├─sdc2 ext4          14.6G  0 part                c96c3fa2-02                          da9c8008-a39a-4229-ab50-726154723bce
├─sdc3                  1K  0 part                c96c3fa2-03
├─sdc5 ntfs   Data    1.8T  0 part /mnt/data      c96c3fa2-05                          C83677EF3677DD3E
└─sdc6 ext4          39.1G  0 part                c96c3fa2-06                          6351b0e7-f874-4051-98c9-f310257fa79a

This system is different because it is a RPI 4b and I simply burned the o/s straight to a USB disk (sdb) and let it run. I think that is why in this case the O/S is using PARTUUID on sdb but dietpi seems to mount the other disk partitions on sda and sdc using UUID, see fstab below..

PHYSICAL DRIVES

#----------------------------------------------------------------
**PARTUUID**=29267926-02 / ext4 noatime,lazytime,rw 0 1
**PARTUUID**=29267926-01 /boot/firmware vfat noatime,lazytime,rw 0 2
**UUID**=C83677EF3677DD3E /mnt/data ntfs noatime,lazytime,rw,permissions,big_writes,noauto,x-systemd.automount
**UUID**=146DB48C10EBCB01 /mnt/backup ntfs noatime,lazytime,rw,permissions,big_writes,noauto,x-systemd.automount

This is why I raised the point in our experimentation with the RPI3b as it uses UUID too.

Though the system is working fine, it just seems inconsistent to me and I may be making something out of nothing. At the very least, it may be just an observation.

22

Things changed over time and it’s different nowadays than it was in past

23

UUID is a filesystem-level feature, and mounting a drive by UUID requires some userland setup, like /dev/disk/by-uuid, or respective probing tools. These conditions are met within an initramfs, but not if the kernel is loaded without initramfs, and needs to mount the rootfs by itself.

PARTUUIDs are a partition-level feature, they exist even if the partition has not been formatted with a filesystem yet, and can be read from the partition table without any filesystem driver or probing tools. The kernel can do this on its own.

Hence, the root= kernel command-line argument should use the PARTUUID of the partition which contains the rootfs, instead of the UUID of the rootfs itself, as long as an initramfs is not guaranteed/expected in the setup.

In older DietPi versions, we for some reason used the PARTUUIDs on RPi as well for rootfs and bootfs entries in /etc/fstab, which was however never needed, and inconsistent (RPi-only). /etc/fstab is used by the init system (systemd), at a stage where udev block device setup has finished, and filesystem drivers can be loaded (as the kernel mounted the rootfs already). The / mount entry causes only a remount, to apply custom mount options, in case, trigger fsck etc (systemctl status systemd-remount-fs).

Practically, /etc/fstab can also use PARTUUIDs, with the same result. But those refer to partitions, not necessarily to filesystems. And even that each partition can practically only contain one filesystem, it makes sense to refer to filesystems explicitly. Also, on MBR partition tables, UUIDs are a lot longer than PARTUUIDs, hence better protect against possible collisions.

However, hence the switch from PARTUUID to UUID in /etc/fstab is expected, and won’t cause any practical difference. It is just an alignment and slight hardening of the exact filesystem reference on RPi systems, introduced with DietPi v10.3.

24

Thank you for that full explanation.I think I now understand.

Every day is a school day! :grinning_face: