During restoration, the above boot entries were cleaned and therefore failed to generate.
Please see Clonezilla log files extract below :
********.
Updating boot entry of EFI NVRAM...
EFI system partition: /dev/mmcblk0p1
Trying to clean unused uEFI boot entry if it exists... *Boot file /EFI/UBUNTU/GRUBX64.EFI does not exist in partition /dev/mmcblk0p1.
Clean the boot entry 0000 by:
Running: efibootmgr -b 0000 -B ********. *Boot file /EFI/BOOT/BOOTX64.EFI does not exist in partition /dev/mmcblk0p1.
Clean the boot entry 0002 by:
Running: efibootmgr -b 0002 -B ***********.
I highlighted the directories below because these 2 files do not exist in my disk:
/EFI/UBUNTU/GRUBX64.EFI
/EFI/BOOT/BOOTX64.EFI
Please see my directory tree for /boot/efi/ as below :
/boot/efi
├── EFI
│ └── ubuntu
│..............└── grub.cfg
├── grub
│........├── grub.cfg
│........└── grubenv
├── grubx64.efi
├── initrd
├── shellx64.efi
└── vmlinuz
My question is :
1. Why did Clonezilla went searching for the files /EFI/UBUNTU/GRUBX64.EFI & /EFI/BOOT/BOOTX64.EFI
2. Why didn't Clonezilla follow the bootloader locations captured in efi-nvram.dat ? For example for Boot0000 (/boot/efi/grubx64.efi) and for Boot0002 (/boot/efi/vmlinuz initrd=/initrd)
Thanks in advanced.
Last edit: Ek Han Heng 2021-10-04
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Steven, I've tried using 2.7.3-19 and the boot entries were not generated even though Clonezilla does capture it in efi-nvram.dat.
Please note that I've did both image capture and restore using 2.7.3-19.
I'm attaching the efi-nvram.dat and clonezilla.log files for your reference.
I do notice some slight changes to the log files but at the end Boot0000 and Boot0002 fails to generate.
********.
Updating boot entry of EFI NVRAM...
EFI system partition: /dev/mmcblk2p1
Trying to clean unused uEFI boot entry if it exists...
[1;33mNo partition boot entry from hard drive exists in EFI NVRAM.
[0;39mEFI boot entries on this system: *******.
BootCurrent: 0004
Timeout: 1 seconds
BootOrder: 0004,0005
Boot0004 UEFI: InnodiskUSB Drive 3ME 0917, Partition 1 PciRoot(0x0)/Pci(0x1d,0x0)/USB(0,0)/USB(3,0)/USB(2,0)/USB(2,0)/HD(1,MBR,0x18cecda,0x800,0x1e37800)..BO
Boot0005 UEFI: IP4 Intel(R) I210 Gigabit Network Connection PciRoot(0x0)/Pci(0x1c,0x3)/Pci(0x0,0x0)/MAC(0030d624cbe1,1)/IPv4(0.0.0.00.0.0.0,0,0)..BO **********.
[1;31mEFI boot file in partition /dev/mmcblk2p1 was NOT found.
Therefore I believe question (2) still applies :
1. Why did Clonezilla went searching for the files /EFI/UBUNTU/GRUBX64.EFI & /EFI/BOOT/BOOTX64.EFI
2. Why didn't Clonezilla follow the bootloader locations captured in efi-nvram.dat ? For example for Boot0000 (/boot/efi/grubx64.efi) and for Boot0002 (/boot/efi/vmlinuz initrd=/initrd)
Looking forward to your advise.
Thanks in advanced.
That said, I'm sure you are already familiar with efibootmgr and probably already implement it inside Clonezilla.
I'm just not sure why didn't Clonezilla just go ahead and re-create the boot entries since it is already captured in efi-nvram.dat ?
Much appreciated.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Please give testing Clonezilla live >= 2.8.0-19 or 20211019-* a try: https://clonezilla.org/downloads.php
This issue should have been improved.
Please let us know the results if you try it. Thanks.
Steven
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Steven, thanks for the reply and suggestion.
Anyway, regarding Ubuntu release, I think the maintainer will only create a new revision upon stable release.
Since the fix is only available in the testing version, can I enquire when is the estimated date for a new stable release incorporating this fix ?
Thanks in advanced.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I believe we will release another stable Clonezilla ive in a few weeks... If you can, please test the latest testing Clonezilla live, and report the results. If we collect enough info and think it's stable enough, we will promote it to stable release.
Thanks.
Steven
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you for your reply. Me and my colleagues are testing out the testing Clonezilla and will report anything irregular.
As a matter of fact, one of my colleague commented that the option "-j2" is missing in advanced mode when she is attempting to create an ISO image. She also mentioned that this option was available in previous Clonezilla version.
Can you please advise if the option was removed for any specific reason ?
Thanks in advanced.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Please give Clonezilla live >=2.8.0-23 or 20211103-* a try: https://clonezilla.org/downloads.php
The missing "-j2" should be shown now.
Please let us know the results. Thanks.
Steven
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello, I'm using clonezilla-live-2.7.1-22-amd64 to restore an image with below efi-nvram.dat.
(Please note that I've truncated Boot0003 since this is the location of the clonezilla-live.)
BootCurrent: 0003
Timeout: 1 seconds
BootOrder: 0000,0002,0003
Boot0000 GRUB HD(1,GPT,2319b787-f990-4a54-ab0f-6ab4e64950ea,0x800,0x1f800)/File(\grubx64.efi)
Boot0002 CLIENT OS 1 HD(1,GPT,2319b787-f990-4a54-ab0f-6ab4e64950ea,0x800,0x1f800)/File(\vmlinuz) .i.n.i.t.r.d.=./.i.n.i.t.r.d.
During restoration, the above boot entries were cleaned and therefore failed to generate.
Please see Clonezilla log files extract below :
********.
Updating boot entry of EFI NVRAM...
EFI system partition: /dev/mmcblk0p1
Trying to clean unused uEFI boot entry if it exists...
*Boot file /EFI/UBUNTU/GRUBX64.EFI does not exist in partition /dev/mmcblk0p1.
Clean the boot entry 0000 by:
Running: efibootmgr -b 0000 -B
********.
*Boot file /EFI/BOOT/BOOTX64.EFI does not exist in partition /dev/mmcblk0p1.
Clean the boot entry 0002 by:
Running: efibootmgr -b 0002 -B
***********.
I highlighted the directories below because these 2 files do not exist in my disk:
/EFI/UBUNTU/GRUBX64.EFI
/EFI/BOOT/BOOTX64.EFI
Please see my directory tree for /boot/efi/ as below :
/boot/efi
├── EFI
│ └── ubuntu
│..............└── grub.cfg
├── grub
│........├── grub.cfg
│........└── grubenv
├── grubx64.efi
├── initrd
├── shellx64.efi
└── vmlinuz
My question is :
1. Why did Clonezilla went searching for the files /EFI/UBUNTU/GRUBX64.EFI & /EFI/BOOT/BOOTX64.EFI
2. Why didn't Clonezilla follow the bootloader locations captured in efi-nvram.dat ? For example for Boot0000 (/boot/efi/grubx64.efi) and for Boot0002 (/boot/efi/vmlinuz initrd=/initrd)
Thanks in advanced.
Last edit: Ek Han Heng 2021-10-04
Please give the latest Clonezilla live a try, e.g., 2.7.3-19 or 2.8.0-9:
https://clonezilla.org/downloads.php
Steven
Hi Steven, I've tried using 2.7.3-19 and the boot entries were not generated even though Clonezilla does capture it in efi-nvram.dat.
Please note that I've did both image capture and restore using 2.7.3-19.
I'm attaching the efi-nvram.dat and clonezilla.log files for your reference.
I do notice some slight changes to the log files but at the end Boot0000 and Boot0002 fails to generate.
********.
Updating boot entry of EFI NVRAM...
EFI system partition: /dev/mmcblk2p1
Trying to clean unused uEFI boot entry if it exists...
[1;33mNo partition boot entry from hard drive exists in EFI NVRAM.
[0;39mEFI boot entries on this system:
*******.
BootCurrent: 0004
Timeout: 1 seconds
BootOrder: 0004,0005
Boot0004 UEFI: InnodiskUSB Drive 3ME 0917, Partition 1 PciRoot(0x0)/Pci(0x1d,0x0)/USB(0,0)/USB(3,0)/USB(2,0)/USB(2,0)/HD(1,MBR,0x18cecda,0x800,0x1e37800)..BO
Boot0005 UEFI: IP4 Intel(R) I210 Gigabit Network Connection PciRoot(0x0)/Pci(0x1c,0x3)/Pci(0x0,0x0)/MAC(0030d624cbe1,1)/IPv4(0.0.0.00.0.0.0,0,0)..BO
**********.
[1;31mEFI boot file in partition /dev/mmcblk2p1 was NOT found.
Therefore I believe question (2) still applies :
1. Why did Clonezilla went searching for the files /EFI/UBUNTU/GRUBX64.EFI & /EFI/BOOT/BOOTX64.EFI
2. Why didn't Clonezilla follow the bootloader locations captured in efi-nvram.dat ? For example for Boot0000 (/boot/efi/grubx64.efi) and for Boot0002 (/boot/efi/vmlinuz initrd=/initrd)
Looking forward to your advise.
Thanks in advanced.
Thanks for your feedback.
Sure, we will think about how to improve update-efi-nvram-boot-entry:
https://gitlab.com/stevenshiau/clonezilla/-/blob/master/sbin/update-efi-nvram-boot-entry
You are very welcome to provide patches.
Steven
Hi Steven, thanks.
My suggestion is to use efibootmgr after restoration since the NVRAM configuration is already captures in efi-nvram.dat
For example in the efi-nvram.dat file boot entries below:
Boot0000 GRUB HD(1,GPT,2319b787-f990-4a54-ab0f-6ab4e64950ea,0x800,0x1f800)/File(\grubx64.efi)
Boot0002 CLIENT OS 1 HD(1,GPT,2319b787-f990-4a54-ab0f-6ab4e64950ea,0x800,0x1f800)/File(\vmlinuz) .i.n.i.t.r.d.=./.i.n.i.t.r.d.
We could generate the NVRAM boot entries using below command:
efibootmgr -c -d /dev/mmcblk0 -p 1 -L "GRUB" -l "/grubx64.efi
efibootmgr -c -d /dev/mmcblk0 -p 1 -L "CLIENT OS 1" -l "/vmlinuz" --unicode " initrd=/initrd"
That said, I'm sure you are already familiar with efibootmgr and probably already implement it inside Clonezilla.
I'm just not sure why didn't Clonezilla just go ahead and re-create the boot entries since it is already captured in efi-nvram.dat ?
Much appreciated.
OK, got it. Thanks for your suggestion.
We will try to improve that in the future.
Steven
Please give testing Clonezilla live >= 2.8.0-19 or 20211019-* a try:
https://clonezilla.org/downloads.php
This issue should have been improved.
Please let us know the results if you try it. Thanks.
Steven
Hi Steven,
The testing Clonezilla live >= 2.8.0-19 manage to resolve this issue.
Many thanks !
I wish to ask though if the changes will be included in future Ubuntu releases ?
The current Ubuntu release is (3.35.2-1).
Once again, much appreciated.
OK, great. Thanks for your confirmation.
As for Ubuntu, well, it depends on Ubuntu's package maintainer.
If you want to use the one from DRBL/Clonezilla project, you can try this deb repository:
http://free.nchc.org.tw/drbl-core/
as what we have mentioned here:
https://drbl.org/installation/02-install-required-packages.php
Steven
Hi Steven, thanks for the reply and suggestion.
Anyway, regarding Ubuntu release, I think the maintainer will only create a new revision upon stable release.
Since the fix is only available in the testing version, can I enquire when is the estimated date for a new stable release incorporating this fix ?
Thanks in advanced.
I believe we will release another stable Clonezilla ive in a few weeks... If you can, please test the latest testing Clonezilla live, and report the results. If we collect enough info and think it's stable enough, we will promote it to stable release.
Thanks.
Steven
Hi Steven,
Thank you for your reply. Me and my colleagues are testing out the testing Clonezilla and will report anything irregular.
As a matter of fact, one of my colleague commented that the option "-j2" is missing in advanced mode when she is attempting to create an ISO image. She also mentioned that this option was available in previous Clonezilla version.
Can you please advise if the option was removed for any specific reason ?
Thanks in advanced.
Please give Clonezilla live >=2.8.0-23 or 20211103-* a try:
https://clonezilla.org/downloads.php
The missing "-j2" should be shown now.
Please let us know the results. Thanks.
Steven
Hi Steven, thanks for addressing the missing "-j2".
We've tried out Clonezilla 2.8.0-23 and verified that the option is now present.
Much appreciated.
Great. Thanks for confirming that.
Steven