Discussion:
search by PARTUUID
Urs Ritzmann
2018-04-10 14:25:01 UTC
Permalink
Hello,

Is there any way to search for the device name by GPT partition UUID or by partition label from the GRUB command-line?

I'd like to search and boot a kernel by GPT partition UUID or partition label.
For example, my grub.cfg would looks like this:

# The following command sets ${partition_uuid},
# i.e.: partition_uuid=14692f4f-bedb-430f-a37f-26b71855945c
load_env

search --partition-uuid --set kernel_partition ${partition_uuid}
kernel_path=(${kernel_partition})/boot/bzImage
linux ${kernel_path} root=PARTUUID=${partition_uuid}
boot

Unfortunately, the search command only supports the filesystem's UUID or label (search --partition-uuid is fiction). Is there a way to achieve this?

---
Many Thanks
Urs
Pascal Hambourg
2018-04-10 21:43:45 UTC
Permalink
Post by Urs Ritzmann
Is there any way to search for the device name by GPT partition UUID or by partition label from the GRUB command-line?
I'd like to search and boot a kernel by GPT partition UUID or partition label.
What would be the use case ?
IOW, why can't you use another search option ?
Urs Ritzmann
2018-04-11 08:00:50 UTC
Permalink
Post by Pascal Hambourg
What would be the use case ?
Ok, let me elaborate my motivation. It's an embedded setup with the following characteristics:

- The kernel is part of the root filesystem and loaded from there.
- There are multiple (redundant) root filesystems (each including its own kernel).
- Updates are always performed on a full image, meaning that one of the root filesystems is completely re-written during an update.
- PARTUUID would point to the most recently updated Image (partition containing rootfs/kernel).

The thing is that when rewriting the filesystem during an update, the filesystem UUID changes, where in contrast, the partition UUID stays constant. So using the PARTUUID would be a better solution.
Post by Pascal Hambourg
IOW, why can't you use another search option ?
Currently, the filesystem UUID is used in the search. It works, but the fs UUID has to be updated after an image update which is a bit ugly. A constant PARTUUID pointing to current image would be more clean.

--
Many Thanks
Urs
Pascal Hambourg
2018-04-11 18:28:17 UTC
Permalink
Post by Urs Ritzmann
Currently, the filesystem UUID is used in the search. It works, but the fs UUID has to be updated after an image update which is a bit ugly. A constant PARTUUID pointing to current image would be more clean.
Can't the same UUID be used when creating a new image ?
Urs Ritzmann
2018-04-12 07:17:37 UTC
Permalink
Hi
Post by Urs Ritzmann
Post by Urs Ritzmann
Currently, the filesystem UUID is used in the search. It works, but the fs UUID has to be updated after an image update which is a bit
ugly. A constant PARTUUID pointing to current image would be more clean.
Can't the same UUID be used when creating a new image ?
The same image can be installed to different partitions (e.g. in a fail-safe dual-copy approach, the currently active image always updates another, inactive image, then toggles the boot to the new one).

In case the same image is installed twice (to different partitions), I would end up with both images having the same UUID.
--
Many Thanks
Urs
Pascal Hambourg
2018-04-12 21:21:11 UTC
Permalink
Post by Urs Ritzmann
Post by Urs Ritzmann
Post by Urs Ritzmann
Currently, the filesystem UUID is used in the search. It works, but the fs UUID has to be updated after an image update which is a bit
ugly. A constant PARTUUID pointing to current image would be more clean.
Can't the same UUID be used when creating a new image ?
The same image can be installed to different partitions (e.g. in a fail-safe dual-copy approach, the currently active image always updates another, inactive image, then toggles the boot to the new one).
In case the same image is installed twice (to different partitions), I would end up with both images having the same UUID.
And that would be a bad thing, because UUIDs are supposed to be unique.
You wrote that rewriting the filesystem UUID was a bit ugly, but IMO not
doing it and having duplicate UUIDs is much more ugly.

Looking at the grub-devel mailing list archives, I found out that some
patches have been submitted to add support for partition UUIDs in GRUB.
But I don't know their status nor whether that is exactly the kind of
support that you are looking for. IIUC, the submitter seemed more
interested in using PARTUUID in the Linux kernel root parameter than in
search commands.
m***@protonmail.com
2018-04-13 05:32:35 UTC
Permalink
I wrote a patch a while ago for this. I ended up creating an add-on command, that uses the partition UUID/GUID, to search (--pt-uuid) and an accompanying module search.pt_uuid. These two commands mirror the search --fs-uuid and search.fs_uuid where given a uuid it will return the device. When given a disk/partition UUID/GUID that corresponds to a disk that is either a biosdisk or efidisk, or a partition with a partmap name of either "msdos" or "gpt" on one of the previous disks it will return that device. I checked it against the master and it applied cleanly. I can post it in a day.

Best regards,

Matt

-------- Original Message --------
Post by Urs Ritzmann
Post by Urs Ritzmann
Post by Urs Ritzmann
Currently, the filesystem UUID is used in the search. It works, but the fs UUID has to be updated after an image update which is a bit
ugly. A constant PARTUUID pointing to current image would be more clean.
Can't the same UUID be used when creating a new image ?
The same image can be installed to different partitions (e.g. in a fail-safe dual-copy approach, the currently active image always updates another, inactive image, then toggles the boot to the new one).
In case the same image is installed twice (to different partitions), I would end up with both images having the same UUID.
And that would be a bad thing, because UUIDs are supposed to be unique.
You wrote that rewriting the filesystem UUID was a bit ugly, but IMO not
doing it and having duplicate UUIDs is much more ugly.

Looking at the grub-devel mailing list archives, I found out that some
patches have been submitted to add support for partition UUIDs in GRUB.
But I don't know their status nor whether that is exactly the kind of
support that you are looking for. IIUC, the submitter seemed more
interested in using PARTUUID in the Linux kernel root parameter than in
search commands.

_______________________________________________
Help-grub mailing list
Help-***@gnu.org
https://lists.gnu.org/mailman/listinfo/help-grub
Urs Ritzmann
2018-04-16 07:41:38 UTC
Permalink
Hi Matt
Post by m***@protonmail.com
I wrote a patch a while ago for this. I ended up creating an add-on command, that uses the partition UUID/GUID, to search (--pt-uuid) and
an accompanying module search.pt_uuid. These two commands mirror the search --fs-uuid and search.fs_uuid where given a uuid it will
return the device. When given a disk/partition UUID/GUID that corresponds to a disk that is either a biosdisk or efidisk, or a partition with
a partmap name of either "msdos" or "gpt" on one of the previous disks it will return that device. I checked it against the master and it
applied cleanly. I can post it in a day.
That's exactly what I'm looking for. I appreciate if you can post the patches. Did you try to upstream them?

Many Thanks
Urs
Post by m***@protonmail.com
-----Original Message-----
Sent: Freitag, 13. April 2018 07:33
Subject: Re: search by PARTUUID
I wrote a patch a while ago for this. I ended up creating an add-on command, that uses the partition UUID/GUID, to search (--pt-uuid) and
an accompanying module search.pt_uuid. These two commands mirror the search --fs-uuid and search.fs_uuid where given a uuid it will
return the device. When given a disk/partition UUID/GUID that corresponds to a disk that is either a biosdisk or efidisk, or a partition with
a partmap name of either "msdos" or "gpt" on one of the previous disks it will return that device. I checked it against the master and it
applied cleanly. I can post it in a day.
Best regards,
Matt
Loading...