2

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
  • 42,961
  • 20
  • 87
  • 207

2 Answers2

5

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
  • 42,961
  • 20
  • 87
  • 207
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