#275 Bug with matching codes for extended partitions

[Alan Rooks]

Clonezilla Live 2.5.2-17

I am using Clonezilla Live to image and duplicate disks that are part of Linux Software RAID1 arrays (using mdadm). I image one of the RAID1 physical disks, restore the image to one of the disks in a new machine, and then let Linux's md subsystem sync the 2nd disk in the RAID1 array in the new machine.

That works fine with an old Clonezilla Live 2.4.5-23 DVD-ROM that I have, but I found that Clonezilla Live 2.5.2-17 would not clone the partitions of the disk that are Linux software RAID partitions; Clonezilla seemed to think that those partitions were extended partitions, and it just created a 512-byte <part>-ebr file for them.

At first I thought that the problem was due to the new Clonezilla Live's kernel containing md_mod and the raid* modules. Unlike 2.4.5, when I boot 2.5.2 I can see that the Live kernel has assembled my RAID1 arrays automatically. I thought that maybe Clonezilla thought that the physical partitions for the RAID1 arrays were busy and that was why it wouldn't image them, so I used modprobe.blacklist on the kernel boot line to remove those modules; then the RAID1 arrays were not built, but Clonezilla still would not recognize my RAID partitions as data partitions to image. As an aside, it wouldn't show those partitions to me as places in which I might want to store images, either - they were not being recognized as data partitions at all.

I eventually tracked down the problem: it is the way that the partition codes for extended partitions are being matched, in the /usr/share/drbl/sbin/ocs-functions library of shell functions. The extended partitions have one-byte codes with values 0x05 and 0x0F, which are reported by ocs-get-part-info (or the underlying programs like blkid or lsblk or parted or partclone.fstype) without leading zeroes, as "0x5" and "0xf". Then those values are matched with grep or case statements, and the bug is that my Linux RAID partitions have a partition code of 0xfd, which matches 0xf!

There is similar code in ocs-get-part-info, but it directly tests "0x5" and "0xf" for equality with the returned partition code value, so that logic works fine ("0xfd" is not equal to "0xf"). But there are 4 places in ocs-functions that match with grep -Ei, so those can be fixed by putting the word-start and word-end anchors into the pattern, like this: grep -Ei "\<(swap|extended|0x5|0xf)\>". And there are 2 places in ocs-functions that use case statements to match; I think that the easiest fix for those is to switch them to use grep -Ei like the other places.

I implemented those 6 changes in ocs-functions file of the booted filesystem of my Clonezilla 2.5.2-17, and then everything worked fine again (even when the RAID1 arrays were assembled and running, but not mounted). The RAID1 partitions were also recognized as options for storing images (although of course I didn't want to store my images there!).

I believe that this is the underlying cause of bug #273, by the way. I looked briefly to see whether this bug had already been reported (and didn't see it directly), and it looked like #273 was also about Linux RAID partitions not being imaged.

[Steven Shiau]

Thank you for reporting this issue. Could you please send the patched files to me:
steven at clonezilla org
Appreciate.

Steven

[Steven Shiau]

This bug should have been fixed in Clonezilla live >= 2.5.2-20 or 20170724-*:
http://clonezilla.org/downloads.php
Feel free to reopen this bug if this issue remains.
Please give it a try and let us know the results. Thanks.

Steven

[Alan Rooks]

Looks good to me. The -w option to grep is a simpler solution than putting \< and > in the patterns, so nicely done.

[Steven Shiau]

Great! Thanks for confirming that.

Steven