Debian – Lenovo Thinkpad T450s: “Error: The non-volatile system UEFI variable storage is nearly full.”

On the ThinkPad twist the ls-8672p the connector between the HDD and motherboard I have found to be a cause for concern after having 3 weeks of trouble with a customer who was receiving the HDD error on boot. I replaced the HDD with SSD and problem went away, only to return again a day later.

Upon removal of the integrated caching drive with no joy, I took a look at the connector between the HDD and mobo and realized it was corroded on most the contacts (dull appearance). I used contact cleaner on both connections.

GO INTO BIOS FIRST AND DISABLE BATTERY BEFORE DISASSEMBLING, and unplug the battery once inside. The connector looks like an L shape and has 1 screw securing it to the chassis.

Once I cleaned it problem was solved, turns out the motherboard isn't the issue, it's all to do with a bad connection. To test my theory you could put some pressure on the angled plastic below the right control key while booting and most times the unit will boot, then lock up when you release pressure, it just needs a good cleaning on those contacts.

An example of the ls-8672p connector so you know what you're looking for:

To answer your final question first: When an OS installs on an EFI-based computer, it's supposed to register its boot loader with the EFI, which stores a pointer to that boot loader in NVRAM. Linux distributions use the efibootmgr tool for this, but other OSes have other tools with similar functionality. (Microsoft extended the bcdedit tool to register its boot loader with the EFI, for instance.) At least one OS (FreeBSD) doesn't do this, though; it stores its boot loader using the fallback filename (EFI/BOOT/bootx64.efi), which IMHO is a bad choice -- but if they don't have an equivalent of efibootmgr, it might be their only option. I don't know of any EFIs that actively scan for bootloaders with arbitrary names, although they do boot to the fallback filename if nothing else is present. Some also treat the Microsoft boot manager (EFI/Microsoft/Boot/bootmgfw.efi) as a fallback filename.

It sounds as if your EFI and its NVRAM entries have gotten messed up. Ordinarily, I'd recommend resetting the firmware to the defaults in the hope that this action would correct the problem, but you've already done that. Perhaps you should remove extraneous entries with efibootmgr or something similar and then try resetting the NVRAM. (Do not remove everything, though; I've seen EFIs behave very strangely after all boot entries are removed. OS entries, like for Debian and Windows, should be safe to remove, but leave entries that are clearly hardware-specific, like entries that refer to hard disk models or PXE-boot options.) Removing these entries may leave the computer unable to boot, so having my rEFInd boot manager on a USB flash drive or CD-R may be helpful; you should be able to boot from it and then rEFInd should enable you to boot any OS it detects, which you can then use to re-create working boot entries.

A couple of additional approaches include:

• Remove all hard disks and boot the computer. This may "kick it in the pants" and get it to fix its boot-entry problem.
• Update your firmware. Even an "update" to the exact same version might help (although the update utility might refuse a no-upgrade update). An update might fix a bug that's causing the problem, but just as important, it might reset some variables or storage space that even the reset-to-defaults operation isn't touching.

These are both desperation measures with a small chance of success, so don't get your hopes up. Nonetheless, they're both worth attempting, IMHO. Be prepared with a rEFInd emergency disk, since either might wipe any working boot entries you've already got.

If your system is completely fubared and can't be fixed, then you might try putting your preferred boot manager on the disk as EFI/BOOT/bootx64.efi and configure it to provide boot options for your other OSes. There are computers that have badly broken EFIs that require this approach even when they're brand-new, and it wouldn't surprise me to learn of EFIs that can be broken to require this workaround despite having worked OK in the past.