For a few years now, my desktop system has been a Dell PowerEdge T30 booting Ubuntu from a SATA SSD; it's been updated over several releases and has been at 21.04 for several months. Last week, I attempted and failed at a memory upgrade (incompatible module) and found myself with a system that wouldn't boot. I'm uncertain exactly what was corrupted in BIOS, GRUB, and/or EFI. After several attempts at remediation, including a fresh 21.04 installation onto another drive and a BIOS updated and reset to defaults, I can now get back into my usual environment and have verified that I can boot to it in either Legacy or UEFI mode. (The SSD on /dev/sda isn't GPT-formatted; I believe that I originally installed Ubuntu there in BIOS mode.)
The bad news, though, is that I can no longer boot up successfully from power-up without intervening via the F12 one-time boot selection menu. If I power-up the machine without F12, I get past a displayed BIOS-level splash screen (which has always been present) offering to set up Intel hardware RAID, see some further disk access LED flashes, and the machine then goes silent without reaching a visible GRUB splash. Some options selected from the F12 menu fail in the same way, with behavior that seems to vary in part as a function of whether the BIOS settings are configured for Legacy vs. UEFI mode, and/or whether that original mode setting is overridden within the F12 menu. Once I get to the GRUB screen, selection works normally, and once I'm booted into Ubuntu, restarts work smoothly; problems seem specific to cold start. I can't tell how much of the underlying cause may fall in the realm of firmware and CMOS configuration vs. EFI and GRUB, but will start here in case other Ubuntu users have seen anything similar.
When I started investigating, the SSD showed a small fat32 partition which gparted indicated as being tagged with (boot, esp), but which seemed to be empty. After EFI-mode installation with that partition, I've verified (via efibootmgr -v) that different boot option choices can successfully launch my desired installation using either the SSD's GRUB or the new Ubuntu install's GRUB as BootCurrent.
As currently EFI-booted, efibootmgr's result is as shown below. Mount also tells me that efivarfs is mounted on /sys/firmware/efi/efivars, and /dev/sda2 on /boot/efi.
$ efibootmgr -v
BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0000,000D,0001,000E,0005,0006,0007
Boot0000* ubuntu HD(2,MBR,0x5be31cf4,0x33000,0x400000)/File(\EFI\ubuntu\grubx64.efi)
Boot0001 Diskette Drive BBS(Floppy,Diskette Drive,0x0)..BO
Boot0005* USB Storage Device BBS(USB,USB Storage Device,0x0)..BO
Boot0006* CD/DVD/CD-RW Drive BBS(CDROM,P2: HL-DT-ST DVD+/-RW GU90N ,0x0)..BO
Boot0007 Onboard NIC BBS(Network,IBA CL Slot 00FE v0106,0x0)..BO
Boot000D* UEFI: ST4000VN008-2DR166 HD(2,GPT,5f7553fb-3ff3-427b-b0ac-821bfb2d1a50,0x16e360800,0x100800)/File(EFI\boot\bootx64.efi)..BO
Boot000E* Internal HDD BBS(HD,Internal HDD,0x0)..BO
The file at Boot-repair output is boot-repair's report on the configuration as it now stands. After running boot-repair and receiving errors, getting the system to a state where it only reached a GRUB shell, I did another grub-install. I got an error that GRUB was not built with efivar support, so no EFI boot entry could be registered, but the configuration is now EFI-bootable as before via F12. The file as posted represents an info-only run. I note that its text (line 447) now suggests a repair to the GRUB on /dev/sdc, rather than earlier runs where it had recommended repair to the GRUB on /dev/sda (the SSD, which is the one I primarily care about).
Does anyone have ideas for fixes or paths to explore? Desirably, I'd prefer to continue using and upgrading my established Ubuntu installation where I'm typing now (with configuration including mdadm RAID for /home) rather than destabilizing further and rebuilding it. While it's possible to work around by using the F12 menu, I'd really rather have the system back to where it was a week ago, reliably booting to GRUB or Ubuntu from cold start. Thanks for reading.
