[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: How to handle kernels of the same version
> The simpler would be to use compilation-time as a subdirectory and
> hack the kernel scripts for making them install the modules in
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
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
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.
Erik Walthinsen <firstname.lastname@example.org> - SEUL Project system architect
/ \ SEUL: Simple End-User Linux -
| | M E G A Creating a Linux distribution
_\ /_ for the home or office user