when building multiple kernels, they end up with installed as: /boot/kernel.$KERNCONF the first built kernel ends up as /boot/kernel I have uninstalled that first kernel, and am now left with: /boot/kernel.GENERIC-MMCCAM/ /boot/kernel.GENERIC-NODEBUG/ loader cannot cope with that. It always tries to build its list of kernels with "kernel" as a base-line, even if it doesn't exist.
(In reply to Mina Galić from comment #0) Right, historically we haven't been able to enumerate directories in loader scripts, thus couldn't really do much more intelligent if the default kernel failed to load. However, we added that (+ kernels_autodetect) fairly early on in lua. Will need to put a little thought into what we want to do here.
My suggestion would be: - if able to enumerate kernels - initialize the list of kernels to the enumerated kernels in lexical order - if the list of kernels is empty after attempted enumeration - initialize it to getenv("kernels"):gmatch("([^;, ]+)[;, ]?") - if the list of kernels is still empty - initialize the list to getenv("kernel") - else - if getenv("kernel") is in the list - move it to the front of the list I believe this will result in the least disruption for existing setups while removing the annoying behavior of always trying to load a non-existent kernel for users who have KODIR = /boot/${KERN_IDENT} in /etc/src.conf.
Created attachment 244259 [details] Proposed patch > - if the list of kernels is empty after attempted enumeration > - initialize it to getenv("kernels"):gmatch("([^;, ]+)[;, ]?") This part I'm not sure I agree with; `kernels` is empty by default, so if it's populated then IMO we should be preserving that as the list of kernels first and foremost with anything we can autodiscover after that to preserve some semblance of the ordering the sysadmin may have intended -- especially since autodiscovery is actually defaulted to on in defaults/loader.conf.