Menu

#127 Recovery Clonezilla fails during boot with Failed to load libcom32.c32 error

closed-fixed
None
5
2022-01-11
2019-08-21
No

It appears that the Recovery Clonezilla feature is not working anymore.
Two issues can be found there:

First, it always creates a tar file instead of zip, no matter whether I splitted the original image in 1024MB files (below the 2GB limit).

Second, it a appears to not copy all files necessary for the boot process. The error message of failing the copy the files appears for a very brief moment during the creation process.

Finally, when extracting the tar file to a usb stick and making it bootable by calling the makeboot batch script in the utils folder, booting from the stick fails with the following repeated error message:
Failed to load libcom32.c32
Failed to load COM32 file vesamenu.c32

Tested with stable - 2.6.2-15, alternative stable - 20190707-disco even testing for both 32bit and amd64.

The workaround I currently apply is to extract the recovery tar file to an existing regular clonzilla live stick. While this leads to a improper boot menu, the recovery process in general appears to work.

Don't hesitate to contact me for further details.

Kind regards,
Mathias

Discussion

  • Steven Shiau

    Steven Shiau - 2019-09-01

    Thanks for your feedback.
    Have you tried the latest testing Clonezilla live, i.e., >= 2.6.3-5 or 20190826-*?
    https://clonezilla.org/downloads.php
    If not, please give it a try and let us know the results. Thanks.

    Steven

     
  • Gustaf

    Gustaf - 2019-11-14

    This issue still exists.
    I tried both stable-2.6.4-10 and testing-2.6.4-11

    The problem seems to be some kind of version mismatch between the versio of syslinux that gets installed to the USB drive and the version of the *.c32 files that are copied to the USB drive.

    My workaround is to efter the USB drive is created with ocs-live-dev raplace all .c32 files on the usb with those from the live environment.

    mount USB on /mnt
    cd /mnt/syslinux
    FILES="$(find . -type f -name "*.c32")"
    for f in $FILES do echo "Copying $f"; cp /usr/lib/live/mount/medium/syslinux/$f /mnt/syslinux/$f;echo; done
    cd /
    umount /mnt
    

    //Gustaf

     
    • Robert Smith

      Robert Smith - 2020-05-06

      I'm having the same problem. I only replaced libcom32.c32 and vesamenu.c32 and it worked after that.

      update: I was using 'Legacy' boot mode before, I just switched to UEFI boot mode and it works fine without replacing those files.

       
      👍
      1

      Last edit: Robert Smith 2020-05-06
  • Steven Shiau

    Steven Shiau - 2019-12-01

    It seems I can not reproduce these two issues. The steps I have done:
    1. Boot Clonezilla live 2.6.5-1 amd64 iso on a VMWare virtual machine
    2. mount the image repository as /home/partimag
    3. Follow the following URL to choose recovery-iso-zip:
    https://clonezilla.org/show-live-doc-content.php?topic=clonezilla-live/doc/04_Create_Recovery_Clonezilla
    4. The image I choosed was a small image, 474 MB:

    # du -hs /home/partimag/xenial-x86-20190818-3/
    474M    /home/partimag/xenial-x86-20190818-3/
    
    1. The command in green is:
      PS. Next time you can run this command directly:
      ocs-live-dev -c -g en_US.UTF-8 -t -k NONE -e "-g auto -e1 auto -e2 -r -j2 -c -scr -p choose restoredisk xenial-x86-20190818-3 sda" xenial-x86-20190818-3
    2. The created zip file:
    # ls -alFh /home/partimag/*.zip
    -rw-r--r-- 1 root root 754M Dec  1 13:51 /home/partimag/clonezilla-live-xenial-x86-20190818-3.zip
    

    As you can see, it's a zip file, not tar file.
    7. I formatted /dev/sdb1 as vFAT partition, mount it as /mnt, run:

    unzip /home/partimag/clonezilla-live-xenial-x86-20190818-3.zip -d /mnt
    

    Then run:

    bash /mnt/utils/linux/makeboot.sh /dev/sdb1
    

    Then it ran smoothly. No errors.
    Please could you please try the similar steps? Thanks.

    Steven

     
  • Tom

    Tom - 2020-06-04

    I have the same problem with clonezilla-live-20200428-focal-amd64, the last time i used it was with clonezilla-live-20180812-bionic-amd64 and there it was working. Maybe it has something to do with lgegacy/UEFI boot if the problem comes up or not?

    This is what i get after an recovery ZIP was extracted to an USB flash drive and then when try to boot from that USB drive.

     

    Last edit: Tom 2020-06-04
  • Tom

    Tom - 2020-06-04

    Just tried with clonezilla-live-20200602-focal-amd64 - problem still present.

     
  • Steven Shiau

    Steven Shiau - 2020-06-07

    Please let us know the steps you have done to create such a zip file. It would be easier for us to reproduce this issue.
    Thanks.

    Steven

     
    • Tom

      Tom - 2020-06-07
      • Mode: Expert mode
      • Mode: recovery-iso-zip
      • Choose: some-image-file.img
      • Device: sda
      • Parameter: -e2 -icds -j2
      • Parameter: ‘use partition table from the image’
      • Parameter: Yes, check the image before restoring.
      • Parameter: -p poweroff
      • Parameter: en_US English
      • Parameter: NONE
      • Parameter: both
      • Verify: Make sure everything matches to the selection above.
      • Power off
       

      Last edit: Tom 2020-06-07
  • Steven Shiau

    Steven Shiau - 2020-06-09

    Finally we can reproduce this issue, so it's fixed now. Please give Clonezilla live >= 2.6.7-20 or 20200608-* a try:
    https://clonezilla.org/downloads.php
    Please tell us the results. Thanks.

    Steven

     
    • Tom

      Tom - 2020-06-12

      Hi Steven

      It works on my side - thank you for the quick fix.

      Something i have observerd:

      • In the past, i found a default menu came up, i was able to replace the background image and adjusted the menu items based on the original template. In the menu i had something like different resoutions, memtest+ and booting the original image.

      • Today i see, there is no menu anymore. There is just a short message saying "found restrore jobs in $somewhere" and then the restore starts.

      Would it be possible to restore the previous behaviour again or is this another support request from your point of view?

      Do you need additional informations to understand what i mean?

      Best regards
      Tom

       

      Last edit: Tom 2020-06-12
      • Steven Shiau

        Steven Shiau - 2020-06-12

        Hi Tom,
        Thanks for your feedback.
        "Today i see, there is no menu anymore. There is just a short message saying "found restrore jobs in $somewhere" and then the restore starts." -> There should have a menu. Could you please take a video or photo about that? It's easier for us to understand.

        Steven

         
        • Tom

          Tom - 2020-06-12

          Hi Steven

          My bad - sorry, the menu is there. Forget about it.

          Have a good weekend
          Tom

           
          • Steven Shiau

            Steven Shiau - 2020-06-13

            OK, great. Thanks for confirming that.

            Steven

             
  • Mister Creeky

    Mister Creeky - 2020-06-12

    I can confrim that 2.6.7-20 / 20200608 does NOT WORK if booted in BIOS mode, it does seem to work if booted in UEFI mode.

    So not fixed yet.

    If booted in Bios mode, it does exactly the same result as Tom pictured above. It just loops around not finding vesamenu and libcom files.

    This was the same setup as Tom, except we want to restore to larger drives so added option -r and -k1.

    Wrote to USB / Tar file (image is 18+GB WES7-32 NTFS image), then expanded that onto USB stick, used Win64 make boot utility using Win7-64 as build system.

    We like the recovery stuck option as it makes it easy for anyone to restore a production image onto a new drive with very little effort, and no options to get wrong.

     
  • Steven Shiau

    Steven Shiau - 2020-06-12

    Thanks for your feedback. Please tell us the exact steps you have done in detail, from the very beginning to the end, i.e., download the file, the steps to create the zip file, the way you put on the USB flash drive, and the error messages on the screen (a picture will be better) so that we can reproduce this issue here.
    Appreciate.

    Steven

     
  • Steven Shiau

    Steven Shiau - 2020-06-12

    BTW, please mount the USB flash drive on Linux, say in /mnt, then:
    1. cd /mnt/syslinux/
    2. md5sum *
    Please post the results of (2).
    Thanks.

    Steven

     
  • Mister Creeky

    Mister Creeky - 2020-06-12

    Steven - here you go. I already posted what I did in previous message, it was same as what user Tom did, restore parameters added option -r and -k1. Made Tar file. On Win7-64 machine expanded Tar file contents to FAT32-formated USB stick. Went to utils/Win64 and used makeboot64.bat to make stick bootable.

    1. Stick boots in BIOS mode: Looping around. There is also an Undef error too.

    2. Stck boot sin UEFI mode: Everything works as intended.

    This is all the same steps we use with CZ regular mode.

    Included screen shot and MD5 sums of syslinux folder, as requested.

     
  • Steven Shiau

    Steven Shiau - 2020-06-13

    @Mister Creeky,
    Tom has confirmed the fixed version (2.6.7-20, 20200608-*) works there.
    I compared the md5 checksums in the syslinux dir, and yours are different from what we have for 2.6.7-20, 20200608-* amd64, so I am wondering maybe you did not overwritten all of them?
    Please use another empty USB flash drive or format it before you put the restored zip file on that.

    Steven

     
  • Mister Creeky

    Mister Creeky - 2020-06-13

    As I said, I started with blank, FAT32 formatted USB drive. Copied on CZ files from the generated TAR. Used Makeboot64.bat.

    Just tried another blank, freshly formated stick. No difference.

    If I format the drive and install just regular CZ, it boots OK in regular BIOS mode. The recovery mode only in UEFI boot.

     

    Last edit: Mister Creeky 2020-06-13
  • Mister Creeky

    Mister Creeky - 2020-06-13

    By the way - it is Makeboot64 that alters syslinux/ ldlinux.c32. That's why the checksums don't match.

    This time I first extracted files from the generated TAR file to a folder on Win764 machine, and generated MD5 sums for all files in /syslinux.

    Copy all CZ file tree on a brand new formated USB stick, never been used.

    Go to syslinux directory and checksums all OK.

    Run Makeboot64.bat...it says ldlinux is installed and USB stick is bootable.

    Go check checksums again in syslinux directory - and now ldlinux.c32 is altered.

    I repeated this with two sticks, one NTFS and one FAT32 - same result. The mobo we're using will boot either format.

     
  • Mister Creeky

    Mister Creeky - 2020-06-13

    OK, got it. Confirmed working CZ 20200608 -groovy amd64.

    I went back and re-downloaded "groovy", rebuilt TAR file as before, and it is working. Not sure what happend with "focal", but it is working now - tried on both NTFS and FAT32 formated sticks (to which the TAR file is extracted to).

    Makeboot64 still does modiy ldlinux, but apperently that is correct behaviour.

    The syslinux directory on the generated TAR file has different checksums than syslinux on the original CZ download (since the TAR was built for recovery mode), but everything is working.

    Thanks!!

     

    Last edit: Mister Creeky 2020-06-14
  • Steven Shiau

    Steven Shiau - 2020-07-04
    • status: open --> closed-fixed
    • assigned_to: Steven Shiau
     
  • JasonC

    JasonC - 2022-01-11

    I have just used clonezilla-live-2.8.0-27-amd64.iso.
    Got the exact same error booting into Clonezilla.
    Failed to load libcom32.c32
    Failed to load COM32 file vesamenu.c32

     

    Last edit: JasonC 2022-01-11
  • Steven Shiau

    Steven Shiau - 2022-01-11

    It's fixed in the latest stable Clonezilla live 2.8.1-12. Please give it a try:
    https://clonezilla.org/downloads.php

    Steven

     
    👍
    1

Log in to post a comment.

Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.