#2319 Issue `closed`: Recover Fails during Parted "Expecting partition Type"¶

Labels: support / question, fixed / solved / done

abbbi opened issue at 2020-01-21 09:45:¶

REAR: 2.5
SLES4SAP: SLES12 SP2

hi,

trying to recover a SLES4SAP System with Multipah SAN Setup fails because the diskrestore script
passes a wrong argument to parted. Following is the setup:

Multipath SAN setup
SLES4SAP installation with regular partitioning Sheme, no LVM is used for OS installation

The recovery of the first partition is OK, however, during the Second Partition
it passes the name of the Partition to the parted call and not the partition
type (primary/logical):

+++ parted -s /dev/mapper/mpatha mkpart ''\''mpatha-part2'\''' 268435456B 107374165503B
parted: invalid token: mpatha-part2
Error: Expecting a partition type

This can be work arounded by editing the diskrestore.sh and then recovery works.
Not sure if this is a known issue. What logfiles would be needed?
As the Logfiles are related to a System whose internal Configuration
should not be publlic, what Informations are needed?

Probably is an already known issue and was fixed already?

In the layout file following is to be seen:

multipath /dev/mapper/MYOS 107374182400 /dev/sda,/dev/sdae,/dev/sdak,/dev/sdaq,/dev/sdg,/dev/sdm,/dev/sds,/dev/sdy
part /dev/mapper/MYOS 251658240 16777216 primary boot /dev/mapper/OS-part1
part /dev/mapper/MYOS 107105730048 268435456 rear-noname none /dev/mapper/OS-part2

So it probably seems the "rear-noname" is the issue already?

jsmeix commented at 2020-01-21 11:02:¶

@abbbi
in general when full debug log files cannot be provided because
the user's system "internal" configuration should not be public
(what is "internal" configuartion - e.g. comparted to "external"?)
there is perhaps not much what we at ReaR upstream can do
so that you or the user may have to report his issue directly
to SUSE provided you or the user have an appropriate support
contract, cf. "SUSE support for Relax-and-Recover" at
https://en.opensuse.org/SDB:Disaster_Recovery

Nevertheless perhaps we can help:

Because you have the "old" multipath syntax in disklayout.conf before
https://github.com/rear/rear/commit/793d096a61b97334a2e9c3ac62077c7926ef41cf
I would first and foremost recommend to try out if things
behave better with our current ReaR upstream GitHub master code,
cf. "Testing current ReaR upstream GitHub master code" at
https://en.opensuse.org/SDB:Disaster_Recovery

When you try out our current ReaR upstream GitHub master code
you need to do both rear -D mkrescue/mkbackup and then
rear -D recover to use the new multipath syntax in disklayout.conf.

When you cannot try out our current ReaR upstream GitHub master code
do both rear -D mkrescue/mkbackup and then rear -D recover
and inspect the debug log files regarding rear-noname to find out
what goes on in relation to that.

The fallback value rear-noname appears in those scripts

usr/share/rear/layout/save/GNU/Linux/200_partition_layout.sh
that is run during rear -D mkrescue/mkbackup
usr/share/rear/layout/prepare/GNU/Linux/100_include_partition_code.sh
that is run during rear -D recover

In our current ReaR upstream GitHub master code at
https://github.com/rear/rear/blob/master/usr/share/rear/layout/save/GNU/Linux/200_partition_layout.sh#L170
we have this comment

# But on s390 'parted mkpart fs-type start end' requires a valid file system type
# so that the above fallback type="rear-noname" that gets during "rear recover"
# replaced with $(basename "$partition") via 100_include_partition_code.sh
# does not work on s390 and lets parted fail with "invalid token",
# see https://github.com/rear/rear/pull/2142#issuecomment-494742554
#   +++ parted -s /dev/dasda mkpart ''\''dasda1'\''' 98304B 314621951B
#   parted: invalid token: dasda1
#   Error: Expecting a file system type.
# Therefore we use a hardcoded fixed file system type 'ext2' as dummy for 'parted' which works
# because the real file systems are set up afterwards via 'mkfs' commands during "rear recover"
# and also YaST uses a fixed 'ext2' dummy file system type for 'parted mkpart' on s390,
# cf. https://github.com/rear/rear/pull/2142#issuecomment-494813151

which is about IMB Z (a.k.a. "s390") but it seems to be about
the same kind of issue where parted fails in the same way.

abbbi commented at 2020-01-21 12:14:¶

I can confirm that after replacing

part /dev/mapper/MYOS 107105730048 268435456 rear-noname none /dev/mapper/OS-part2

with

part /dev/mapper/MYOS 107105730048 268435456 primary none /dev/mapper/OS-part2

in the disklayout.conf, the recovery works without issue. I do currently not have the debug log from mkrescue, i will try to get it for you. Using master is out of scope currently unfortunately :)
OS is on Intel, so no special Power or S390.

jsmeix commented at 2020-01-21 15:37:¶

@abbbi
also check and report what kind of partitioning type
is used on the affected disk, e.g. provide the

parted -s /dev/XXX unit MiB print

output. If it shows "Partition Table: gpt" you may need recent fixes like
https://github.com/rear/rear/commit/793d096a61b97334a2e9c3ac62077c7926ef41cf

abbbi commented at 2020-01-22 09:25:¶

@jsmeix

On the system in question, the parted command does not print any type of information (primary or logical) for the partition in question,..:

/dev/mapper/OS:107GB:dm:512:512:gpt:Linux device-mapper (multipath):;
1:16.8MB:268MB:252MB:fat16:primary:boot;
2:268MB:107GB:107GB:btrfs::;

so probably the issue is related and already fixed with the newer commit you mentioned.

jsmeix commented at 2020-01-22 14:29:¶

@abbbi
your parted's "machine parseable output" in your
https://github.com/rear/rear/issues/2319#issuecomment-577088441
is hard to read for me (because - surprise - I am human - not a machine ;-)

I would prefer to get human readable output as in

parted -s /dev/XXX unit MiB print

cf. https://github.com/rear/rear/issues/2319#issuecomment-576738628

For comparison how things look for me on my openSUSE 15.0 system:

# parted -s /dev/sda unit MiB print

Model: ATA WDC WD10EZEX-75M (scsi)
Disk /dev/sda: 953870MiB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags:

Number  Start      End        Size       File system     Name  Flags
 1      1.00MiB    501MiB     500MiB     fat16                 boot, esp
 2      501MiB     937911MiB  937410MiB  ext4
 3      937911MiB  953870MiB  15959MiB   linux-swap(v1)        swap

and I get the same formatting also on SLES12 and older versions.

Because in your partitioning info in your
https://github.com/rear/rear/issues/2319#issuecomment-577088441
I can decipher gpt I think you need (at least) our recent
ReaR upstream fixes for multipath with GPT disks.

What is the reason why you cannot try out our
current ReaR upstream GitHub master code as described in
"Testing current ReaR upstream GitHub master code"
at
https://en.opensuse.org/SDB:Disaster_Recovery
I.e. what is the reason why you cannot

... have several ReaR versions in parallel
each one in its own separated directory
without conflicts between each other
and without conflicts with a normally
installed ReaR version via RPM package

?

jsmeix commented at 2020-06-16 07:54:¶

This issue is meanwhile fixed in our GhitHub master code
via https://github.com/rear/rear/pull/2235
and https://github.com/rear/rear/pull/2237
cf.
https://github.com/rear/rear/issues/2424#issuecomment-644281968

[Export of Github issue for rear/rear.]

#2319 Issue closed: Recover Fails during Parted "Expecting partition Type"¶