#263 Issue closed: RHEL4 Disk layout problems

Labels: bug

lpouellet opened issue at 2013-06-27 20:07:

Hi
First post,new user, be gentle ;)
First I have to express myself... Rear is the best thing since sliced bread.

Ok now to serious things.

Source server is running : Red Hat Enterprise Linux ES release 4 (Nahant Update 9)
Restoring on a proliant dl380 G4

I hit 2 problems during restore:

  1. Error: Expecting a partition number.

Comes from +++ parted -s /dev/cciss/c0d0 set /dev/cciss/c0d0p3 on
why does the "set" is passed a partion instead of only its id?
Temporary fix was to comment out the set.
This happens for all paritions to be created

  1. Error: Can't create any more partitions.
+++ echo -e 'Creating partitions for disk /dev/cciss/c0d0 (msdos)'
+++ parted -s /dev/cciss/c0d0 mklabel msdos
+++ parted -s /dev/cciss/c0d0 mkpart primary 0 509
+++ parted -s /dev/cciss/c0d0 mkpart primary 509 100716
+++ parted -s /dev/cciss/c0d0 mkpart primary 100716 220165
+++ parted -s /dev/cciss/c0d0 mkpart primary 220165 220165
+++ parted -s /dev/cciss/c0d0 mkpart logical 220165 264263

problem was fixed by replacing
+++ parted -s /dev/cciss/c0d0 mkpart primary 220165 220165
by
+++ parted -s /dev/cciss/c0d0 mkpart extended 220165 264263

After fixing these issues the Disk layout completes and restore starts.

Any advice for a permanent fix?

lpouellet commented at 2013-06-27 20:37:

Running 1.13 , same issue with 1.14

jhoekx commented at 2013-06-28 13:33:

Could you post disklayout.conf?

lpouellet commented at 2013-06-28 13:36:

[root@mtl-mon02d ~]# sfdisk -l

Disk /dev/cciss/c0d0: 35132 cylinders, 255 heads, 32 sectors/track
Warning: extended partition does not start at a cylinder boundary.
DOS and Linux will interpret the contents differently.
Warning: The partition table looks like it was made
  for C/H/S=*/255/63 (instead of 35132/255/32).
For this listing I'll assume that geometry.
Units = cylinders of 8225280 bytes, blocks of 1024 bytes, counting from 0

   Device Boot Start     End   #cyls    #blocks   Id  System
/dev/cciss/c0d0p1   *      0+     64      65-    522081   83  Linux
/dev/cciss/c0d0p2         65    6438    6374   51199155   83  Linux
/dev/cciss/c0d0p3       6439   14036    7598   61030935   83  Linux
/dev/cciss/c0d0p4      14037   17843    3807   30579727+   5  Extended
/dev/cciss/c0d0p5      14037+  16841    2805-  22531131   83  Linux
/dev/cciss/c0d0p6      16842+  17582     741-   5952051   83  Linux
/dev/cciss/c0d0p7      17583+  17843     261-   2096451   82  Linux swap

Disk /dev/cciss/c0d1: 70265 cylinders, 255 heads, 32 sectors/track
Units = cylinders of 4177920 bytes, blocks of 1024 bytes, counting from 0

   Device Boot Start     End   #cyls    #blocks   Id  System
/dev/cciss/c0d1p1          0+   9804    9805-  40004384   83  Linux
/dev/cciss/c0d1p2       9805   14707    4903   20004240   83  Linux
/dev/cciss/c0d1p3      14708   22061    7354   30004320   83  Linux
/dev/cciss/c0d1p4      22062   70264   48203  196668240    5  Extended
/dev/cciss/c0d1p5      22062+  22541     480-   1958384   82  Linux swap
[root@mtl-mon02d ~]#

Disklayout.conf

