ff652aa8ea
different kernel to boot with kernel="NAME" would load the kernel and loader.conf-selected modules from /boot/NAME, but it would not change module_path. So, for instance, the automatically loaded acpi.ko would come from /boot/kernel/acpi.ko, *always*. Mind you, this happened for unassisted boot. If you interrupted, typed "unload" and then "boot NAME", it would Do The Right Thing. The source of the problem is the double initialization with beastie's loader.rc. One would happen inside "start", and would load the kernel. The next one would happen later in the loader.rc script, resetting module_path. Because module_path is set to the Right Value by the functions in support.4th that actually load the kernel, when beastie.4th proceeded to boot module_path would remain wrong, as the kernel was already loaded. This can be corrected by removing either initialization, and also by changing the command used by beastie.4th from "boot" to "boot-conf", which makes sure you use the right kernel and modules. I chose to remove the second initialization, since this let you interrupt (or confirm) boot before beastie even comes up. I avoid also doing the boot-conf change because that would simply cause the kernel and modules to be loaded twice (in fact, that was my original patch, until, in writing this very commit message, I saw the error of my ways). This commit changes the semantics of module loading when using the beastie menu. Now it does what one would expect it to, but not what it was actually doing, so something may break for unusual setups depending on broken behavior. As our japanese friends so nicely put it, shikata ga nakatta. :-) Approved by: re (scottl) |
||
---|---|---|
.. | ||
conf.c | ||
help.i386 | ||
loader.rc | ||
main.c | ||
Makefile | ||
version |