Using /dev/disk/by-label does not work after flashing disk

[lhh31]

Is your feature request related to a problem? Please describe.
I am running an A/B partitioning scheme and there are multiple disks connected to the system. To allow me to access the disks in a repeatable manner I use the/dev/disk/by-label to identity them. In the update manifest the device= parameter uses this label to identify the disk; however, when flashing the disk (e.g., as an ext4 filesystem) the label is not preserved after the update process.

I have not tested, but I suspect that this would also ocurr if the update was interrupted as the label is one of the first pieces of information lost form the disk.

Describe the solution you'd like
The label is persevered.

Describe alternatives you've considered
I could set the label on the ext4 before adding it to the bundle; however, how could I guarantee that it would be installed to the correct partition and I could end up with duplicate partition labels.

I could add a post-hook to run e2label to set the label after the disk has been flashed; however, this runs the risk that if the update process was interrupted the disk could possibly have no label and therefore never be able to be programmed by rauc without a user intervention.

[ejoerns]

@lhh31 The file system label is inappropriate for identifying a disk in a filesystem-image-based redundancy setup.
It is a property of the file system and the file system is expected to be replaced by an update.

Please use another alternative to identify the partition, like by-path or by-uuid.
Some options are described here: https://rauc.readthedocs.io/en/latest/integration.html#partitioning-your-device

[lhh31]

@ejoerns the by-uuid will change when the update is applied, and the by-path is not accessible from grub. Are you meaning to use the by-partuuid as this is stored within the partition table rather than the partition itself?

[ejoerns]

@lhh31 Sorry, confused myself. Indeed, I meant by-partuuid for the reason you mentioned.

[jluebbe]

I've created #1359 to clarify the documentation.

[lhh31]

@ejoerns from what I understand grub does not support using Partition UUID, but rather only supports the filesystem UUID. This means that the detection of the partition can only be performed by the initramfs rather than by grub itself, meaning that the initramfs must be loaded from the same partition as the grub bootloader.

[ejoerns]

@lhh31 I'm not sure if I get your setup. grub should be unrelated here since we are talking about paths/symlimks that are determined by Linux and udev.

Could you describe what you try to achieve this grub here?

https://github.com/rauc/meta-rauc-community/tree/master/meta-rauc-qemux86 should contain an example setup for grub btw.

[lhh31]

@ejoerns I have an A B partitioning setup using grub on a EFI boot partition.

Looking at the disk layout it is something like the following.

/dev/sda
|-/dev/sda1 (vfat)
  |- /EFI/boot/bootx64.efi
  |- /EFI/boot/grub.cfg
  '- /EFI/boot/grubenv
|-/dev/sda2 (ext4)
  |- bzImage
  |- initramfs.cpio.gz
  '- roots.squashfs
|-/dev/sda3 (ext4)
  |- bzImage
  |- initramfs.cpio.gz
  '- roots.squashfs

The grub.cfg (currently) uses the search.label to get the partition (hd0,gpt2) that corresponds to the current boot slot. Boot slot selection is the same as that example you gave using TRY_A etc in the grubenv. The grub search command searches for the A or B partition label then loads the kernel, initramfs from that partition and passes the rootfs UUID to the kernel for the initramfs to load the squashfs root file system.

An RAUC update is setup as an ext4 partition containing a new kernel initramfs and rootfs. This allows update of everything except the boot loader with the same safe fallback mechanism as rootfs updates.

The issue with using labels is as initially raised - they get wiped out, and UUID has the same issue. Using PARTUUID would remain static; however grub cannot search by partition UUID rather only file system UUID.

An easy way to do it would be to load the kernel and initramfs from the first vfat partition but this makes kernel and initramfs updates more difficult.

[ejoerns]

@lhh31 Is the disk topology prone to change in your grub setup?

Otherwise, you could just hard-code the partitions to boot for each entry, couldn't you? Like:

menuentry "Slot A (OK=$A_OK TRY=$A_TRY)" {
    linux (hd0,4)/boot/bzImage root=/dev/sda4 $CMDLINE rauc.slot=A
}

Depending on how you do your bootstrapping, you should at least know the topology beforehand and could use 'disk/by-path` symlink in your system.conf to match the appropriate partitions.
Doing the 'slot identification' in both directions (i.e. also in grub by reading the label) shouldn't be required in a static partitioning setup.

The actual identification of the booted partitions on Linux/RAUC-side will work via the rauc.slot cmdline parameter anyway.

Btw, is the split-up between kernel, initramfs and squashfs rootfs required in your setup?

[lhh31]

@ejoerns it only changes when we have a usb drive connected to the system, in which case the disk do change in grub. The main cause we find is that we have multiple disks connected to the system (eMMC multiple externals) and on different units they are enumerated in different orders (e.g sometimes eMMC is hd0 others not, especially when the disk is changed with a newer part number or a different processor), hence requiring to search in grub as well.

I'm not sure I understand the question about the split up? Are you saying to bundle the initramfs and bzImage? Or why is the initramfs and kernel not in the squashfs?

[djr-spectrummfg]

Another solution is to use the patch from my PR #1375 to manually set the label to a known value for each slot and use a tar archive in the bundle rather than ext4 directly.

[ejoerns]

I am not convinced that working around GRUB's lack of support for identifying partitions based on partition or topology information in RAUC. Might this be the point where one should consider if GRUB is the proper bootloader or if GRUB should be patched/extended? Like what was discussed once in https://help-grub.gnu.narkive.com/c6QEmclg/search-by-partuuid

Maybe there are other options existing but I am not a GRUB expert ;)

I'm not sure I understand the question about the split up? Are you saying to bundle the initramfs and bzImage? Or why is the initramfs and kernel not in the squashfs?

Was just the question if initramfs is required in the setup (for setting up something) or if one could directly boot a rootfs with a kernel contained (for setup simplification).

[lhh31]

@ejoerns the initramfs has one core feature where it creates a tmpfs to use as an overlay over the squashfd rootfs. This probably could be replicated by added some services to the early systemd services but I haven't really investigated that route very much.

At the moment I have got a working setup which uses the UUID of the fat boot partition to recognise if the USB flash is plugged in. This means we can then boot the usb entry in the grub.cfg. The main eMMC fat also has a fixed UUID which is also searched by grub to load the kernel in normal mode. Each eMMC partition then has a PARTUUID and the PARTUUID is then passed at the grub load argument as the rootfs to load the correct rootfs. The systemd configuration then uses /dev/disk/by-partuuid to install updates. The PARTUUID doesn't change, and the fat UUID doesn't change so

@djr-spectrummfg i am not familiar enough with the source; however, if the mkfs command fails for some reason (power off during command) is there not a change the label will not be applied and there could possibly brick a device, or is there a protection around this?

[djr-spectrummfg]

i am not familiar enough with the source; however, if the mkfs command fails for some reason (power off during command) is there not a change the label will not be applied and there could possibly brick a device, or is there a protection around this?

If the update is interrupted then the slot is invalid anyway whether there's a label or not. The only concern is whether this breaks attempting the update again - which it would do if you used the label in the rauc system.conf slots definition, but not if you specified it without using labels there as in my example config on that PR. The fact that a bootloader may be looking for the label isn't really relevant.