[root@mtl-mon02d ~]# cat /var/lib/rear/layout/disklayout.conf 
disk /dev/cciss/c0d0 146778685440 msdos
part /dev/cciss/c0d0 534610944 32256 primary boot /dev/cciss/c0d0p1
part /dev/cciss/c0d0 52427934720 534643200 primary none /dev/cciss/c0d0p2
part /dev/cciss/c0d0 62495677440 52962577920 primary  /dev/cciss/c0d0p3
part /dev/cciss/c0d0 1024 115458255360 primary  /dev/cciss/c0d0p4
part /dev/cciss/c0d0 23071878144 115458287616 logical  /dev/cciss/c0d0p5
part /dev/cciss/c0d0 6094900224 138530198016 logical  /dev/cciss/c0d0p6
part /dev/cciss/c0d0 2146765824 144625130496 logical  /dev/cciss/c0d0p7
disk /dev/cciss/c0d1 293564211200 msdos
part /dev/cciss/c0d1 40964489216 16384 primary none /dev/cciss/c0d1p1
part /dev/cciss/c0d1 20484341760 40964505600 primary  /dev/cciss/c0d1p2
part /dev/cciss/c0d1 30724423680 61448847360 primary  /dev/cciss/c0d1p3
part /dev/cciss/c0d1 1024 92173271040 primary  /dev/cciss/c0d1p4
part /dev/cciss/c0d1 2005385216 92173287424 logical  /dev/cciss/c0d1p5
   # disk /dev/hda 4294965248 
fs /dev/cciss/c0d0p2 / ext3 uuid=32d48876-172e-4a2d-8a08-a1689f124622 label=/1 blocksize=4096 reserved_blocks=4% max_mounts=-1 check_interval=0d options=rw
fs /dev/cciss/c0d0p1 /boot ext3 uuid=4a5fb3aa-157b-45e1-b9b0-a99ebefc12c5 label=/boot blocksize=1024 reserved_blocks=5% max_mounts=-1 check_interval=0d options=rw
fs /dev/cciss/c0d0p6 /opt/wily ext3 uuid=aa47a3fa-23df-4b40-836d-9dc521041708 label=/opt/wily1 blocksize=4096 reserved_blocks=4% max_mounts=-1 check_interval=0d options=rw
fs /dev/cciss/c0d0p5 /tmp ext3 uuid=d43f10e8-e2c6-4c18-b985-add8b95901a1 label=/tmp1 blocksize=4096 reserved_blocks=4% max_mounts=-1 check_interval=0d options=rw
fs /dev/cciss/c0d0p3 /var ext3 uuid=eb8abd2f-7611-4f04-98a5-60108a79e0a6 label=/var1 blocksize=4096 reserved_blocks=4% max_mounts=-1 check_interval=0d options=rw
fs /dev/cciss/c0d1p3 /opt/wiki ext3 uuid=70655892-51bf-46cd-b50b-71f95f19c413 label=/opt/wiki blocksize=4096 reserved_blocks=5% max_mounts=23 check_interval=180d options=rw
fs /dev/cciss/c0d1p1 /home ext3 uuid=570f2476-70c1-462a-8017-2fbdd218b230 label=/home blocksize=4096 reserved_blocks=4% max_mounts=20 check_interval=180d options=rw
fs /dev/cciss/c0d1p2 /opt/wily/data ext3 uuid=4fd958cc-36a2-468f-95bc-b7784628a211 label= blocksize=4096 reserved_blocks=5% max_mounts=26 check_interval=180d options=rw
swap /dev/cciss/c0d1p5 uuid= label=
swap /dev/cciss/c0d0p7 uuid= label=
logicaldrive /dev/cciss/c0d0 1|A|1 raid=1 drives=2I:1:1,2I:1:2, spares=1I:1:6, sectors=32 stripesize=128
logicaldrive /dev/cciss/c0d1 1|B|2 raid=5 drives=1I:1:5,2I:1:3,2I:1:4, spares=1I:1:6, sectors=32 stripesize=128
smartarray 1

dagwieers commented at 2013-06-28 23:08:

@lpouellet I improved the code for your first problem. We now moved the logic to get the partition number from the partition name to a separate function. And we also trap when for some reason we don't get an integer.

Now to test this on RHEL4, it would be nice if you could send the output of:

source usr/share/rear/lib/_input-output-functions.sh
source usr/share/rear/lib/layout-functions.sh
get_partition_number /dev/cciss/c0d0p3

