unable to remove superflous linux kernel entries

[Mark Eckert]

I'm sure I'm missing something here, but for the life of me can't find it.

Where does rEFInd store information that it uses to populate the options for linux kernels it has autodetected? I have tried moving the old bzImage*.efi to /boot/efi/EFI/refind, but that didn't do it. I moved them to my root filesystem and told rEFInd in refind.conf not to scan the volume rootfs (the label of the relevant partition). Finally, I completely deleted these old bzImages. Yet, I am still presented with menu entries for all the kernels rEFInd has ever detected, though those kernels have been moved, and subsequently deleted!

On the positive side, this is wonderful software, and I can now boot Windows 8 directly from rEFInd, which makes it simple for me and my family. Or, it will once they don't have to confront an array of zombie linux kernel entries before locating their beloved Windows.

Thank you for taking the time to read my question.

[Roderick W. Smith]

If you select an entry and rEFInd returns a "file not found" error, then the most likely possibility is that there's a manual boot stanza for it in refind.conf. Naturally, rEFInd does not ship with any such entries active, since they'd be highly system-specific, so if this is what's happening, you must have created such an entry yourself at some point (or perhaps copied a configuration file from somebody who'd defined such an entry).

If rEFInd can launch the kernel (even if it fails at some subsequent point), then the kernel file must exist somewhere that rEFInd is scanning. The description that appears beneath the icons will tell you where it is. For instance, rEFInd's description might be:

Boot boot\vmlinuz-3.16.0 from 44 GiB ext4 volume

This description gives the filename, including its path (boot\vmlinuz-3.16.0 -- EFI, and therefore rEFInd, displays backslashes as directory separators) and the volume name or description (44 GiB ext4 volume in this example, since the volume has no name set). You should be able to figure out where your kernels are from this information. Note that rEFInd knows nothing about Linux mount points, so if you've got a separate /boot partition, the description would omit the boot\ part and the volume description would be the name or description of the /boot partition.

All that said, I do not recommend deleting or moving kernels by hand. If you move them around using mv, you could end up duplicating kernels, and they'll clutter your filesystem. Fedora limits the number of kernels it installs at any given moment. Ubuntu does not, but you can trim it down to two or three by doing sudo apt-get autoremove. Other distributions may have similar mechanisms, but I don't know the details, offhand. It's best to keep at least two kernels installed (except on a brand-new installation) so that you can use the older one as a backup in case the newer one gets trashed, or in case you install a new one and it's got some bug that prevents it from working correctly. Having an extra entry or two in the boot menu is a small price to pay for this backup functionality.

[Mark Eckert]

SOLVED:

Ahh. It's come to me, I think. The HDD where my /home now resides might just still have its old efi system partition. I long ago moved everything but /home over to my ssd. I completely forgot about the other partitions. Been to lazy to temporarily move /home and reformat the drive. I think rEFInd must be scanning the efisys partition of what is now sdb. Once my son finishes his TF2 session for today I will look into it.

I'm almost certain this is it. It's the only explanation that makes any sense at all. Sorry to take your time with what was a dumb mistake on my part.