Recently, during my Great Rack Migration madness, I migrated the system drive for my main NAS to a new Supermicro 846.
One of the hurdles I ran into was that my system refused to boot after I moved the drive. The install was EFI based, and the new system didn’t have the appropriate NVRAM variables to determine which OS to boot.
Fortunately, EFI provides the EFI shell, and that shell makes this problem extremely simple to fix.
First off, to replicate the setup, I create a new small Debian VM on ESXi and installed Buster. An important step to take if you want to experiment in the EFI shell, is to make sure the VM actually boots via EFI, which the Debian template doesn’t do automatically:
For this experiment, it is important to make this change before installing the VM.
Within a VM in ESXi for EFI, it’s fairly trivial to replicate what would happen if you moved a boot drive from one system to another. The NVRAM file just needs to be deleted (preferably while the VM is powered down).
This involves manually browsing the datastore and deleting the
vmname.nvram file that’s in the VM Folder on the datastore.
Once the nvram file is deleted, the VM will refuse to boot:
But reseting and tapping ESC quickly gets the the boot manager menu, which allows entering an EFI shell. Some servers boot straight into the EFI shell if they can’t find what to boot:
Which leads to:
In the EFI shell, available drives are enumerated as
Switch to a drive and see if it’s a drive that has EFI stuff on it (dir or ls works):
EFI folder exists, that’s the right spot.
cd EFI dir cd debian dir
The relevant file should be named
grubx64.efi. Typing that (or using tab completion to select it), will boot your system:
Once your system is booted, you just need to rerun and update grub to restore your system’s ability to boot without the EFI shell.
It’s important that your EFI partition is properly mounted, which should happen, but you might need to mount it manually:
Once you confirm your EFI partition is mounted, reinstall grub:
sudo grub-install /dev/sda sudo update-grub
That’s it! The system should be booting again.