It should return 3 :-)

dagwieers commented at 2013-06-28 23:19:

@lpouellet BTW We don't understand how the current or previous implementation can return /dev/cciss/c0d0p3 for the partition number. There should be no universe where echo "/dev/cciss/c0d0p3" | grep -o -E "[0-9]+$" returns more than an integer.

lpouellet commented at 2013-07-03 20:38:

@dagwieers RHEL4 test results.

[root@mtl-mon02d rear-master]# cat /etc/redhat-release
Red Hat Enterprise Linux ES release 4 (Nahant Update 9)

[root@mtl-mon02d rear-master]# get_partition_number /dev/cciss/c0d0p3
3
[root@mtl-mon02d rear-master]# get_partition_number /dev/cciss/c0d0p4
4
[root@mtl-mon02d rear-master]# get_partition_number /dev/cciss/c0d0p6
6
[root@mtl-mon02d rear-master]# get_partition_number /dev/cciss/c0d0p9
9
[root@mtl-mon02d rear-master]# get_partition_number /dev/cciss/c0d0p23
3
[root@mtl-mon02d rear-master]# get_partition_number /dev/cciss/c0d0p238
8
[root@mtl-mon02d rear-master]# get_partition_number /dev/cciss/c0d0p999
9
[root@mtl-mon02d rear-master]# get_partition_number /dev/cciss/c0d0p0
2013-07-03 16:37:12 ERROR: BUG BUG BUG! Partition number '0' of partition /dev/cciss/c0d0p0 is not a valid number.
......

Aborting due to an error, check for details
0

dagwieers commented at 2013-07-03 21:06:

Yup, that's the expected behavior. We only support up to 9 partitions as the code indicates. @jhoekx said this was a limitation in Relax-and-Recover in other places anyway. I don't mind to improve the code (and in the above case it's not that hard) however, in other cases (see examples in code) it is impossible to know for sure how many digits at the end represent the partition number. So we ended up not accepting anything other than 1 to 9.

BTW /dev/cciss/c0d0p0 is not a valid partition number ! Partition numbers start from 1, e.g. /dev/sda1 !

gdha commented at 2013-07-04 05:38:

@dagwieers @jhoekx If 9 partitions is hard limitation by rear then we better clearly state this in our documentation. Is there any reason why we don't go beyond the number 9 except for the fact we don't like 2 digit numbers?

dagwieers commented at 2013-07-04 07:32:

@gdha There's no dislike for 2 digit numbers, fact is that you cannot create a function that correctly get partition numbers for all cases. (There is no sane way to get the partition number for cases like: /dev/mapper/36001438005deb05d0000e00005c400001) Where exactly the other limitation of 9 partitions is, I don't know. (That said, I never encountered a system with more than 9 partitions these days since the general availability of LVM, usually there are only 1 or 2)

BTW Like I mentioned in #183, to me the above partition is not a valid partition name according to the kernel, it should have been /dev/mapper/36001438005deb05d0000e00005c40000p1 according to the rules. I don't know where that name comes from.

jhoekx commented at 2013-07-04 07:49:

The whole partitioning stuff is not nicely written anyway (and I say this having written it myself - twice). My decision to read the parted output was not good for old systems. One day I should add a code branch that uses sfdisk when the 'machine readable' parted output is not available. There are various problems all around, but I think the limitation is actually at most 8 partitions because of how extended partitions work.

gdha commented at 2013-07-04 08:21:

@jhoekx The GPT standard allows maximum of 128 partitions per disk
@dagwieers #183 - the code generated was not correct so I wouldn't bother too much with what was original written (by me)

jhoekx commented at 2013-07-04 08:30:

What I meant is the actual limitation inside ReaR is 8 partitions.

dagwieers commented at 2013-07-04 22:50:

@gdha Can you tell me what system has a partition named /dev/mapper/36001438005deb05d0000e00005c400001 instead of /dev/mapper/36001438005deb05d0000e00005c40000p1 ? Because I don't think it is a correct name for a partition... It would be easy if the example is wrong.

gdha commented at 2013-07-05 06:23:

@dagwieers I've checked my old notes and the disklayout file was beginning with:

disk /dev/mapper/36001438005deb05d0000e00005c40000 299959511040 gpt
part /dev/mapper/36001438005deb05d0000e00005c40000 1069254144 32256 primary boot /dev/mapper/36001438005deb05d0000e00005c40000_part1
part /dev/mapper/36001438005deb05d0000e00005c40000 321053293056 1069286400 primary lvm /dev/mapper/36001438005deb05d0000e00005c40000_part2

As I previously mentioned the code which produces the diskrestore.sh script contained a bug and the interpretation was incorrect somehow. However, I'm not sure it has been fixed as I couldn't test it anymore since then...

dagwieers commented at 2013-07-05 07:00:

@gdha Where did the device name /dev/mapper/36001438005deb05d0000e00005c400001 come from ? Is that device real or not.

gdha commented at 2013-07-05 07:14:

@dagwieers it was not a real device. It was the result of our code base not fully understanding devices that only contains numbers

dagwieers commented at 2013-07-05 07:40:

@gdha Perfect :-) A fix is on the way...

