#2548 Issue `closed`: GPT table creation does not recover old disk and partition GUIDs¶

Labels: won't fix / can't fix / obsolete, minor bug

DEvil0000 opened issue at 2020-12-21 18:29:¶

ReaR version ("/usr/sbin/rear -V"): 2.6
OS version ("cat /etc/os-release" or "lsb_release -a" or "cat /etc/rear/os.conf"): ubuntu 20.04
Firmware (BIOS or UEFI or Open Firmware) and bootloader (GRUB or ELILO or Petitboot): uefi/grub
Partition table type on system: gpt
Description of the issue (ideally so that others can reproduce it):
After a recover a new UEFI boot entry gets created for the recovered efi since the GPT partition GUID changed.
Of course this is more a minor issue only affecting people making use of multiple boot options tried to boot in order.
This however has two side effects:
1. it changes the boot order putting the recovered efi partition as first
2. it fills the boot records list with another entry keeping the old one (getting messy and maybe running out of entries over time)
Workaround/solution:
There are at least two possible workarounds/fixes possible for this:
- one can cleanup the old efi boot entries and set the boot order again (manually or with e.g. evibootmgr)
- one can replace the GUID (e.g. using gdisk or sgdisk) and use the old efi boot entry

The complete fix for rear would be also writing GPT GUIDs to the layout file and then setting them e.g. with sgdisk.

gdha commented at 2021-01-08 11:05:¶

@DEvil0000 No interest in writing a PR for your proposal?

gdha commented at 2021-01-12 16:46:¶

@DEvil0000 PR has been merged, if you could recheck if all goes well?

DEvil0000 commented at 2021-01-13 11:27:¶

The vfat ID now gets set for the UEFI partition but the GPT partition GUID (not type id) is still newly generated and was not addressed by #2546

gdha commented at 2021-01-22 16:47:¶

@DEvil0000 Sorry for the delay in answer - please show us what is really missing here - it seems we misunderstood

DEvil0000 commented at 2021-01-22 17:26:¶

A efi boot entry contains disk, partition and efi payload path. There may also be a filesystem ID/UUID but thats not what this ticket is about.
Example UEFI boot entries (might use less details or different ids and methods - UEFI records are quite a beast):

Boot0019* Ubuntu 1  HD(1,800,32000,a44dc908-e0d1-4df5-903f-a8db5f6f66b3)File(\EFI\ubuntu\grubx64.efi)
Boot001A* Ubuntu 2  HD(4,df6609e,2fbe1,773a0059-be41-4828-944a-32217f941c95)File(\EFI\ubuntu\grubx64.efi)

The disk may be referenced by its bios id (a integer based on boot order bios settings normally) or by a disk UUID. See wiki (Partition table header, offset 0x38) for GPT but I think msdos has the same thing at the same offset in this case.

When using a msdos partition table the partitions are numberd from 1-4 or such. For an UEFI boot (payload) record you reference the partition id then.
When using GPT partition tables the partitions have a UUID for the partition type and a UUID for the actual partition. See wiki (Partition entries, offset 0x10). This Unique partition GUID must get recovered so existing old UEFI boot entries still match otherwise the system BIOS/Firmware will create a new entry or you would need to create one manually.

So when using a GPT partition table and UEFI you should definitely save the GPT UUIDs (disk and partition) and also insert those when creating the partition on recover. This way you restore the system "as it was".
Then you will not face any issues with UEFI and existing boot entries.

Edit:
My proposal is to also store those GPT UUIDs in the layout file and write them correctly to GPT when created.
There is also a GPT partition name which you might need to recover - don't remember if that was recovered.
BTW I am using USB method if that makes a difference.

gdha commented at 2021-01-25 14:07:¶

@DEvil0000 Not all system are equal it seems - my UEFI knowledge became a bit rusty...

root@velo:~# efibootmgr 
BootCurrent: 0004
Timeout: 0 seconds
BootOrder: 0004,0003,0000,0001
Boot0000* UEFI Micron 2200S NVMe 512GB 194624E8DCEE 1
Boot0001* Linux Firmware Updater
Boot0003* UEFI Micron 2200S NVMe 512GB 194624E8DCEE 1 2
Boot0004* ubuntu

root@velo:~# parted /dev/nvme0n1 print
Model: Micron 2200S NVMe 512GB (nvme)
Disk /dev/nvme0n1: 512GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:

Number  Start   End     Size    File system  Name                  Flags
 1      1049kB  819MB   818MB   fat32        EFI system partition  boot, esp
 2      819MB   6188MB  5369MB  fat32        Basic data partition  msftres
 3      6188MB  512GB   506GB   ext4

Not sure where to start? @gozora Do you have some more insights on these matters?

gozora commented at 2021-01-26 07:31:¶

Let us not forget that there are also users that are migrating to different HW. For this group of people recreating all the UEFI boot configuration entries make little sense.
I think that current minimalist approach, that adds just entry for newly restored system, is good because it is simple. If one is concerned about mess in boot entries, he can easily clean it up (using efibootmgr).

Of course if anybody is willing to cover this complex topic with a pull request, I have no objections.

Hope it helps.

V.

[Export of Github issue for rear/rear.]

#2548 Issue closed: GPT table creation does not recover old disk and partition GUIDs¶