Clonezilla 20180812-bionic bricked Dell Optiplex 3060 computers
A partition and disk imaging/cloning program
Brought to you by:
steven_shiau
Menu
▾
▴
#310 Clonezilla 20180812-bionic bricked Dell Optiplex 3060 computers
We have used “Clonezilla 20180812-bionic” to restore an SSD image for a couple of Dell Optiplex 3060.
The computers had uEFI secure boot enabled.
The restore process completed without error. However, after the reboot, the computers were hanging showing only the Dell logo on the screen.
No chance to go into bios setup (using F2 key) or select the boot device list ( using F12 key).
We have contacted Dell and tried many things together with the support engineer in order to get the computers to boot again. Unfortunately, nothing worked. The machines were fully “bricked”!
Dell decided that the only option will be to replace the motherboards.
As soon as the motherboards were replaced, the 2 computers booted without any problems ( the restored partitions were fine).
Anyone can explain what could have been the root cause of this problems? How comes that a restore can mess up the computer BIOS to such an extent?
Detailed steps:
1) In the BIOS of the Optiplex 3060 we have set the SATA operation mode from RAID to AHCI
2) We have installed the latest version of Linux Mint on the internal SSD of the Optiplex 3060. After the installation the Linux mint properly created an entry in the UEFI BIOS and it was able to boot up successfully.
3) We booted up from an usb key having Clonzilla Live (alternative stable - 20180812-bionic)
- We have selected the “Clonzilla Live (To RAM )” option.
- We have created a full disk image of the internal M.2 disk
- The image of the disk was saved on the same usb key
- The Clonzilla reported image creation successfully and the computer was shut down
4) To test the restore process we booted again the lonzilla USB key
- We have selected the same “Clonzilla Live (To RAM )” option.
- We have then selected a full disk restore from the image created at the previous step
/usr/sbin/ocs-sr -q2 -c -j2 -z1p -I 4096 -sfsck – csc -senc – p poweroff savedisk mint-image nvme0n1
- Image restore went OK an the computer was powered off
5) Attempting to start the computer again resuled in a black screen showingonly the Dell logo.
Sorry to hear that. However, I have no idea about this. Maybe something similar to this:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1734147
I believe something has trigered that. Maybe it's due to buggy firmware in the BIOS, or the kernel bug. Is that possible you ask Dell to check that?
Thanks.
Steven
We will try to work with Dell and get this issue sorted as we need this solution to deploy hundreds of computers.
Can someone please explain what clonzilla tries to write in the UEFI BIOS on restore?
One thing that Clonezilla will try to modify the uEFI setting is to use the program efibootmgr (in update-efi-nvram-boot-entry) to add the boot entry for the restored OS. However, this should not brick the whole system unless there are bugs, either in Linux kernel, the firmware or efibootmgr. The Linux kernel is from Ubuntu 18.04 and it's used by millions of Ubuntu users. Besides, this version Clonezilla live 20180812-bionic has been downloaded more than 100k times, and you are the 1st one reporting this. Therefore maybe it's due to the buggy firmware in the Dell BIOS.
Steven
1) I am also inclined to think that some sort of bug in the BIOS must be the root cause for this...Regardless what settings efibootmgr tries to "push" into the VNRAM, the uEFI BIOS should have proper mechanism in place to prevent such catastrophic event from where you can’t recover unless you replace the motherboard….
2) I am not the 1st one reporting this. There are similar reports out there of Dell computers being bricked , for instance https://sourceforge.net/p/clonezilla/discussion/Open_discussion/thread/9fc9c4dee3/
3) Inspecting the image folder, I can see in the efi-nvram.dat
BootCurrent: 0009
Timeout: 2 seconds
BootOrder: 0000,0007,0008,0001,0009
Boot0000 ubuntu HD(1,GPT,f4136aa2-c2f4-4a0f-a080-c0fbafc15f08,0x800,0x100000)/File(\EFI\ubuntu\shimx64.efi)
Boot0001 Mint PciRoot(0x0)/Pci(0x1d,0x0)/Pci(0x0,0x0)/NVMe(0x1,00-08-0D-03-00-3F-D3-68)/HD(1,GPT,f4136aa2-c2f4-4a0f-a080-c0fbafc15f08,0x800,0x100000)/File(\EFI\ubuntu\shimx64.efi)
Boot0007 Onboard NIC(IPV4) PciRoot(0x0)/Pci(0x1c,0x0)/Pci(0x0,0x0)/MAC(b88584a66a09,0)/IPv4(0.0.0.00.0.0.0,0,0)..BO
Boot0008 Onboard NIC(IPV6) PciRoot(0x0)/Pci(0x1c,0x0)/Pci(0x0,0x0)/MAC(b88584a66a09,0)/IPv6([::]:<->[::]:,0,0)..BO
Boot0009 UEFI: KingstonDataTraveler 3.0PMAP PciRoot(0x0)/Pci(0x14,0x0)/USB(17,0)/HD(1,MBR,0x35844f4,0x800,0x39bf800)..BO
Is Clonezilla using the efibootmgr to push all those entries in the uEFI BIOS on restore ?
"Is Clonezilla using the efibootmgr to push all those entries in the uEFI BIOS on restore ?" -> No, Clonezilla just extracts the required info from that file, basically the info for the OS. In your case, it's "ubuntu". Then use it for adding the boot entry.
Steven
This issue looks like a similar one:
https://sourceforge.net/p/clonezilla/discussion/Clonezilla_live/thread/76ba35a226/
@MRadu, are you able to ask Dell to fix this? Any progress?
Thanks.
Steven
Actually there is one more:
https://sourceforge.net/p/clonezilla/discussion/Open_discussion/thread/9fc9c4dee3
Steven
@Steven Shiau : So far Dell only suggested using "-iefi" as a boot option when performing the restore.
@MRadu,
Thanks. Yes, the option "-iefi" force to skip updating EFI firmware, i.e., efibootmgr won't be run to change andy setting in the uEFI firmware.
The version efibootmgr used in Clonezilla live is verion 15:
https://packages.debian.org/sid/efibootmgr
It's been existing in Debian repository since Apr, 2017. If it's an issue, I believe it will also destroy other brand's EFI firmware. So far the issue seems to be only reproducible on Dell's machine. Maybe I am wrong, but I believe it's Dell which has to fix the firmware to avoid this issue.
Steven
Hello, where in my config files, would the -iefi switch go? I am working on cloning to some new Dell 5060s and don't want to hose them.
@Ward,
Please enter expert mode, and then you can find there is "-iefi" you can choose:
https://clonezilla.org/clonezilla-live/doc/02_Restore_disk_image/advanced/09-advanced-param.php
Steven
@Steven,
I see, it goes in the ocs_live-run command line. Got it once I saw the screen shoot.
In Clonezilla live >= 2.6.0-31 or 20181217-*, we have temporarily blacklisted Dell machine in the program update-efi-nvram-boot-entry. It's the same with enabling the option "-iefi".
Thank you for issue report.
Steven
Last edit: Steven Shiau 2018-12-18
@MRadu,
Has Dell updated the firmware? Do you know that? Thanks.
Steven
Dell US, Taiwan and AMI Taiwan have helped fixing this issue. AMI Taiwan has confirmed that this issue was fixed in Clonezilla live 20190118-cosmic. The same codes are used in Clonezilla live 2.6.1-12 and 20190118-disco. They are now all in testing branch:
https://clonezilla.org/downloads.php
Thanks to Dell US, Taiwan and AMI Taiwan.
Steven
@Steven - is this fixed because of them issueing a UEFI update for their systems, or is this only fixed because of your blacklisting of Dell machines as you mentioned in https://sourceforge.net/p/clonezilla/bugs/310/#e785
Last edit: John L. Galt 2019-02-21
There was a wrong command which was too long, and when writing to AMI uEFI BIOS, it caused CPU exception.
Actually, this issue was caused by the following two factors exist simultaneously:
1. Wrong command from Clonezilla when there are multiple OSs in the uEFI booting entry, e.g.,
Previously Clonezilla can not handle this correctly. Therefore a wrong command like:
efibootmgr -c -d /dev/sda -p 1 -L "opensuse HD(1,GPT,7f033140-72dd-47f6-a9f2-ef7486b67510,0x800,0x4e000)/File(\EFI\opensuse\grubx64.efi)
Windows Boot Manager " -l "\EFI\Microsoft\Boot\bootmgfw.efi"
was run. Now only something like:
efibootmgr -c -d /dev/sda -p 1 -L "opensuse" -l \EFI\opensuse\grubx64.efi)
will be run. Actually we should improve that by adding all of them one by one.
Clonezilla has fixed the 1st one, and I believe AMI team definitely will fix the 2nd one.
Without the help from Dell US, Taiwan and AMI Taiwan, we won't be able to fix this. Thanks to them.
Steven
Ah. That makes sense. 6 months ago I dug out a pair of older laptops to install various flavors of Linix on them to test, and ran into a weird idiosyncrasy regarding the passing of EFI vars to one of them from a Gentoo build. The variables weren't passed from CZ, but from the install itself, and my EFI Vars were overpopulated with items, and the machine, an older Dell Inspiron laptop, kept showing me strange entries on boot drive selection mode (I think it was the Dell, not the other laptop, which is a Lenovo).
It never actually managed to brick the machine, thankfully, and I've currently got Windows running on it, but use CZ to keep full system backups of both the Windows install as well as the current Linux dustro I'm running on it, Sabayon Linux (Gentoo-derivatice).
FWIW, I'ts running InsydeH2O-based UEFI. I can get the exact version and details if need be, but is this a part of the list of machies you want tested? If so, I'll fire up the laptop and give you the command results.
Last edit: John L. Galt 2019-02-22
@John,
Thanks. For the later version of Clonezilla live (>= 2.6.1-12) we have fix this issue. Therefore no need for you to run those commands anymore. Appreciate.
Steven
Cool. I did end up digging that laptop out, and a CZ full disk backup of Sabayon Linux (Gentoo-derivative) with full disk encryption will get installed on it, but the EFI boot info does not get written to the UEFI, rendering it useless. I have a newer CZ backup of Windows partitions and it restored fine, including the EFI entry to allow boot, and subsequent backups also work perfectly fine upon restore.
The same version of CZ was also used to back up the same version of Sabayon that was installed on the Lenovo but it restored perfectly fine, including EFI entry to allow booting.
Is there anything I can do to the Dell backup to see if I can get it to restore the required EFI entry so that I can get it to boot? I have not tried manually creating an EFI entry by setting the UEFI to custom boot settings, whereby I can add info, as my time has been limited, but I'm willing to do anything at this point to restore that backup instead of clean installing Sabayon again (that was a lot of work, with custom kernel compiling, custom graphics drivers and a whole slew of other things I'd rather avoid having to do again). :p
If I need to make a new post / issue for my specific machine, I can do that.
Please advise as to what I need to do, and what additional information you may need from the backup.
Last edit: John L. Galt 2019-03-26
To all,
Just want to make sure:
Was your Dell motherboard bricked due to multiple OSs in the uEFI booting entry? Maybe there are some other scenarios which we do not know?
If you can, please show that by running in Clonezilla live command line prompt:
sudo efibootmgr -v
Then post the results.
Thank you very much.
Steven
This issue was fixed and a new stable Clonezilla live 2.6.1-25 was released.
Steven
Hi,
I realize that this is nearly one year later, but I had the same issue using cloenzilla 2.6.4-10 amd64.
I was cloned disk to disk on a Dell Dimension E521 and when I tried to reboot, nothing at all was possible. I tried changing hard drives, usb drives, disconnecting all the devices, etc. but the boot startup message never displayed and the monitor simply went into stand by mode. I tried many times before finally giving up.
I too was planning on cloning plenty of these machines but now I am a bit scared to brick them all.
Any thoughts?
Cheers!
B