gdha commented at 2013-07-11 07:00:

@lpouellet has your issue been resolved by the fix of Dag? Please confirm.

dagwieers commented at 2013-07-11 23:25:

@gdha There are two issues in this report and we didn't tackle the second one. I looked at it, but it seems much more complicated than I had hoped it to be :-/ The problem seems to be tuned for the expertise of @jhoekx ;-)

gdha commented at 2013-08-09 10:26:

@jhoekx Do you have some spare cycles in the near future to have a look at issue 2?

jhoekx commented at 2013-08-09 10:40:

It's strange that we're not detecting it as an extended partition.

We'd need a rear -D savelayout logfile to know more.

gdha commented at 2013-09-03 11:14:

@lpouellet Can you send us the debug logfile as requested by @jhoekx ?

gdha commented at 2013-10-02 11:45:

@lpouellet is it Ok we close this issue? When we don't have a response within a month I'll close it automatically.

MarkusRoth commented at 2013-10-28 07:03:

@gdha Here is the output of rear -D savelayout of the RHEL system.
https://gist.github.com/MarkusRoth/7192428

gdha commented at 2013-10-28 07:57:

@MarkusRoth Think output of rear -D savelayout is missing

MarkusRoth commented at 2013-10-28 08:02:

Can't you access the link to the gist?

https://gist.github.com/MarkusRoth/7192428

gdha commented at 2013-10-28 08:06:

Yes, I can and I see the content of:

  1. Disklayout.conf
  2. df-txt
  3. diskdeps.conf
  4. disktodo.conf

However, I'm missing the debug output rear -D savelayout

On Mon, Oct 28, 2013 at 9:02 AM, MarkusRoth notifications@github.comwrote:

Can't you access the link to the gist?

https://gist.github.com/MarkusRoth/7192428


Reply to this email directly or view it on GitHubhttps://github.com/rear/rear/issues/263#issuecomment-27194382
.

MarkusRoth commented at 2013-10-28 08:20:

Sorry, I've actually forgotten the debug output :-(

Now it is attached in gist.


Von: gdha [notifications@github.com]
Gesendet: Montag, 28. Oktober 2013 09:06
An: rear/rear
Cc: Roth, Markus
Betreff: Re: [rear] RHEL4 Disk layout problems (#263)

Yes, I can and I see the content of:

  1. Disklayout.conf
  2. df-txt
  3. diskdeps.conf
  4. disktodo.conf

However, I'm missing the debug output rear -D savelayout

On Mon, Oct 28, 2013 at 9:02 AM, MarkusRoth notifications@github.comwrote:

Can't you access the link to the gist?

https://gist.github.com/MarkusRoth/7192428


Reply to this email directly or view it on GitHubhttps://github.com/rear/rear/issues/263#issuecomment-27194382
.


Reply to this email directly or view it on GitHubhttps://github.com/rear/rear/issues/263#issuecomment-27194541.

gdha commented at 2013-11-25 09:18:

@lpouellet I'll close this ticket as it is duplicate one (see issue #319)


[Export of Github issue for rear/rear.]