I restored my disk using Clonezilla. When I choose the corresponding entry from my the boot menu, the screen flashes black and returns quickly… no error messages that are visible to me.
However, if I run Super Grub from a USB drive, and then pick the /EFI/opensuse/grubx64.efi to boot, the grub menu would come up with all entries functioning as I would normally expect to get.
So, this makes me thing the problem is something wrong with the efibootmgr entry. I removed the existing entry and recreated this using the following command:
sudo efibootmgr -c -d /dev/sdd -p 1 -L “openSUSE” -l “\EFI\opensuse\grubx64.efi”
(My EFI partition is /dev/sdd1)
The EFI partition is reported in the Yast Partitioner as type “EFI Boot”. I also tried regenerating the grub config and running grub2-install, though it didn’t seem to be the actual issue.
I’m stumped as to what to do now? Thanks for any suggestions!
Yes, I have a few disks. I have a separate drive which holds my windows os - it has its own UEFI partition and if I choose it, it will boot through the windows boot manager. Here is the output of blkid:
Just to be sure - you chose it in GRUB or in firmware boot menu?
Everything looks just fine. If you firmware offers possibility to select file to boot, I would try if you can navigate openSUSE EFI partition. It really looks like firmware does not like something on that partition.
You could try to re-run mkfs on that partition and re-run grub2-install after that. Just to be sure it is not some fs-level corruption.
Yep, I tried that stuff. I also compared all the partition flags and configuration in the partitioner to a fresh install of opensuse and couldn’t identify any different… It does seem like the firmware doesn’t like something about the partition after it is restored, as you mention.
I was able to get this fixed by:
Doing a fresh install of opensuse from a USB drive, with the same partition sizes and configuration as the clone, wiping everything else on the drive.
Restore only my root and home partitions and leaving the EFI and swap partitions from the new install.
Grub was now failing into a recovery command line so I booted with Super Grub disk on Parted Magic.
When the system tried to boot again, it failed because the EFI and swap partitions had new UUIDs. So I had to correct the /etc/fstab entries using the new ids from the output of blkid.
Now I could get a clean boot into suse with super grub, and then ran “grub2-install /dev/sdd” to fix grub.
… and tada… it works. And everything looks the same to me in efibootmgr except the new partition id.
Glad to have it booting as expected now but frustrating that I can’t identify the root cause. The UEFI implementation on my motherboard firmware seems to be a little odd/non-traditional and I can’t seem to find anyway to get any error output, so I guess it’s just trial and error…
Depending how you “clone” and restore it is possible to get new UUID on restore. If you do a binary copy of drive then UUID should be unchanged but depending on the clone software cloning partitions may result in different UUID on restore.
BTW boot flags are not used at all in EFI boot only legacy
Yes, clonezilla restored with the same UUIDs, however when I installed opensuse fresh and then restored only the root and home partitions, the efi and swap partitions had new UUIDs from the fresh install. Good to know about the boot flags.
If you really want to pursue it, it makes sense to contact Clonezilla guys and work with them. At the end, it is their software that fails to produce working configuration. You can find exact commands to create ESP in /var/log/YaST/y2log on openSUSE after installation, this may help to compare with what Clonezilla does.
Just a quick question, did you clone the “partition” or the “device” in clonezilla? I have much more luck with cloning and restoring the entire device, especially if the device is an ssd. This gets you the MBR as well as the partition. When I restore the device, I de-select the option to re-install grub. It is possible that clonezilla did it’s own thing with your grub setup.
If it’s a large drive with multiple partitions, then it may not be useful to clone the device since you would rarely if ever want to restore all of it at once. I went to doing the device with ssd’s because the available size of partitions on an ssd can change over time and you can end up with an image that is too large to restore to a somewhat depleted partition. Device also backs up your MBR which can be nice if you end up with something nasty in there. When I do just partitions, I also do concurrent backups of the MBR with separate software.
Hmm yes, I backed up the entire device, and was initially attempting to restore the entire device as well. I don’t recall an option to skip grub install, but grub seemed to be intact as it used to be as I could hand off to grun on my EFI partition via the super grub disk. I don’t have enough understanding of what is stored in the MBR to determine whether it could be affecting how my motherboard firmware attempted the EFI boot process, but it sounds like it’s probably along the right path.
Good idea! It might be an interesting exercise to try an alternative cloning software and see if it produces similar result.
Finding the exact commands will be great - I’ll have a look. If nothing else, perhaps I can recreate what the opensuse installer does to repair the device after restore without having to run a full install.
With EFI boot there is no MBR it is not used. The EFI boot partition is the thing that controls the boot. The UEFI looks for a specail partition that is FAT formatted and starts the boot process there. each OS has it’s own directory. The boot order is set and stored in the UEFI flash
Hello everyone!
I’m having very similar (if not the same) problem with non-UEFI boot.
Cloning of entire disk is done without errors, but after restore grub command shell is displayed and computer was not able to boot. I’m trying to restore openSUSE 42.1 64bit, EXT4 file system, on same machine it was originally installed on. UUIDs are same after restore (I have just root and swap partition), boot record is on root partition.
I’m not sure what is the problem, so I’ll keep looking for solution.
Interesting thing happened… I was restoring the image with different version of Clonezilla and had no problem with boot. Image was made with Clonezilla 2.4.7-i686-PAE and when I used the same version for restoring the image, system couldn’t boot. However, I used Clonezilla alternative stable version, 20160627-xenial-64bit and everything worked like charm, no action on my part. Not sure what was causing the problem, but it is worth posting here IMHO, it may help others.
Big thanks to community for support.