Add support for parted 'Disk Flags' (in particular 'Disk Flags: pmbr_boot' to boot from GPT disk on BIOS system)

[jsmeix]

Cf.
#2298 (comment)
and
#2299 (comment)

• ReaR version ("/usr/sbin/rear -V"):
  Current GitHub master code

• OS version ("cat /etc/rear/os.conf" or "lsb_release -a" or "cat /etc/os-release"):
  openSUSE Leap 15.1

• ReaR configuration files ("cat /etc/rear/site.conf" and/or "cat /etc/rear/local.conf"):
  should not matter here - but same as in
  Normal /dev/sda by "multipath -c /dev/sda" falsely recognized as multipath device (DM_MULTIPATH_DEVICE_PATH="1") #2298 (comment)

• Hardware (PC or PowerNV BareMetal or ARM) or virtual machine (KVM guest or PoverVM LPAR):
  PC (my laptop)

• System architecture (x86 compatible or PPC64/PPC64LE or what exact ARM device):
  x86_64

• Firmware (BIOS or UEFI or Open Firmware) and bootloader (GRUB or ELILO or Petitboot):
  UEFI capable firmware in legacy BIOS mode

• Storage (local disk or SSD) and/or SAN (FC or iSCSI or FCoE) and/or multipath (DM or NVMe):
  local /dev/sda with GPT

• Storage layout ("lsblk -ipo NAME,KNAME,PKNAME,TRAN,TYPE,FSTYPE,SIZE,MOUNTPOINT"):
  see Normal /dev/sda by "multipath -c /dev/sda" falsely recognized as multipath device (DM_MULTIPATH_DEVICE_PATH="1") #2298 (comment)

• Description of the issue (ideally so that others can reproduce it):

See #2299 (comment)
(excerpt)

I did a "rear recover" test on my laptop
...
the recreated system can no longer boot from its built-in /dev/sda
(the BIOS tells that an operating system needs to be installed on the disk)
but it can be booted from the USB disk ReaR recovery system bootloader
in its syslinux boot menue by selecting `Boot Local disk (hd1)`
so something on the built-in /dev/sda got lost or damaged by "rear recover"
that is needed by that laptop's firmware (UEFI capable firmware that I use
in legacy BIOS mode) to boot.

• Workaround, if any:

See #2299 (comment)
(excerpt)

The missing piece on /dev/sda that got destroyed by "rear recover"
was the enabled boot flag on the GPT’s protective MBR partition, cf.
https://www.gnu.org/software/parted/manual/html_node/disk_005fset.html
...
(parted) disk_set pmbr_boot on
...
The difference is `Disk Flags:` empty which does not work
versus `Disk Flags: pmbr_boot` which is needed
at least by my UEFI firmware that I use in legacy BIOS mode
to boot from a GPT disk with GRUB2 installed "in MBR"

Accordingly the following POST_RECOVERY_SCRIPT
in etc/rear/local.conf helped in my case:

SSH_ROOT_PASSWORD="rear"
USE_DHCLIENT="yes"
PROGRESS_MODE="plain"
PROGRESS_WAIT_SECONDS=3
KEEP_BUILD_DIR="yes"
GRUB_RESCUE=y
OUTPUT=USB
BACKUP=NETFS
BACKUP_URL=usb:///dev/disk/by-label/REAR-000
USB_SUFFIX="ReaRbackup"
USB_DEVICE_FILESYSTEM_PERCENTAGE=10
POST_RECOVERY_SCRIPT=( 'parted -s /dev/sda disk_set pmbr_boot on' )

[jsmeix]

I think what is actually needed is support for parted Disk Flags.

E.g. on my original system I have

# parted -s /dev/sda unit MiB print

Model: ATA QEMU HARDDISK (scsi)
Disk /dev/sda: 20480MiB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: pmbr_boot
...

but after "rear recover" I get on the recreated system

# parted -s /dev/sda unit MiB print

Model: ATA QEMU HARDDISK (scsi)
Disk /dev/sda: 20480MiB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:
...

i.e. no longer any Disk Flags.

[github-actions]

Stale issue message

[dcz01]

@jsmeix I think that this bug is important for many systems.
You should reopen it because it was closed by github-bot.
I also use some systems with the BIOS and GPT partition format with pmbr_boot flag.

[dcz01]

@gdha Could we reopen this bug or better said feature for ReaR?

[github-actions]

Stale issue message