#3420 PR merged: ppc64le: Fix PReP Boot detection on GPT layouts

Labels: enhancement, cleanup, fixed / solved / done, special hardware or VM

lzaoral opened issue at 2025-03-05 08:58:

Pull Request Details:

  • Type: Bug Fix

  • Impact: High

  • Reference to related issue (URL): N/A, found when playing with #3406

  • How was this pull request tested? rear -d savelayout on RHEL 9 (MSDOS) and RHEL 10 (GPT)

  • Description of the changes in this pull request:

In general, file output is not stable and is purely informational. This manifested in PReP Boot partitions on GPT formatted block devices being classified as missing (apparently, file detects the Protective MBR instead):

# file -s /dev/sdb
/dev/sdb: DOS/MBR boot sector; partition 1 : ID=0xee, active, start-CHS (0x0,0,2), end-CHS (0x3ff,255,63), startsector 1, 10485759 sectors
# parted -s /dev/sdb print
Model: AIX VDASD (scsi)
Disk /dev/sdb: 5369MB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: pmbr_boot

Number  Start   End     Size    File system  Name  Flags
 1      1049kB  5243kB  4194kB                     prep
 2      5243kB  1079MB  1074MB  xfs                bls_boot
 3      1079MB  5368MB  4289MB                     lvm

This fixes the bootloader detection on RHEL 10 PowerVM machines which use the GPT layout by default.

lzaoral commented at 2025-03-05 09:41:

The Packit CI failures are unrelated.

jsmeix commented at 2025-03-06 09:08:

@rear/contributors
unless there are objections
I would like to merge it tomorrow afternoon

jsmeix commented at 2025-03-06 10:38:

This issue is not an actual bug in ReaR because
there is the config variable BOOTLOADER
which is meant for the user to specify (if needed)
what kind of bootloader is used on his system
and what we do when BOOTLOADER is not specified
in layout/save/default/445_guess_bootloader.sh
can be only a guess what bootloader is used
because it is impossible to determine in a reliable way
how a running system was actually booted, see the
section "Disaster recovery does not just work" in
https://en.opensuse.org/SDB:Disaster_Recovery#Disaster_recovery_does_not_just_work

jsmeix commented at 2025-03-07 12:21:

FYI an addendum regarding x86_64 with ESP:

Also on x86_64 with an EFI system partition (ID=0xEF)
'file $disk' detects the GPT protective MBR (ID=0xEE).

Regarding those IDs see
https://en.wikipedia.org/wiki/Partition_type

For example on my workstation
(long 'file' output line shown wrapped here):

# file -s /dev/nvme0n1
/dev/nvme0n1: DOS/MBR boot sector; partition 1 : ID=0xee,
 start-CHS (0x0,0,2), end-CHS (0x3ff,254,63), startsector 1,
 976773167 sectors, extended partition table (last)

# parted -s /dev/nvme0n1 unit GiB print
Model: NVMe Device (nvme)
Disk /dev/nvme0n1: 466GiB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: 
Number  Start    End      Size     File system  Name   Flags
 1      0.00GiB  0.50GiB  0.50GiB  fat16               boot, esp
...

Also the 'file $partition' output does not look really helpful
to reliably detect an EFI system partition
(long 'file' output line shown wrapped here):

# file -s /dev/nvme0n1p1
/dev/nvme0n1p1: DOS/MBR boot sector, code offset 0x3c+2,
 OEM-ID "mkfs.fat", sectors/cluster 16, reserved sectors 16,
 root entries 512, Media descriptor 0xf8, sectors/FAT 256,
 sectors/track 32, heads 64, hidden sectors 2048,
 sectors 1046528 (volumes > 32 MB), reserved 0x1,
 serial number 0x89aa6ad3, unlabeled, FAT (16 bit)

In contrast the 'part ... esp ...' entry in disklayout.conf
shows correctly the disk '/dev/nvme0n1'
with the EFI system partition '/dev/nvme0n1p1':

# grep '^part .*esp' var/lib/rear/layout/disklayout.conf 
part /dev/nvme0n1 535822336 1048576 rear-noname boot,esp /dev/nvme0n1p1

# awk -F ' ' '/^part / {if ($6 ~ /esp/) {print $2}}' var/lib/rear/layout/disklayout.conf
/dev/nvme0n1

# awk -F ' ' '/^part / {if ($6 ~ /esp/) {print $7}}' var/lib/rear/layout/disklayout.conf
/dev/nvme0n1p1

[Export of Github issue for rear/rear.]