#2234 Issue closed: Multipath disk restored with MBR instead of GPT

Labels: enhancement, bug, cleanup, fixed / solved / done

petrpavlu opened issue at 2019-09-12 13:02:

  • ReaR version ("/usr/sbin/rear -V"):

    # ./usr/sbin/rear -V
Relax-and-Recover 2.5 / Git

    Git revision a252ca20b5dc9f34f6c8fffb61e055141ca37669 (current HEAD).

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

    # cat etc/rear/os.conf 
OS_VENDOR=SUSE_LINUX
OS_VERSION=12.2

  • ReaR configuration files ("cat /etc/rear/site.conf" and/or "cat /etc/rear/local.conf"):

    # cat etc/rear/local.conf
BACKUP=NETFS
BACKUP_OPTIONS="nfsvers=4,nolock"
BACKUP_URL=nfs://192.168.122.1/srv/nfs/multipath-test
REQUIRED_PROGS=( "${REQUIRED_PROGS[@]}" snapper chattr lsattr )
COPY_AS_IS=( "${COPY_AS_IS[@]}" /usr/lib/snapper/installation-helper /etc/snapper/config-templates/default )
BACKUP_PROG_INCLUDE=( /var/cache /var/lib/mailman /var/tmp /var/lib/pgsql /usr/local /opt /var/lib/libvirt/images /boot/grub2/i386-pc /var/opt /srv /boot/grub2/x86_64-efi /var/lib/mariadb /var/spool /var/lib/mysql /tmp /home /var/log /var/lib/named /var/lib/machines )
AUTOEXCLUDE_DISKS=n
AUTOEXCLUDE_MULTIPATH=n

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

    KVM guest.

  • 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 + GRUB.

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

    DM multipath disk with GPT.

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

    When recording information about a multipath disk, ReaR currently does not store information about its partition label type (file 280_multipath_layout.sh). Example multipath line:

    multipath /dev/mapper/0QEMU_QEMU_HARDDISK_0001 2147483648 /dev/sda,/dev/sdb

    During recovery, create_multipath() (210_load_multipath.sh) is used to process a single multipath definition. The function primarily calls create_partitions() (100_include_partition_code.sh) to create a label and partitions on the device. However, no label type is passed to create_partitions() which causes that the code tries to automatically detect the label type. This heuristics works as follows:

        ### List partition types/names to detect disk label type.
    local -a names=()
    local part size pstart name junk
    while read part disk size pstart name junk ; do
        names=( "${names[@]}" $name )
        case $name in
            (primary|extended|logical)
                if [[ -z "$label" ]] ; then
                    Log "Disk label for $device detected as msdos."
                    label="msdos"
                fi
                ;;
        esac
    done < <( grep "^part $device " "$LAYOUT_FILE" )

    The logic goes wrong if a multipath disk with GPT has a partition with a name set to exactly "primary", "extended" or "logical". In such a case, ReaR creates the MBR label on the restored disk instead of GPT.

    Note: Restoring normal disks does not rely on this heuristic because the partition label type is explicitly stored for them.

  • Workaround, if any:

    The problem can be avoided by using the gdisk or parted utility and renaming all GPT partitions with names "primary", "extended" or "logical" to something different.

jsmeix commented at 2019-09-13 11:13:

@setupji
thank you for your comprehensive issue report
together with your proposed fix in your
https://github.com/rear/rear/pull/2235
plus your workaround!

I see the relevant parted info is in
https://github.com/rear/rear/pull/2235#issue-316899745

jsmeix commented at 2019-10-18 10:08:

With https://github.com/rear/rear/pull/2235 merged
this issue should be fixed.

[Export of Github issue for rear/rear.]