Load the first of the following kernels to be found:
${kernel} if ${kernel} is an absolute path
/boot/${kernel}/${kernel}
/boot/${kernel}/${bootfile}
${kernel}/${kernel}
${kernel}/${bootfile}
${kernel}
${bootfile}
The last instance of ${kernel} and ${bootfile} will be treated as a
list of semicolon separated file names, and each will be tried in turn,
from left to right.
Also, for each filename loader(8) will try filename, filename.ko,
filename.gz, filename.ko.gz, in that order, but that's not related
to this code.
This resulted in a major reorganization of the code, and much of what
was accumulating on loader.4th was rightly transfered to support.4th.
The semantics of boot-conf and boot also changed. Both will try to load
a kernel the same as above.
After a kernel was loaded, the variable module_path may get changed. Such
change will happen if the kernel was found with a directory prefix. In
that case, the module path will be set to ${directory};${module_path}.
Next, the modules are loaded as usual.
This is intended so kernel="xyzzy" in /boot/loader.conf will load
/boot/xyzzy/kernel.ko, load system modules from /boot/xyzzy/, and
load third party modules from /boot/modules or /modules. If that doesn't
work, it's a bug.
Also, fix a breakage of "boot" which was recently introduced. Boot without
any arguments would fail. No longer. Also, boot will only unload/reload
if the first argument is a path. If no argument exists or the first
argument is a flag, boot will use whatever is already loaded. I hope this
is POLA. That behavior is markedly different from that of boot-conf, which
will always unload/reload.
The semantics introduced here are experimental. Even if the code works,
we might decide this is not the prefered behavior. If you feel so, send
your feedback. (Yeah, this belongs in a HEADS UP or something, but I've
been working for the past 16 hours on this stuff, so gimme a break.)
Now boot-conf can also receive parameters to be passed to the kernel
being booted. The syntax is the same as in the boot command, so one
boots /kernel.OLD in single-user mode by typing:
boot-conf /kernel.OLD -s instead of
boot-conf -s /kernel.OLD
The syntax still supports use of directory instead of file name, so
boot-conf kernel.OLD -s
may be used to boot /boot/kernel.OLD/kernel.ko in single-user mode.
Notice that if one passes a flag to boot-conf, it will override the
flags set in .conf files, but only for that invocation. If the user
aborts the countdown and tries again without passing any flags, the
flags set in .conf files will be used.
Some factorization was done in the process of enhancing boot-conf,
as it has been growing steadly as features are getting added, becoming
too big for a Forth word. It still could do with more factorization,
as a matter of fact.
Override the builtin "boot" with something based on boot-conf. It will
behave exactly like boot-conf, but booting directly instead of going
through autoboot.
Since we are now pairing kernel and module set in the same directory,
this change to boot makes sense.
is failing for everybody that I have spoken with that has tried it.
FreeBSD/i386 bootstrap loader, Revision 0.8
(root@outback.netplex.com.au, Tue Jun 13 23:26:49 PDT 2000)
Loader version 0.3+ required
Aborted!
start not found
Note that the 0.3+ message is from inside the arch-alpha block, not the
i386 block of code. And even then, 0.8 is higher than 0.3.
This prevents the rest of the loader.conf stuff working. :-/
was found or not. Fix it's usage. Alas, it caused no problem before,
besides leaving garbage in the stack, because refill, used by [if]
[else] [then], was broken.
a parameter and dtrt.
Also, make boot-conf always unload first. There wasn't really any
point in not doing this, as the kernel _has_ to be loaded before
any other modules.
Tested by: dwhite
