Setup:
- Multiple Offline Computers with Hot Swappable Single SSDs (single SSD containing OS & data)
- Ubuntu 20.04.1 installed in UEFI mode (Single OS, entire disk)
Problem: After moving to Ubuntu 20.04 LTS, it has become a common incident that following a complete shutdown of a PC, taking out the SSD (containing the OS) and moving it to another (exactly same HW) PC, I face grub rescue. This didn't happen in 16.04 LTS (non UEFI) and I could replace SSDs normally.
Symptoms:
- After moving the SSD (100% sure about proper shut down), I face grub window (in rescue mode) both in original and the new PC (i.e. OS is corrupted)
- Even setting up grub in manual mode (set root=(hd0,gpt2); linux /boot/vm...) and calling 'boot', takes me to a command-line environment with (initramfs) at the start of the line where it suggests running fsck on root partition because the checksum is wrong!
- fsck nearly invalidates all sectors and the partition becomes unusable.
Suggestions:
- The only thing I can think of (though not necessarily true) is use of LZ4 for initramfs in Ubuntu 20.04. Or it could be grub problems with UEFI mode. Since most folks out there don't usually move their OS disk around between different PCs, this might be a rare problem.
Notes:
- I don't do anything strange with these disks. As all my Windows setups (and previously, Ubuntu 16.04 LTS ones) work OK during these replacements.
sudo efibootmgr -v
UEFI has fallback or hard drive entry that uses /EFI/Boot/bootx64.efi which should allow you to boot. Typically bootx64.efi is just a copy of /EFI/ubuntu/shimx64.efi. Some UEFI seem to auto find a Windows entry & recreate it, but not any other system. External drives all boot from the same type of entry as the fallback on internal drives (same as yo use for Ubuntu or Windows flash drive installer). – oldfred Oct 27 '20 at 15:40