#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.]