[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: splitting up kernel-image into two pieces



On Jul 15, Robert Bihlmeyer wrote:
> Nick Cabatoff <ncc@cs.mcgill.ca> writes:
> 
> > > AFAIK all the images do is update the vmlinuz symlink. Why don't you
> > > just ignore that and specify /boot/vmlinux-x.y.z-foo directly in your
> > > boot setup?
> > 
> > They do a lot more than that - the postinst is about 1000 lines of
> > perl currently I believe.
> 
> 50 % is user interaction.

Fine, make it 500 lines.  Mostly to set the symlink and run lilo, with
lots of sanity checking.

> > I don't want to specify the kernel in my lilo because I want to be
> > able to use the same lilo.conf for all, or at least most, of our ~100
> > debian machines.  I don't want to have to change lilo.conf just
> > because I change the kernel.
> 
> It would be interesting to know, *which* problem you actually want to
> solve. In other words, what does the postinst get wrong?

It's not that it does anything 'wrong' per se, it's that I don't agree
that installing a kernel image on a machine should make it the only
operative one.  Put another way, I want to have multiple kernel images
available sometimes; I don't want the order in which they're installed
to matter, and I don't want putting the kernel on disk to potentially
make the machine unbootable.  (These issues are particularly important
to me because on our system packages are mostly installed 
noninteractively.)

The immediate motivation for me was that I was irritated that when
installing different kernel-images on a machine I had to boot off a
floppy.  Scenario:

- install image A on machine - now the old kernel I had gets moved to
  vmlinuz.old
- discover image A doesn't boot, so try image B - now A is
  vmlinuz.old, and my old working kernel isn't listed in lilo.conf
- reboot, curse, and go find a boot floppy

I've worked around that partly by putting a 'failsafe' target in my
lilo.conf, but I'm not entirely satisfied.  Hence my kernel-sel
packages.  Which are working now on our machines if anyone is
interested, though I still haven't done enough testing on them for me
to really endorse them.

> In the mean time, maybe "man kernel-img.conf" helps...

Thanks just the same, but in this case I'd pored over the docs and
code at length before I posted.



Reply to: