#183 Issue closed: parted complains with "Error: Partition doesn't exist"

Labels: fixed / solved / done

gdha opened issue at 2012-11-30 11:59:

During a recover exercise on SAN based disks I get an error during the partitioning:

+++ echo '2012-11-30 13:48:37 Erasing MBR of disk /dev/mapper/36001438005deb05d0000e00005c40000'
2012-11-30 13:48:37 Erasing MBR of disk /dev/mapper/36001438005deb05d0000e00005c40000
+++ dd if=/dev/zero of=/dev/mapper/36001438005deb05d0000e00005c40000 bs=512 count=1
1+0 records in
1+0 records out
512 bytes (512 B) copied, 0.000169116 s, 3.0 MB/s
+++ sync
+++ LogPrint 'Creating partitions for disk /dev/mapper/36001438005deb05d0000e00005c40000 (msdos)'
+++ Log 'Creating partitions for disk /dev/mapper/36001438005deb05d0000e00005c40000 (msdos)'
+++ test 1 -gt 0
++++ Stamp
++++ date '+%Y-%m-%d %H:%M:%S '
+++ echo '2012-11-30 13:48:37 Creating partitions for disk /dev/mapper/36001438005deb05d0000e00005c40000 (msdos)'
2012-11-30 13:48:37 Creating partitions for disk /dev/mapper/36001438005deb05d0000e00005c40000 (msdos)
+++ Print 'Creating partitions for disk /dev/mapper/36001438005deb05d0000e00005c40000 (msdos)'
+++ test 1
+++ echo -e 'Creating partitions for disk /dev/mapper/36001438005deb05d0000e00005c40000 (msdos)'
+++ parted -s /dev/mapper/36001438005deb05d0000e00005c40000 mklabel msdos
+++ parted -s /dev/mapper/36001438005deb05d0000e00005c40000 mkpart primary 32768B 1069286911B
+++ parted -s /dev/mapper/36001438005deb05d0000e00005c40000 set 400001 boot on
Error: Partition doesn't exist.
2012-11-30 13:48:37 An error occured during layout recreation.

When we look on the devices with parted we see the following:

# parted /dev/mapper/36001438005deb05d0000e00005c40000
GNU Parted 1.8.8
Using /dev/mapper/36001438005deb05d0000e00005c40000
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) print
Model: Linux device-mapper (dm)
Disk /dev/mapper/36001438005deb05d0000e00005c40000: 322GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number  Start   End     Size    Type     File system  Flags
 1      32.8kB  1069MB  1069MB  primary  ext3         , , , , , , , , , type=83, ,

And when we look at one of the multipath devices with its physical name:

Model: HP HSV450 (scsi)
Disk /dev/sda: 322GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number  Start   End     Size    File system  Name     Flags
 1      32.8kB  1069MB  1069MB  ext3         primary  boot, , , , , , , , , , ,
 2      1069MB  322GB   321GB                primary  , , , , , lvm, , , , , ,

Before restarting the recovery we dd all devices belonging to dm-0

dd if=/dev/zero of=/dev/mapper/36001438005deb05d0000e00005c40000 bs=512 count=1
dd if=/dev/zero of=/dev/sda bs=512 count=1
...

but it still complains

gdha commented at 2012-11-30 13:53:

+++ parted -s /dev/mapper/36001438005deb05d0000e00005c40000 set 400001 boot on
Error: Partition doesn't exist

the 400001 should be a 1 ! The layout code somehow wrongly converted this.

gdha commented at 2012-12-21 09:01:

Digging into the code for this issue (script layout/prepare/GNU/Linux/10_include_partition_code.sh) and the lines of interest producing above mentioned lines are:

        # Get the partition number from the name
        local number=$(echo "$partition" | grep -o -E "[0-9]+$")

Simulating the input as follows:

$ partition=/dev/mapper/36001438005deb05d0000e00005c400001
$ echo "$partition" | grep -o -E "[0-9]+$"
400001

Under normal circumstances we give the following entries as input:

$ partition=/dev/cciss/c0d0p1
$ echo "$partition" | grep -o -E "[0-9]+$"
1

@jhoekx : how shall we fix this? Cutting the last 2 digits?

jhoekx commented at 2012-12-21 09:15:

No, that is too much of a hack :-)

What is the normal path of one of the partitions?

gdha commented at 2012-12-21 10:26:

@jhoekx In the following gist several input files are listed so you've get an idea of how the diskrestore.sh script was created:

https://gist.github.com/4351993

jhoekx commented at 2012-12-21 10:40:

I see, that leaves us no choice at all if we want to support that. So go ahead and add the cut. I think we also need to strip leading zeros.

gdha commented at 2013-01-22 13:14:

Need to review the code as input device name does not have any indication of a partition layout yet...need some more thoughts.

gdha commented at 2013-01-25 08:46:

I think the problem we have with SAN disks is due to missing code in layout/prepare/default/32_apply_mappings.sh
The case statement does not cope with SAN disks (yet):

# Replace all replacements with their target
while read source target junk ; do
    replacement=$(get_replacement "$source")
    # Replace whole device
    sed -i -r "\|$replacement|s|$replacement\>|$target|g" $LAYOUT_FILE
    # Replace partitions
    case "$target" in
        *rd[/!]c[0-9]d[0-9]|*cciss[/!]c[0-9]d[0-9]|*ida[/!]c[0-9]d[0-9]|*amiraid[/!]ar[0-9]|*emd[/!][0-9]|*ataraid[/!]d[0-9]|*carmel[/!][0-9])
            target="${target}p" # append p between main device and partitions
            ;;
    esac
    sed -i -r "\|$replacement|s|$replacement([0-9]+)|$target\1|g" $LAYOUT_FILE

Therefore replacement disk /dev/mapper/36001438005deb05d0000e00005c40000 becomes /dev/mapper/36001438005deb05d0000e00005c400001 instead of /dev/mapper/36001438005deb05d0000e00005c40000_part1

Wow - it took a while to trace this one.

I'm not sure SAN disk devices are always presented this way? Can we assume /dev/mapper/ is an indication or not?

jhoekx commented at 2013-01-25 08:55:

If you are restoring to the same SAN LUN the replacement code shouldn't be triggered at all. If it is, that's the problem?

gdha commented at 2013-01-28 12:48:

it was a migration from a (source) system with cciss-internal disk to a (target) system with only SAN-disk(s)

dagwieers commented at 2013-02-01 15:49:

@gdha I have never seen anything other than the following convention:

  • If the blockdevice ends with a letter, add the partition number
  • If the blockdevice ends with a number, add 'p' followed by the partition number

So disk /dev/mapper/36001438005deb05d0000e00005c40000 has first partition /dev/mapper/36001438005deb05d0000e00005c40000p1

gdha commented at 2013-03-10 12:00:

The mail thread of http://pikachu.3ti.be/pipermail/rear-users/2013-February/002642.html gives some interesting background material for this issue.

ProBackup-nl commented at 2017-04-14 18:47:

@gdha In ReaR 2.00 git there is still a similar issue for sd to nvme device migrations.
The source drive device was named: /dev/sda
The target drive device is named: /dev/nvme0n1

rear recover tries to:
+++ parted -s /dev/nvme0n1 set 11 boot on

The 11 should be a 1.

disklayout.conf (shortened) lists:

...
part /dev/nvme0n1 1G 4M EFIboot boot /dev/nvme0n11
part /dev/nvme0n1 172G 107G root none /dev/nvme0n12
...

[Export of Github issue for rear/rear.]