<TLDR> Use a recovery environment to re-install grub! </TLDR>
I have been getting the dreaded “No Operating System” when restoring a VMware guest using Veeam. Here is my story of how I fixed it.
I have two old SLES guests running on VMware 7. I use Veeam to back these systems up. One of my SLES guests has several virtual hard drives, which shouldn’t be a problem, but is. It will not start on restore from Veeam. The only way I’ve had consistent success is by (s)FTP and making a copy of the VMware folder of the guest, then using VMware’s datastore browser and uploading the files (also can use sFTP) and then adding a existing guest. Not a terrible work around, but the guest must be off to get it’s files. One can not do this with a hot guest.
After years of using the FTP solution, I decided to get to the bottom of this.
The first thing I noticed was the second virtual disk was being used as the primary disk in the VMware configuration. Odd. This particular guest has two drives, the primary disk at 68gb and the secondary at 66gb. The secondary disk has no partitions and is only defined at the hardware level – it is not mounted. When backing up, everything looks good – the larger disk is shown as primary. When restoring, everything continues to look good until you finish the restore and look at the machine in VMware. Now it shows the 66gb disk as primary!! Booting results in “No Operating System” being shown.
So I tried a few methods of swapping positions – simply editing the guest configuration and deleting both drives and repopulating them with existing drives pointing to the correct files – no effect same message of “No OS”. I also tried some fancy renaming of the .vmdk files… all no luck. Still getting the “No Operating System” when booting no matter what I tried.
So I suspected the virtual controllers may be the culprit – I am moving from a real ‘server’ with RAID and SAS drives to a simple i5 box I have at home, and VMware cares about SCSI/ISA Controllers. Any and all muckery here was wasted effort and added to my deepening dread that I had a major IT asset which I did not have confidence in being able to recover in case of a disaster.
After many attempts at editing the Virtual Machine – I tried modifying the .vmx file directly, copying and pasting sections from a working guest. As expected, this by in large broke the machine outright far more than fixed it. After only a couple hours it was clear this was not a path to success.
After a rare good nights sleep I decided to approach the situation differently. I have been working from the point of view that the guest VM is broken… not really listening to what it was telling me.. “No Operating System”. It wasn’t the guest, it was the OS! Grub was clobbered!
Fortunately I had a SLES10.1 .iso (same vintage is always best!), and was able to boot into a recovery session on the guest.
$fdisk -l showed that the swap partition was positioned in front of the data partition… it has been trying to boot the swap partition and finding nothing there!!
So, the fix:
- fdisk -l to show the devices, noting the bootable partition is at (in my case) /dev/sda2
- mount /dev/sda2 /mnt
- cat /mnt/etc/fstab and note /dev/sda2 mounting to “/” (good!)
- grub-install –root-directory=/mnt /dev/sda
This reinstalls grub so that it looks to the second partition to boot from. Reboot and presto – it works!!
I tried this with SLES15 but no luck – that uses grub2. Tried a old SystemRescueCD.iso and had success using it’s version of grub. Seems pretty resilient.
A pretty straight forward fix, once I was on the right track! So hard to see the right track when you are working in a team of one and deep in your box.
Handy guide I followed:
Source: How to reinstall the GRUB boot loader | Support | SUSE
How to reinstall the GRUB boot loader _ Support _ SUSE (local copy)
