Hugo van den Brand

Dear all, I have finally identified the cause of my problem. On the newest image the fallback.efi was named fbx64.efi. As a consequence, BOOTX64.efi tried to start grubx64.efi that was not present. The solution for me was to copy fbx64.efi to fallback.efi. And I need to search if this issue is known for CentOS 7.3.1611. However, this means that it is not a Clonezilla issue for me. Best wishes, Hugo

Hi Jeonkwan, I am also looking in to this issue again. I was able to recreate the booting problem by clearing all boot entries using efibootmgr. Then the uefi booting reverts to the default \EFI\BOOT\grubx64.efi that is not present. I actually saw the problem pop up three times in new fresh systems. Maybe that is also a difference between your systems? I have one centos image which restores the correct efi boot table. If I run this the efi boot table is restored and afterwards I can restore other...

Hi Steven, Thank you fior response. Unfortunately I jsut saw it a few days ago. Version 2.5.4-5 is still a testing version. Are these improvements also expected in the latest stable version (2.5.2-31) ? I also noticed that I need to boot the system before installing the second image. Could also point me to the relatedd issue? Best wishes, Hugo

Dear all, I use Clonezilla Live to make an image on an USB and restore it in an unattended restore to a headless computer. I experienced something very strange in restoring an image using Clonezilla Live 2.5.0-25-amd64. I made an image on 2017-09-22 (let's call it Image1) and one on 2017-11-08 (let's call it Image2). Both are from the same CentOS7 system. In the meantime I change some unrelated files and did an update (yum update). It could be that I even updated grub. When I restored Image2 the...