For that to work you'd have to implement the filesystem
code in the bootloader (or have the bootloader chain
to a chunk of code, a 2nd stage bootloader, in any
filesystems that it *did* support.
This would constrain you to filesystems that had such
code (minix, xiafs, ext and ext2 don't seem to have
such code in their superblocks).
This superblock code (or 2nd stage bootloader) would
either have to allow LILO to pass parameters to it,
or it would have to be interactive, or both (so you
could select alternative kernels).
>> I've worked with other boot-loaders which, when told what partition the
>> kernel is placed on, automagically figured out what sector etc. etc. it
>> should grab the kernel from. No need to run some boot-loader
>> configuration-program after a kernel recompile.
Yes. You have. These constrain the type of filesystem
and the locations and names of the kernels. Linux doesn't
do this.
As I said, I saw an announcement in c.o.l.a. about a
(patch?, package?) that adds this feature to ext2fs ---
but I don't remember the name and I don't have a suitable
set of keywords to track it down. So, unless someone
can point me to a set of c.o.l.announce archives that goes
back at least 4 months I won't be able to help anyone (who
hates LILO) find it.
>> The bootloader of my choice is the one from Unifix:
>>
>> - loads kernel from any partition
>> - boot gui; edit kernelparameters at before boot, save them before boot,
>> ...
>>
>> Anyway, let's not bore the admin-list with this topic any more ... ;o)
>>
>> Kind regards,
>> Brian
>>
>> (P.S: I did like your analogy!)
>> Jim Dennis wrote:
> Sorry, but one last post.
> It can't automagically load the kernel because it doesn't know
> which one! I have several on my noot partition. The whole point
> being to nominate one of them as the default, but still have the
> others available. Nothing like trying to recover a dud
This isn't quite right. It can't do it automagically
because "it" (the bootloader) doesn't contain filesystem
driver code. "It" loads the kernel which contains the
filesystem drivers (and can thus find directories, follow
those links to their corresponding inodes, and thence to
the data blocks (direct and indirect)).
Most versions of Unix (and DOS) "cheat" by having some
code in the logical boot record (superblock) implement
enough of the filesystem primitives to allow the
location and loading of the kernel.
Certainly this is possible in Linux --- and it would
be highly to our advantage to implement it in the
next stable version.
LILO questions are the most common source of confusion
(speaking as "the answer guy" --- senior linux tech support).
It's perfectly understandable that this is a source of
confusion --- Linux is the only OS on the PC that works this
way. Thus users coming from DOS and Unix backgrounds, those
with SCO, Solaris x86, Xenix, MS-DOS, DR-DOS, Win '9x and
NT, backgrounds, even those with experience in *ALL* of
these are all at an equal disadvantage when dealing with
LILO.
I didn't say that LILO was the optimal solution. I said
that it helps if you understand *why* it came to pass, and
offered a practical analogy for explaining the "extra step"
(running /sbin/lilo to "compile" the directives in
/etc/lilo.conf into a set of "boot blocks and maps"). It
actually isn't _quite_ right --- but it's practical and
get's people to understand it.
I'd bet you could even add a target in an /etc/Makefile
that would have some sort of dependency under /boot/*
--- to recognize any time new kernel at been built and
run /sbin/lilo automatically. (I'm also convinced that
there are numerous other things we could put in
/etc/Makefile, like newaliases and various makemap
commands. There was an article in an old LISA proceeding
about "Makefiles for sysadmins"
Incidentally it's no accident that I refer to LILO to
discuss the package as a whole, /sbin/lilo to refer to
the "compiler" and the phrases "boot loader" and "maps"
to refer to the output from /sbin/lilo. Those terms
are frequently misused, which further adds to the
confusion in this area.
> kernel. Back in the old days when I was working on Idris (one of
> the first clones) we were on ... (never mind noone else is that
> old). Anyway if you built a bad kernel life was traumatic for the
> next hour or two. Much better to press CTRL or ALT and pick a
> working kernel. If you want to make life easy, some kernels have
> a make zlilo option which will build a kernel and install it as
> vmlinuz and run lilo. Next best thing IMHO while still retaining
> the flexibility for those who must live life on the edge. Assumes
> vmlinuz is the boot kernel.
I like that make option, and thought that a more
recent one even had a "make install" option (that would
build everything? --- do
make zlilo modules module_install
... everything except reboot.
> RJM
-- Jim Dennis (800) 938-4078 consulting@starshine.org Proprietor, Starshine Technical Services: http://www.starshine.org- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/