Slackware 15.0 elilo machine was not booting after a CMOS battery change. "No boot device available" It was booting to Slackware before the battery change. (We changed the battery because it keeps losing the time's hour whenever it's shut down and restarted, but keeps the minute - it still does, and the old battery seems fine.)

BIOS Setup could see the SSD (sda, where the boot files were on sda1) and the HD sdb.
Slackware 15 could be launched as an available option once the installation DVD was booted.

Research found efibootmgr utility plausible to help, but there's only a Slack package for 14, not 15.
We booted the installed Slackware via the installation DVD, and found that our Slackware 15.0 installation has efibootmgr available, but only to root use. "not found" to normal user. So, as root,
efibootmgr
command shows DVD, UEFI DVD, and the drives, no "Slackware".

We followed instructions to create an EFI boot entry:
Step 1 of 2: We copied elilo-x86_64.efi from /boot to /boot/efi/EFI/Slackware directory, as there was no *.efi file in that directory.
Then, step 2 of 2:
efibootmgr --create --disk=/dev/sda --part=1 --label="Slackware" --loader='EFI\Slackware\elilo-x86_64.efi'

This created an EFI boot entry and set it as the default boot. ...Thank you for super help,
https://linuxconfig.org/how-to-manag...tries-on-linux

It boots, hooray! (Machines with support for the UEFI firmware stores boot entries in the non-volatile RAM called NVRAM, which needs continuous CMOS battery power to remember. Poor thing had forgotten which drive and partition was bootable.)
It took me a good while to research and solve this, so I'm posting hoping to help another Slackware fan through their research.

Yup, that makes sense and not only for Slackware.

You need to go through much the same palaver if you change the hard drive, as I found out to my cost! In that case, the UEFI data preserved in NVRAM haven't changed, but the partition IDs on the new drive no longer match them even if you copied your EFI partition contents across intact.

2 members found this post helpful.

Aha, the alphabet soup tag. So, I bet you had to delete and re-create the drive/partition entry. Good to know! KGHN

My guess is that the reason Slackware 15.0 stopped booting when changing CMOS battery is that all the CMOS settings were lost when you changed the battery. Changing CMOS battery should not cause any .efi files on your HD to get lost, but you probably previously booted with LILO and had your cmos could be configured to boot in legacy mode instead of UEFI.

However, the fact that you had a boot/efi directory indicates that you once tried to boot with UEFI, that directory is most likely on a FAT32 partition.

regards Henrik

If time is off by an hour it is probably due to a time zone setting not configured correctly. Does the output of the date command show the correct time and timezone?

Hey, henca, Yes, the reason Slackware 15.0 stopped booting when changing CMOS battery is that all the CMOS settings were lost when we changed the battery. I'm thinking that the original Slackware EFI boot entry was looking for the .efi in its /boot location, but I was following the recipe I found online for making the new EFI boot entry, so I made a copy to where the new entry expected it. I don't think any files on the HD got lost. We were definitely booting with elilo before the "No boot device available" trouble. And yes, I configured the machine from scratch, and my notes confirm that I created the /boot/efi directory in a 100MB dedicated FAT32 partition on the SSD.

Thank you for posting, michaelk. The time comes up off by 7 hours consistently, in the opposite direction from Greenwich Time. I think we are set correctly to Mountain Time (Montana location). Thanks for the suggestion to check the output of the date command; we'll do that, and also check into hwclock vs. sysclock, as suggested by another post I found last night.

Time being off by the UTC offset indicates that something could be amiss with the UTC setting in the /etc/adjtime file for the system clock. The hardware clock being set to local or UTC and the adjtime file (system clock setting) set to the opposite. I ask about the date command since many desktop clock display have their own independent timezone setting.

I could be misunderstanding, but I would have thought the simple Slackware way to do this would be to run `eliloconfig'
This is Patrick's shell script that does all of the above, found at /usr/sbin/eliloconfig

Thank you, Loomx, for suggesting another way to fix it. I wasn't quite sure what the problem was, when I started getting a pretty general error instead of booting. I did my best to search for advice online. Not being a guru, I was wary of messing up my configuration with unintended consequences of broader tools. One post I found suggested "running through the installation" - but didn't give enough detail for me to feel confident about the safety of my data or my ability to choose do-this-don't-do-that properly; I started trying that process but got nervous about my ignorance and aborted. This computer has much of value to me in /home. Your kind advice makes me think that researching eliloconfig would have been a good approach. I appreciate your post.