Menu ▾ ▴

Possible bug with Clonezilla live on USB stick

Clonezilla live
GrahamB
2015-01-23
2015-01-24

  • GrahamB

    GrahamB - 2015-01-23

    There appears to be a long-standing problem that has been reported several times over several revisions, but never resolved as far as I can see.
    e.g.
    #1 MBR not restored properly jr1@writeme.com
    #161 windows mbr borked after disk to disk clone
    #187 MBR restore fail with CloneZilla on USB key with TuxBoot

    My experience today may help track the bug down, having had a similar problem myself.
    I needed to clone a fairly full 1TB drive with multiple partitions of Operating Systems, and Data. It was beginning to be unreliable, with SMART errors.
    I used clonezilla-live-2.3.1-18-i686-pae.zip, unzipped to a USB stick; and, from the stick, ran \utils\win32\makeboot.bat
    This worked perfectly, and made my USB stick bootable. Running a Linux system meant I didn't have the problem of Windows 'helpfully' trying to assign drive letters to all my partitions - not enough letters in the alphabet!
    I tried it on a small drive, again with several OS's, and copied the WHOLE DISK to a brand new 2TB drive, using the automatic 'skip checking/repair'. All appeared to go well, copying all the partitions, and the MBR (which contained details of some Primary Partions and an Extended Partition to hold several Logical Partitions). All appeared fine, except the cloned drive would not boot. Black screen, flashing cursor, no error messages.

    I tried my Windows Recovery DVD to repair the MBR and make it bootable, but no good. At this stage, I didn't know if the clone was bad, or my brand new drive was bad, or there were intermittent problems reading the (known-unreliable) source drive, or I had done something wrong. With nothing to lose, I used the Recovery DVD to do a full restore; this worked, over-writing my first partition in the process, and assigning it the drive letter C: But my original first partition (which was the boot partition but NOT drive C:) contained boot.ini, with details of my available operating systems, and this was of course lost. But my other partitions were intact, and I was able to re-enable them with some work (but not my first OS, of course).

    So, my new disk was not 'dead on arrival', and CloneZilla could be made to work with some effort.
    Of all the possible problems, Clonezilla seemed least likely to be bad - so I did an Interactively Check and Repair Source before Cloning' (skipping checking the NTFS partitions).

    As far as I can see, CloneZilla appears to correct any errors in the source, and write corrections to the source; I would prefer that it did not do this, without permission (unstoppable now!), just make the corrections to the DESTINATION only.

    After checking the source disk, CloneZilla offered to clone the executable boot loader (the first 446 bytes) as well as the partition table, which I accepted. I then copied 11 partitions, taking about 5 hours. Both disks were connected to the motherboard using SATA cables.
    The new disk refused to boot - just a black screen, with flashing cursor, and no error message - the same as before.

    I booted to a DOS USB stick to check the MBR; everything seemed sensible, but there were some extra bytes used in some of the (mostly zero) chunks. I was not sure if these were errors, or existed in the source disk too, as some form of copy protection; so I connected both drives and compared the first 63 sectors of both drives; the gash bytes were in both, but there were 5 other bytes in error, in the Cylinder/Head/Sector bytes for the Start and End locations for two of the partitions. I changed the 5 bytes to match the source disk, and tried to reboot.
    EVERYTHING WORKED - all my partitions, and boot choices were restored.

    Each partition uses 3 bytes to define the Cylinder/Head/Sector values for its start, and 3 for its stop. The 24 bits are split into 8 (head), 10 (Cylinder) and 6 (Sector). Because of the BigEndian/LittleEndian fiasco, the mapping is not straightforward!

    My clone was done using Live on USB, like Bug Report #187 'MBR restore fail with CloneZilla on USB key with TuxBoot'; the user reports that it only failed with a USB stick, whereas the same release on CD worked fine.
    Is the same CHS mapping algorithm used for the CD and the USB stick versions?

    I searched Sourceforge for the source code to see if I could spot the problem, but without success; is the source available?

     

Log in to post a comment.

MongoDB Logo MongoDB