0

Goal

Hi my PI keeps rebooting after I added two lines to the rc.local file. Now i am trying to log into the boot shell and edit those two lines out.

Problem

I added init=/bin/bash to the cmdline.txt and it looks like the following:

 dwc_otg.lpm_enable=0 root=PARTUUID=61f5b861-02 rootfstype=ext4 elevator=deadline 
fsck.repair=yes rootwait quiet splash plymouth.ignore-serial-consoles init=/bin/bash

I then can successfully log into the boot shell and type at the command line. However, whenever I've tried the following commands to remount the file system as read/write:

mount -n -o remount,rw /

it gave an error: mount: can't find PARTUUID=61f5b861-02

Then after I read some posts on the forum, I changed the root in my cmdline.txt to the following:

 dwc_otg.lpm_enable=0 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline 
fsck.repair=yes rootwait quiet splash plymouth.ignore-serial-consoles init=/bin/bash

And then i ran the command: mount: mount point /dev/mmcblk0p2 / It just worked...

Question

Can somebody explain what happened? This doesn't seem to be the solution for anybody else.

Reference:

https://www.raspberrypi.org/forums/viewtopic.php?p=1284212

How do I start up in safemode?

goldilocks
  • 58,859
  • 17
  • 112
  • 227
Yihan Hu
  • 37
  • 1
  • 5

1 Answers1

2

The root= field from cmdline.txt specifies to the kernel where the partition with the root filesystem is. There are a few ways that can be specified. The one that is generally preferred in the linux world is UUID or PARTUUID, because it depends on a fixed identifier assigned to the partition as opposed to the other commonplace method, a /dev node, which is less predictable on systems that have various sorts of storage attached the configuration of which may change, meaning the associated /dev node would then change, whereas the UUID would not.

There's a bit of a complication with PARTUUID, though, which is really intended for use on GPT disks, but is also something that Windows systems won't get wrong when dealing with ext4 partitions, for a further explanation:

https://raspberrypi.stackexchange.com/a/95436/5538

Anyway, when you copy a partition, unlike the UUID, the PARTUUID doesn't go with it, which is why they can get lost. Conversely, if you copy cmdline.txt around, you'll end up with a mismatch.

However, in the context of a normal 2 partition Rpi SD card, /dev/mmcblk0p2 is unequivocal: It means the second partition on the first SD block device.

You can check the PARTUUID on a running system with:

blkid /dev/mmcblk0p2

Chances are it isn't 61f5b861-02.

goldilocks
  • 58,859
  • 17
  • 112
  • 227
  • Linux supports PARTUUID for MBR partitions, but this is not fixed and is just a positional notation for the partition on the MBR disk. The format is SSSSSSSS-PP, where SSSSSSSS is a 32-bit MBR disk signature (stored in the MBR label-id field), and PP is a partition number. PARTUUID creates more problems than it solves on the Pi as SD Cards are easily, and commonly moved/duplicated. – Milliways Sep 06 '19 at 00:05
  • Yes, the fact that it is derived from a value in the MBR is why you can deduce it without having (or being able) to read any partition data, which is where a normal UUID is (permanently labelled in the fs). The other issue on the Pi cards is vfat parititions can't be labelled with a UUID, so PARTUUID seems like a smart choice, except that: 1) You could use root=UUID even if the first partition doesn't have one, 2) Much less problematic in context would be just using the /dev node. – goldilocks Sep 06 '19 at 13:01