Re: How to handle kernels of the same version

[Erik Walthinsen <omega@omegacs.net>]

> The simpler would be to use compilation-time as a subdirectory and
> hack the kernel scripts for making them install the modules in
> /lib/modules/$kernel_version/$compiltime_version
It'd work the same either way.  The only difference is a '/' instead of the 
'-' in all the paths.  Implementor's preference.  Though..., there might be 
a good reason to keep them in version-sequence.  If for some reason 
something were to happen to the conf.modules file, it would default to
/lib/modules/version.  As as safety, this can be a symlink to the safe 
kernel modules directory, /lib/modules/version-1.  If we used subdirs for 
each sequence, this wouldn't be very clean, to have 2/ right next to ipv4/, 
and ipv4/ itself a symlink to 1/ipv4/.

> Notice however than we don't really need to handle many kernel
> versions.  What we need is to keep sane the modules for the safety
> kernel (the one he used for install that we would be keeping just in
> case).
Quite true.  I see no reason why any SEUL machine would have more than an 
absolute maximum of three kernels on their system: stock, known 'custom', 
and attempted 'custom'.  The attempted custom kernel would become the known 
custom kernel once it boots successfully, and the user decides they're OK 
(maybe with prompting from the system after N days/boots, or whatever).

> Having a tgz containing the safey kernel's modules in the root
> peripheral and a command for moving the production modules out of the
> way and reinstalling the modules for the safey kernel is perfectly
> valid.
But it doesn't allow the user to automatically boot to a safe kernel.  The 
kernel modules should always be there, because by design the kernel will be 
*very* dependent upon them.  Having to make sure things are just right to 
allow the extracting of the modules early enough on boot to work properly 
just introduces too many variables.  What if the disk is full?  What if you 
need a module to do it?  etc. etc.

I think the ~1MB (2MB extracted - 1MB compressed) we lose to keep them
around is worth it, especially since we'd have to make sure there are 2MB 
available at *all* times anyway, just so we could extract them if needed.

> By lloking at /proc you can know the arguments to the kernel and pass
> a special arg thanks to LILO.
True.  Didn't think about that.  But as the docs say, any un-parsed 
variables are available in the *environment* of init anyway, so we don't 
even need to parse them out.

> If you erase and reinstall your kernel sources the .version will be reset.
That's not much of a problem, since the actual kernel build will be done by 
some other program.  It's trivial to set the .version file (`echo 1 > 
.version`), and all we really have to do is check against the existing 
kernels.  We can assume that all kernels built on the machine will be used 
on the same machine, and vice versa, so all we have to do is find the max 
of the existing kernels (or a hole if we really wanted to) and shove that 
number (minus 1, actually) into .version before calling make.

> I have the box.
Huh?

     Erik Walthinsen <omega@seul.org> - SEUL Project system architect
        __
       /  \                SEUL: Simple End-User Linux -
      |    | M E G A            Creating a Linux distribution
      _\  /_                         for the home or office user