1

By default the root parameter in /boot/cmdline.txt is set with PARTUUID. For example:

dwc_otg.lpm_enable=0 console=serial0,115200 console=tty1 root=PARTUUID=ae4da847-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait

The PARTUUID=ae4da847-02 is just a numerated PTUUID=ae4da847 Disk identifier (also named Volume ID) as you can see with:

rpi ~$ sudo blkid /dev/mmcblk0
/dev/mmcblk0: PTUUID="ae4da847" PTTYPE="dos"

Raspian is distributed with disk-images containing all the same Disk identifer, so we spread the same identifer for different storages all over the world. Doesn't matter?

No, we get problems as reported here. Disk management tools like fdisk or parted correct this silently to a unique Disk identifier when used. But then Raspbian fails to boot because it has it's old and now wrong numerated Disk identifer PARTUUID in it's root parameter. In the opposite it seems that the UUID of a partition never changes as long as the partition exists, even with duplicates on different disks. It's unique on the disk.

~$ sudo blkid /dev/mmcblk0p2
/dev/mmcblk0p2: LABEL="rootfs" UUID="72bfc10d-73ec-4d9e-a54a-1cc507ee7ed2" TYPE="ext4" PARTUUID="ae4da847-02"

To fix this problem I tried to use the UUID as root parameter in /boot/cmdline.txt but Raspbian does not boot with this.

Is there any other usable partition identifier for the root parameter in boot/cmdline.txt than PARTUUID?

Ingo
  • 40,606
  • 15
  • 76
  • 189
  • AFAIK this is not possible. The bootloader just doesn't have the grunt to search UUID. It is simple to change PARTUUID, or indeed go back to the old `/dev/mmcblko2`. I am not sure what the "problem" is; it is true that some partitioning tools change Volume ID, but that is only a problem if you do not ensure it is used consistently in `cmdline.txt` and `fstab`. – Milliways Jan 25 '18 at 03:42
  • @Milliways The problem is only using a disktool without touching an existing installation breaks its booting. This is not expected on a unix system and it isn't documented. It also breaks (restricts) kernel-specification. Workaround (not fixing) this cost me and others hours of hours. I will try with device name. – Ingo Jan 25 '18 at 10:46

2 Answers2

4

It seems with the current bootloader it's not possible to use partition UUID as kernel boot parameter for the root device. As suggested in the comment I tried booting with the device name /dev/mmcblk0p2. It works and I will use that from now on. It is more stable than using PARTUUID because it does not interfere with disk management tools on cloned disk images like Raspbian.

Before flashing an image I modify /boot/cmdline.txt and /etc/fstab. For reference I use 2018-03-13-raspbian-stretch-lite.img and mount its partions on a pc with CD Card reader. The offsets are only valid for this image!

pc ~$ sudo mount -o offset=$((8192*512)),sizelimit=$((85611*512)) 2018-03-13-raspbian-stretch-lite.img /mnt/boot
pc ~$ sudo mount -o offset=$((98304*512)),sizelimit=$((3530752*512)) 2018-03-13-raspbian-stretch-lite.img mnt/root

Then changed:

pc ~$ sudo cat /mnt/boot/cmdline.txt
dwc_otg.lpm_enable=0 console=serial0,115200 console=tty1 root=PARTUUID=a8fe70f4-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait quiet init=/usr/lib/raspi-config/init_resize.sh

to

dwc_otg.lpm_enable=0 console=serial0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait quiet init=/usr/lib/raspi-config/init_resize.sh

and

pc ~$ sudo cat /mnt/root/etc/fstab
proc                  /proc           proc    defaults          0       0
PARTUUID=a8fe70f4-01  /boot           vfat    defaults          0       2
PARTUUID=a8fe70f4-02  /               ext4    defaults,noatime  0       1

to

proc            /proc           proc    defaults          0       0
/dev/mmcblk0p1  /boot           vfat    defaults          0       2
/dev/mmcblk0p2  /               ext4    defaults,noatime  0       1

pc ~$ sudo umount /mnt/root
pc ~$ sudo umount /mnt/boot
Ingo
  • 40,606
  • 15
  • 76
  • 189
0

In this case, it's not the bootloader at issue. The boot loader on the sdcard simply loads up the configured kernel and initramfs and passes the cmdline along to them. The initramfs is responsible for reading the root= cmdline and mounting root accordingly for the rest of boot. Issues with the initramfs not mounting root correctly (when configured correctly) are typically timing issues with root devices being enumerated by udev too slowly. You'll see this alot with USB devices and software raid devices. I've used rootdelay=9 (for a 9sec wait for root devices to show) in the past.

razholio
  • 1
  • 1
    As described in the question the `PARTUUID` is changed on the storage but not in cmdline.txt when using *parted* for example to add a partition. You can wait as long as you like, that will not restore the old `PARTUUID` on the storage. Initramfs (when used) cannot find the wrong addressed root partition. – Ingo Dec 02 '18 at 21:59