Support LABEL in installed_os.json[n].partitions

[akinnee]

/etc/fstab supports mounting partitions using the partition label.

Looks like installed_os.json supports:

• device node path, e.g. /dev/sda6
• partition uuid, e.g. PARTUUID=abc-06

Mounting by LABEL would make the install better survive partition moving, since PARTUUID can change from that. It would still survive moving the drive to another port, unlike device mount path.

Currently, PINN says LABEL=OS1_BOOT is not a valid partition, even though putting the same thing in the first OS's /etc/fstab file works fine.

[procount]

PINN already supports using Label. Indeed it is necessary to boot Ubuntu.
Which OS does this refer to? Are you creating your own OS installation files?
Make sure your partition names do not have spaces in them (in partitions.json), although I do try to replace them with Underscores.

Using LABEL is not perfect, as it means you cannot have 2 instances of the same OS on the same drive.

[akinnee]

PINN already supports using Label. Indeed it is necessary to boot Ubuntu.
Which OS does this refer to? Are you creating your own OS installation files?
Make sure your partition names do not have spaces in them (in partitions.json), although I do try to replace them with Underscores.

Using LABEL is not perfect, as it means you cannot have 2 instances of the same OS on the same drive.

If I try using the same label syntax in the json file that I use in fstab, then try using the fixup feature, it errors. It works fine if I specify the path (/dev/sda1 for example) in the json file and then use LABEL in fstab.

You can easily relabel the partitions to support multiple of the same os per drive. I gave each partition a unique label. No issues with my installs breaking after moving partitions around in gparted now.

[procount]

Please see partitions.json from Ubuntu as an example.
This is the syntax to use:

      "label": "system-boot",
      "requires_label": true,

The partitions.json file fields are described in https://github.com/procount/pinn/wiki/JSON-fields#partitions.json
The requires_label field is necessary to force labels to be used as references. It will also check that no existing partition has the same label name as they must be unique.

The use of partuuids, uuids, device names or labels is OS specific as not all OSes support all types. Some OSes can use whatever label names you like, but others like Ubuntu will not upgrade if the labels are not as expected. Hence you could install 2 copies of Ubuntu by changing the labels of one of them, but it will no longer be upgradable as I understand it. YMMV.

I can't explain why your use of labels is not working in your PINN installations without more information. E.g. which OS? what is your partitions.json file? what partition formats? What error message?

Make sure you conform to the maximum label lengths which are different for each format type.

[akinnee]

Can easily repro with 2 copies of pi OS.

PINN doesn't support referring to partitions by LABEL

• Install with PINN, works fine
• Give your partitions nice labels, works fine
• Edit fstab files for both OSs to refer to partitions by label, instead of UUID, works fine
• installed_os.json to refer to partitions by label, instead of UUID
• run PINN fixup tool
• breaks, can't boot

Using LABEL is not perfect

Even if that's the case, the tool doesn't have to use labels by default. But if the user manually edits installed_os.json, it should at least support it.

UUID is not good, because resizing partitions causes their UUIDs to change, which makes the PINN bootloader not work

device path is not good, because if the drive is mounted at a different path, the PINN bootloader won't work, but at least device path survives partition resize.

LABEL would support both cases, and if some OSs don't support it, users can continue using UUID or device path for those OSs.

[procount]

Manually editing installed_os.json is not a documented nor expected operation.

[akinnee]

Understood. I figured it out myself through reading the source and trial-and-error. That's fine if it's not officially supported.

Editing installed_os.json does work fine for re-configuring PINN to reference partitions by device path, though, which makes it possible to resize the partitions with gparted without bricking the install. So, I'm not sure why PINN wouldn't also support LABEL. Perhaps both options could make it into the GUI someday, but I'm not too worried about that for now.

If you follow all the steps I listed above, but use device paths instead of labels, it all works totally fine. And I think I remember seeing that PINN used to use device path, but switched to UUID to make sure the install would continue working if the drive is plugged into a different port.

I'm not too familiar with the codebase, but if you point me in the right direction, I could see about adding support for LABEL whenever I have time to dig into it. 🙂

[procount]

I will take a look to see if this can be improved.

The default is to use Device Paths on SD card, or PARTUUIDs on USB or SSD.
Some OSes require labels to be used, so they have overrides to use those regardless.
Some OSes can't use PARTUUIDS, but can boot from USB/SSD if device paths are used, which implies limitations.
Some OSes can't be booted from USB/SSD at all.

So there is no "one-size fits all" solution and there are a lot of things to consider to try and make it foolproof.