#2281 Issue `closed`: Missing delete_dummy_partitions_and_resize_real_ones calls cause "rear recover" BugError¶

Labels: bug, cleanup, fixed / solved / done

musyl opened issue at 2019-11-22 09:44:¶

Relax-and-Recover (ReaR) Issue Template¶

Fill in the following items before submitting a new issue
(quick response is not guaranteed with free support):

ReaR version ("/usr/sbin/rear -V"):
Relax-and-Recover 2.5
OS version ("cat /etc/rear/os.conf" or "lsb_release -a" or "cat /etc/os-release"):
SUSE Linux Enterprise Server 12 SP4
ReaR configuration files ("cat /etc/rear/site.conf" and/or "cat /etc/rear/local.conf"):

BACKUP=NETFS
BACKUP_URL=nfs://naspnmksysb/mksysb/linux_lpars
ISO_MKISOFS_BIN="$( type -p mkisofs || type -p genisoimage )"
BACKUP_PROG_EXCLUDE=( "${BACKUP_PROG_EXCLUDE[@]}" '/tmp/*' '/var/lib/rear/output/*' '/media/*' '/hana/*' '/opt/coop/*' '/var/coop/*' '/home/*' '/var/mksysb/*' '/var/old_mksysb/*' '/dev/*' '/proc/*' '/run/*' '/syslink/*' '/var/instsoftw/*' '/usr/sap/*' '/opt/uniq/*' '/var/cisp/*' '/opt/ibm/cisp/*' '/opt/ixos/*' '/var/sapdaten*/*' '/var/DTA/*' '/var/svr*/*' '/var/universv/*' '/sapmnt/*' '/hana/data/STA/mnt00001/*' '/hana/shared/STA/*' '/hana/log/STA/mnt00001/*' )
BACKUP_PROG_INCLUDE=( '/*' '/var/lib/mysql/*' '/var/opt/*' '/home/' '/var/tmp/*' '/var/lib/pgsql/*' '/var/lib/machines/*' '/var/lib/libvirt/images/*' '/var/lib/mariadb/*' '/var/lib/named/*' '/var/patrol/*' '/usr/local/*' '/opt/*' '/etc/salt/*' '/tmp/*' '/root/*' '/var/log/*' '/boot/grub2/powerpc-ieee1275/*' '/var/lib/mailman/*' '/var/spool/*' '/srv/*' '/opt/ctm/*' '/opt/patrol/*' '/opt/teamquest/*')
BACKUP_ONLY_INCLUDE="yes"
COPY_AS_IS=( "${COPY_AS_IS[@]}" /etc/multipath/* )
COPY_AS_IS_EXCLUDE=( "${COPY_AS_IS_EXCLUDE[@]}" /dev/sd* /dev/mapper/mpath* /dev/mapper/*vg* /dev/mpath/\* /dev/dm-* /dev/sg* /dev/*_vg /dev/disk/\* /dev/block/\*  )
AUTOEXCLUDE_MULTIPATH=n
EXCLUDE_DEVICE_MAPPING=( "loop*" "ram*"  "dm-*" )
REAR_INITRD_COMPRESSION="lzma"
BOOT_OVER_SAN=y
ONLY_INCLUDE_VG=(sys_vg)

TIMESYNC=NTP
REQUIRED_PROGS=( "${REQUIRED_PROGS[@]}" snapper chattr lsattr )
COPY_AS_IS=( "${COPY_AS_IS[@]}" /usr/lib/snapper/installation-helper /etc/snapper/config-templates/default )
POST_RECOVERY_SCRIPT=( 'if snapper --no-dbus -r $TARGET_FS_ROOT get-config | grep -q "^QGROUP.*[0-9]/[0-9]" ; then snapper --no-dbus -r $TARGET_FS_ROOT set-config QGROUP= ; snapper --no-dbus -r $TARGET_FS_ROOT setup-quota && echo snapper setup-quota done || echo snapper setup-quota failed ; else echo snapper setup-quota not used ; fi' )

Hardware (PC or PowerNV BareMetal or ARM) or virtual machine (KVM guest or PoverVM LPAR):
PowerVM LPAR
System architecture (x86 compatible or PPC64/PPC64LE or what exact ARM device):
PPC64LE
Firmware (BIOS or UEFI or Open Firmware) and bootloader (GRUB or ELILO or Petitboot):
Open Firmware
Storage (local disk or SSD) and/or SAN (FC or iSCSI or FCoE) and/or multipath (DM or NVMe):
SAN-FC and multipath-DM
Description of the issue (ideally so that others can reproduce it):

rear recover failed. There are two entries in the disk_mappings file:

Current disk mapping table (source => target):
  /dev/mapper/360060e8007e39e000030e39e00000776 => /dev/mapper/360060e8007e39e000030e39e00000776
  /dev/mapper/360060e8007e39e000030e39e00000775 => /dev/mapper/360060e8007e39e000030e39e00000775

LUN 360060e8007e39e000030e39e00000776 is swap partition
LUN 360060e8007e39e000030e39e00000775 is system partition.

The first create_disk_label & create_disk_partition is OK but the second fails.

BUG in /usr/share/rear/lib/layout-functions.sh line 1078

It seems that there is a problem with the current_disk variable in the create_disk_label function.

Workaround, if any:
The possible workaround is to delete the line corresponding to the swap, restore the system partition and after the reboot recreate the swap.
Attachments, as applicable ("rear -D mkrescue/mkbackup/recover" debug log files):
rear-svrlsta101-0.log

To paste verbatim text like command output or file content,
include it between a leading and a closing line of three backticks like

++ create_disk_label /dev/mapper/360060e8007e39e000030e39e00000775 msdos
+++ local disk=/dev/mapper/360060e8007e39e000030e39e00000775 label=msdos
+++ [[ -n /dev/mapper/360060e8007e39e000030e39e00000776 ]]
+++ [[ /dev/mapper/360060e8007e39e000030e39e00000776 != \/\d\e\v\/\m\a\p\p\e\r\/\3\6\0\0\6\0\e\8\0\0\7\e\3\9\e\0\0\0\0\3\0\e\3\9\e\0\0\0\0\0\7\7\5 ]]
+++ BugError 'Current disk has changed from '\''/dev/mapper/360060e8007e39e000030e39e00000776'\'' to '\''/dev/mapper/360060e8007e39e000030e39e00000775'\'' without calling delete_dummy_partitions_and_resize_real_ones() first.'
+++ Error '

jsmeix commented at 2019-11-22 11:50:¶

@rmetrich
I dared to assign this issue also to you because
delete_dummy_partitions_and_resize_real_ones is your code.

jsmeix commented at 2019-11-22 12:29:¶

@musyl
before I try to dig around in your logs (as time permits)
I would like to know what output you get for the following commands:

lsblk -ipo NAME,KNAME,PKNAME,TRAN,TYPE,FSTYPE,SIZE,MOUNTPOINT

and

findmnt -a

to get an overview of your block devices and filesystems structure.

Furthermore please also attach your disklayout.conf file
that "rear mkrescue/mkbackup" had created
usually as var/lib/rear/layout/disklayout.conf

jsmeix commented at 2019-11-22 12:32:¶

@schabrolles
I also dared to assign this issue also to you because
it is about POWER architecture and multipath.

musyl commented at 2019-11-22 13:13:¶

Please find below the result of the commands requested.

findmnt.log
lsblk.log
disklayout_conf.txt

Thank you.

jsmeix commented at 2019-11-22 15:22:¶

On a quick first glance things look as follows to me:

The sequence of the create_... calls
(some create_device btrfsmountedsubvol are cut here):

# grep '+ create_' rear-svrlsta101-0.log

++ create_device /dev/mapper/360060e8007e39e000030e39e00000776 multipath
++ create_multipath /dev/mapper/360060e8007e39e000030e39e00000776
++ create_partitions /dev/mapper/360060e8007e39e000030e39e00000776 msdos
++ create_device /dev/mapper/360060e8007e39e000030e39e00000776-part1 part
++ create_device swap:/dev/mapper/360060e8007e39e000030e39e00000776-part1 swap
++ create_swap swap:/dev/mapper/360060e8007e39e000030e39e00000776-part1
++ create_device /dev/mapper/360060e8007e39e000030e39e00000775 multipath
++ create_multipath /dev/mapper/360060e8007e39e000030e39e00000775
++ create_partitions /dev/mapper/360060e8007e39e000030e39e00000775 msdos
++ create_device /dev/mapper/360060e8007e39e000030e39e00000775-part1 part
++ create_device /dev/mapper/360060e8007e39e000030e39e00000775-part2 part
++ create_device fs:/ fs
++ create_fs fs:/
++ create_device btrfsmountedsubvol:/ btrfsmountedsubvol
...
++ create_device btrfsmountedsubvol:/opt/patrol btrfsmountedsubvol
+++ create_component vgchange rear
+++ create_component /dev/mapper/360060e8007e39e000030e39e00000776 multipath
+++ create_disk_label /dev/mapper/360060e8007e39e000030e39e00000776 msdos
+++ create_disk_partition /dev/mapper/360060e8007e39e000030e39e00000776 primary 1 1048576 34360786943
+++ create_component /dev/mapper/360060e8007e39e000030e39e00000776-part1 part
+++ create_component swap:/dev/mapper/360060e8007e39e000030e39e00000776-part1 swap
+++ create_component /dev/mapper/360060e8007e39e000030e39e00000775 multipath
+++ create_disk_label /dev/mapper/360060e8007e39e000030e39e00000775 msdos

The functions where current_disk="$disk" is set are
in usr/share/rear/lib/layout-functions.sh
create_disk_label() and create_disk_partition()

The delete_dummy_partitions_and_resize_real_ones function
is only called in
usr/share/rear/layout/prepare/GNU/Linux/100_include_partition_code.sh
after the create_partitions call that calls create_disk_label
and for each partition on that disk create_disk_partition.

The sequence of only the create_disk_label
create_partitions and create_disk_partition
calls in rear-svrlsta101-0.log is

# grep '+ create_' rear-svrlsta101-0.log | egrep 'create_disk_label|create_partitions|create_disk_partition'

++ create_partitions /dev/mapper/360060e8007e39e000030e39e00000776 msdos
++ create_partitions /dev/mapper/360060e8007e39e000030e39e00000775 msdos
+++ create_disk_label /dev/mapper/360060e8007e39e000030e39e00000776 msdos
+++ create_disk_partition /dev/mapper/360060e8007e39e000030e39e00000776 primary 1 1048576 34360786943
+++ create_disk_label /dev/mapper/360060e8007e39e000030e39e00000775 msdos

which looks somehow wrong because I would expect to see

create_disk_label /dev/mapper/360060e8007e39e000030e39e00000775 msdos

before

create_partitions /dev/mapper/360060e8007e39e000030e39e00000775 msdos

and I think this wrong looking sequence is the reason why things fail.

I think it is right that "rear recover" errors out with that BugError because
I think the sequence how things are created could be wrong here.

But I am not at all a multipath expert so things could be rightfully
different when multipath is used?

jsmeix commented at 2019-11-22 15:29:¶

@musyl

only as a basically blind test because we have some recent fixes
regarding multipath in our current GitHub upstream master code
I would like to ask you to try out our current master code
as described in the section
"Testing current ReaR upstream GitHub master code" in
https://en.opensuse.org/SDB:Disaster_Recovery

Those recent fixes regarding multipath are
https://github.com/rear/rear/pull/2235
https://github.com/rear/rear/commit/0584c3287aade755bc2f4e4a70fffc8467b59eb8
which might make a difference here
and additionally
https://github.com/rear/rear/pull/2237
https://github.com/rear/rear/commit/84d74a3646c99f3a78a9b20ac57c5935af6c4888

jsmeix commented at 2019-11-25 08:59:¶

I think my "quick first glance" in my above
https://github.com/rear/rear/issues/2281#issuecomment-557574289
is a contradiction in itself because I wrote (excerpts)

the `create_partitions` call that calls `create_disk_label`
and for each partition on that disk `create_disk_partition`
...
I would expect to see
`create_disk_label ...`
before
`create_partitions ...`

but because create_partitions calls create_disk_label
the ordering create_partitions before create_disk_label is right.

So - as far as I see - for one same disk the expected ordering is

create_partitions
  |-> create_disk_label
  |-> create_disk_partition (first one on that disk)
  ...
  '->create_disk_partition (last one on that disk)
delete_dummy_partitions_and_resize_real_ones

But as far as I see now it seems this sequence of function calls
can run simultaneously for more than one disk at the same time
cf. in my above
https://github.com/rear/rear/issues/2281#issuecomment-557574289

# grep '+ create_' rear-svrlsta101-0.log | egrep 'create_disk_label|create_partitions|create_disk_partition'

++ create_partitions /dev/mapper/360060e8007e39e000030e39e00000776 msdos
++ create_partitions /dev/mapper/360060e8007e39e000030e39e00000775 msdos
+++ create_disk_label /dev/mapper/360060e8007e39e000030e39e00000776 msdos
+++ create_disk_partition /dev/mapper/360060e8007e39e000030e39e00000776 primary 1 1048576 34360786943
+++ create_disk_label /dev/mapper/360060e8007e39e000030e39e00000775 msdos

instead of the expected sequence

++ create_partitions /dev/mapper/360060e8007e39e000030e39e00000776 msdos
+++ create_disk_label /dev/mapper/360060e8007e39e000030e39e00000776 msdos
+++ create_disk_partition /dev/mapper/360060e8007e39e000030e39e00000776 primary 1 1048576 34360786943
++ create_partitions /dev/mapper/360060e8007e39e000030e39e00000775 msdos
+++ create_disk_label /dev/mapper/360060e8007e39e000030e39e00000775 msdos

With the intermixed sequence things can mess up
because the current_disk variable is a global variable
that is used as some kind of semaphore to
synchronize creating partitions on a disk.

jsmeix commented at 2019-11-25 09:10:¶

@rmetrich
I fear this issue here might reveal a possibly severe issue
since the create_partitions function in
layout/prepare/GNU/Linux/100_include_partition_code.sh
does no longer emit the actual parted calls directly but only
indircet function calls create_disk_label and create_disk_partition
which could somehow (I do not yet see how) lead to intermixed
creation of partitions on more than one disk at the same time?

rmetrich commented at 2019-11-25 09:31:¶

Hi @jsmeix,
I will try to have a look rapidly. Sorry, I'm very busy these months (hence my silence on many ReaR stuff).

jsmeix commented at 2019-11-25 09:38:¶

@rmetrich
thank you for your notification!

You really do not need to be sorry for being kept busy with other stuff.

For me it is basically the same, cf. my
https://github.com/rear/rear/issues/799#issuecomment-531247109
and I also know it is same for @schabrolles

jsmeix commented at 2019-11-25 10:03:¶

Currently I fail to see how device recreation things could run in parallel.

As far as I see by plain looking at the code all seems to happen sequentially.

Nowhere I spotted a subshell or something like that, starting at
layout/prepare/default/540_generate_device_code.sh
that calls create_device (in lib/layout-functions.sh)
that calls create_$type "$device" which is here

# cat rear-svrlsta101-0.log | grep '+ create_device'

++ create_device /dev/mapper/360060e8007e39e000030e39e00000776 multipath
++ create_device /dev/mapper/360060e8007e39e000030e39e00000776-part1 part
++ create_device swap:/dev/mapper/360060e8007e39e000030e39e00000776-part1 swap
++ create_device /dev/mapper/360060e8007e39e000030e39e00000775 multipath
++ create_device /dev/mapper/360060e8007e39e000030e39e00000775-part1 part
++ create_device /dev/mapper/360060e8007e39e000030e39e00000775-part2 part
++ create_device fs:/ fs
...

But I think I may have found something else:

In https://github.com/rear/rear/issues/2281#issuecomment-557574289
I wrote

The `delete_dummy_partitions_and_resize_real_ones` function
is only called in
usr/share/rear/layout/prepare/GNU/Linux/100_include_partition_code.sh
after the `create_partitions` call

I think it means delete_dummy_partitions_and_resize_real_ones
must be called after any create_partitions call
but that is not the case because create_partitions
is also called in two other scripts:

# find usr/sbin/rear usr/share/rear/ -type f | xargs grep 'create_partitions'

usr/share/rear/layout/prepare/GNU/Linux/120_include_raid_code.sh:    create_partitions "$device"
usr/share/rear/layout/prepare/GNU/Linux/210_load_multipath.sh:        create_partitions "$device" "$label"

therein in the create_raid and create_multipath functions.

@rmetrich
when my assumption is right
that delete_dummy_partitions_and_resize_real_ones
must be called after any create_partitions call
then it is perhaps best to add the
delete_dummy_partitions_and_resize_real_ones call
into the create_partitions function to ensure that
delete_dummy_partitions_and_resize_real_ones
is always called at the end of each create_partitions call?

But even if this is right it does not explain the unexpected
ordering of the create_... function calls in the log
that at least look as if there happens intermixed creation
of partitions on more than one disk at the same time.

musyl commented at 2019-11-25 10:29:¶

Thank you all for your help.

I followed the "Testing current ReaR upstream GitHub master code" procedure but the recovery fails by returning the same errors.

rear-svrlsta101-0.log

jsmeix commented at 2019-11-25 10:48:¶

@musyl
thank you for your feedback!

The next test with our current ReaR upstream GitHub master code
that you could try out is according to what I wrote in
https://github.com/rear/rear/issues/2281#issuecomment-558081653
to add a delete_dummy_partitions_and_resize_real_ones call
after the create_partitions call in
usr/share/rear/layout/prepare/GNU/Linux/210_load_multipath.sh
in the same way as it is currently done for the non-multipath case
usr/share/rear/layout/prepare/GNU/Linux/100_include_partition_code.sh
so that it will look like the following (excerpt)

function create_multipath() {
    ...
        create_partitions ...
        cat >> "$LAYOUT_CODE" <<EOF
delete_dummy_partitions_and_resize_real_ones
EOF
    fi
}

Then re-do "rear mkrescue/mkbackup" and afterwards
trest if now "rear recover" perhaps works for you.

If re-do "rear mkrescue/mkbackup" is too laborious or time consuming for you
you could - in particular for a test - also modify the ReaR scripts
from within the ReaR recovery system. To do that
boot the ReaR recovery system and log in as 'root'
and then - before you run "rear recover" - you can
modify any ReaR scripts as you like.
Cf. the section "Disaster recovery with Relax-and-Recover (ReaR)"

even temporary quick and dirty workarounds
are relatively easily possible

in https://en.opensuse.org/SDB:Disaster_Recovery

musyl commented at 2019-11-25 12:44:¶

I modified the script 210_load_multipath.sh

### Create multipath devices (at least partitions on them).
function create_multipath() {
    local component device size label junk
    read component device size label junk < <(grep "^multipath $1 " "$LAYOUT_FILE")
    if [[ "$device" ]]; then
        Log "Found current or former multipath device $device in $LAYOUT_FILE: Creating partitions on it"
        create_partitions "$device" "$label"
        cat  >> "$LAYOUT_CODE" <<EOF
        # Clean up transient partitions and resize shrinked ones
        delete_dummy_partitions_and_resize_real_ones
    fi
EOF
}

I performed a backup and then a recover, but the recover loop in the diskrestore.sh script.

rear-svrlsta101-0_20191125_1331.log

jsmeix commented at 2019-11-25 12:53:¶

Without checking your log I noticed in your
https://github.com/rear/rear/issues/2281#issuecomment-558139389
that you modified 210_load_multipath.sh falsely.
You need to have the EOF before the closing fi
i.e. you need to have

### Create multipath devices (at least partitions on them).
function create_multipath() {
    local component device size label junk
    read component device size label junk < <(grep "^multipath $1 " "$LAYOUT_FILE")
    if [[ "$device" ]]; then
        Log "Found current or former multipath device $device in $LAYOUT_FILE: Creating partitions on it"
        create_partitions "$device" "$label"
        cat  >> "$LAYOUT_CODE" <<EOF
# Clean up transient partitions and resize shrinked ones
delete_dummy_partitions_and_resize_real_ones
EOF
    fi
}

musyl commented at 2019-11-25 14:12:¶

Oups ! Excuse me ! I'm sorry I didn't see my mistake.
The recover worked but I see that the swap partition type is 'Linux' (0x83) and not 'Linux swap / Solaris' (0x82) as defined at installation.

jsmeix commented at 2019-11-25 14:57:¶

@musyl
thank you for your prompt replies!

Off the top of my head the swap partition type issue is normal
(I think I also had it on my test systems and it works nevertheless)
but feel free to report it as a new separated GitHub issue
so that we can have a closer look because ReaR should
recreate the system exactly as it was before (as far as possible).

musyl commented at 2019-11-26 07:45:¶

Thank you very much for your help. !!
Will the modification of script 210_load_multipath.sh be implemented in the next version of ReaR (2.6)?
Should I close the incident, or should I let you handle it?

jsmeix commented at 2019-11-26 08:31:¶

@musyl
my pleasure!

The fix for this issue will be included in ReaR 2.6 and
I will close this issue when its fix actually is in ReaR.

The fix of this issue will also include a fix for the create_partitions call
in prepare/GNU/Linux/120_include_raid_code.sh
cf. https://github.com/rear/rear/issues/2281#issuecomment-558081653

rmetrich commented at 2019-12-04 15:01:¶

Hi,
Sorry for taking so long, I'm very busy these weeks.
I'm very confused by the code, I don't understand why, when creating a software raid of multipath, we call create_partitions(), this will be done later anyway from my understanding.

rmetrich commented at 2019-12-04 15:06:¶

@musyl Could you provide the diskrestore.sh file generated based on disklayout.conf without any fix at all?

jsmeix commented at 2019-12-04 17:07:¶

@rmetrich
thank you for having a look.
That you are very confused by the code helps me a lot
because I do no longer think I am slow-witted here:
I am also confused by the code.

Perhaps my usual forensics method could also help here
(excerpts):

# git log -p --follow usr/share/rear/layout/prepare/GNU/Linux/210_load_multipath.sh

...

commit ad5bd0e889230e999e3669f0a21076b4d6aec2f2
Author: Sebastien Chabrolles ...
Date:   Fri Aug 25 17:54:33 2017 ...

    restore create_multipath function as we finally need it.
...
+### Create multipath devices (at least partitions on them).
+create_multipath() {
+    local multipath device
+    read multipath device junk < <(grep "multipath $1 " "$LAYOUT_FILE")
+
+    create_partitions "$device"
+}

....

commit 4344d1b6ae5d4e7010365ff939afac3f9d208d4c
Author: Sebastien Chabrolles ...
Date:   Thu Aug 24 19:53:22 2017 ...

    cleanup: remove useless create_multipath funtion
...
-### Create multipath devices (at least partitions on them).
-create_multipath() {
-    local multipath device
-    read multipath device junk < <(grep "multipath $1 " "$LAYOUT_FILE")
-
-    create_partitions "$device"
-}

...

commit 87c459a104335623347c629990c28d281bbc9256
Author: Jeroen Hoekx ...
Date:   Fri Mar 16 14:11:46 2012 ...

    layout: recreate partitions on multipath.
...
+### Create multipath devices (at least partitions on them)
+create_multipath() {
+    local multipath device
+    read multipath device junk < <(grep "multipath $1 " $LAYOUT_FILE)
+
+    create_partitions "$device"
+}

But unfortunately those commits
https://github.com/rear/rear/commit/ad5bd0e889230e999e3669f0a21076b4d6aec2f2
https://github.com/rear/rear/commit/4344d1b6ae5d4e7010365ff939afac3f9d208d4c
https://github.com/rear/rear/commit/87c459a104335623347c629990c28d281bbc9256
tell nothing about why create_partitions is needed to be called
so my usual forensics method did not directly help here.

But the commits from @schabrolles at least mention
https://github.com/rear/rear/pull/1449
so perhaps therein is a reason that explains
why create_partitions must be called
separatedly in case of multipath.

The comments where create_multipath was removed and re-added are
https://github.com/rear/rear/pull/1449#issuecomment-324578476
https://github.com/rear/rear/pull/1449#issuecomment-324718692
https://github.com/rear/rear/pull/1449#issuecomment-324874100
https://github.com/rear/rear/pull/1449#issuecomment-325021108
where the latter reads (excerpt):

you are right regarding create_multipath()
function... we finally REALLY need it.
I do additional test which confirm
it cannot work without it (partition are not created)

So the question is why are partitions not created
in case of multipath when there is no create_multipath
function that calls create_partitions?

My blind guess is that it may boil down to how the
dependency handling of the disk layout components
works in ReaR ( shudder ;-)

musyl commented at 2019-12-06 08:58:¶

@rmetrich
Hello, I uploaded the diskrestore.sh file.

diskrestore.sh.20191121165116.recover.12917.txt

rmetrich commented at 2019-12-06 09:13:¶

Thank you. This puzzles me. I don't understand why multipath and disk are considered different.
A multipath device is just a disk ...
Currently the code when having a multipath device is "old-style", explaining the issue. Probably create_multipath should call create_disk internally.

rmetrich commented at 2019-12-06 13:22:¶

I need to set up 2 reproducers:

a software raid
a multipath system

Both cases do not execute through create_disk, hence the failures.

rmetrich commented at 2019-12-06 15:43:¶

I could progress a bit today:

a software raid CAN have partitions, /dev/mdXXX is a standard block device

But I doubt a multipath device may have (except the underlying disk of course).

rmetrich commented at 2019-12-06 15:58:¶

I should have something on monday. Ping me if nothing comes up :-)

rmetrich commented at 2019-12-09 08:41:¶

@musyl Please check my code in PR #2295 on your system, I've tested in my lab on Software Raid and Multipath.

musyl commented at 2019-12-09 15:49:¶

@rmetrich
It also works in my environment. Thank you so much.
FYI I uploaded:
disklayout.conf_20191208.txt
rear-svrlsta101-0.log_20191208.txt
diskrestore.sh_20191208.txt

jsmeix commented at 2019-12-13 12:59:¶

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

@rmetrich
thank you for your fix!
In particular because you did it regardless
that you have not much time to work on ReaR.

[Export of Github issue for rear/rear.]

#2281 Issue closed: Missing delete_dummy_partitions_and_resize_real_ones calls cause "rear recover" BugError¶