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?

Improve this question

1 Answer 1

Reset to default
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.

Improve this answer
2
  • 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
    Commented Sep 6, 2019 at 0: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 ♦
    Commented Sep 6, 2019 at 13:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.