Re: The lilo problem

[David Butts <dbutts@genuity.com>]

Hello, all-

Thanks for the fast response.

On Sat, 20 May 2000, Mike Bilow wrote:

> I think what you are missing is that the kernel you were using previously
> was compressed in bzImage form, while your new kernel is not.  This is
> Lilo behaving essentially as documented.  There would be effectively no
> limitation on kernel size using bzImage, since this involves a multipart
> loader (which is the whole point of bzImage).

I've poked around through the docs (both for lilo and the kernel source)
and haven't found any explanation of what the bzImage does.  I had assumed
that it just used bzip to compress the kernel instead of gzip, but that
apparently isn't the case.  What exactly is the bzImage doing that allows
a larger kernel image to be loaded, if it's the uncompressed size that
matters?

> Also, even on a 16 MHz 386SX, kernel decompression time should be minimal.  
> If you are doing an initrd load, however, this can be very slow since it
> goes through ROM BIOS disk access calls rather than Linux.  Since I used a
> 16 MHz 386SX when working on the SCSI stack in Linux back around v0.95, I
> can assure you that decompressing the kernel on boot is a LOT less time
> consuming than, say, recompiling the kernel on that platform.

This is true.  It took ~18 hours to compile the kernel and modules, but
I figured that, since I was trying to keep the kernel small to save
memory, I could get away with an uncompressed kernel and save a few
seconds at boot (FWIW, it loads the image substantially faster than it
decompresses it).  In retrospect, the fact that other architectures can
get away with it wasn't applicable to lilo, but live and learn, right?

Out of curiosity, how long has it been since a full kernel fit in 512Kb?

Thanks again-
David

> -- Mike
> 
> On 2000-05-20 at 16:33 -0400, David Butts wrote:
> 
> > I expect that 63925 is not just a documentation problem.
> > 
> > I have a 386sx 16, and recently compiled a new kernel for it.  I
> > chose to compile an uncompressed kernel (make vmlinux), since it
> > takes a non-trivial amount of time to uncompress the kernel on my
> > admittedly sorry little 386.
> > 
> > I got that 'Kernel foo is too big error', even though my new,
> > uncompressed kernel is _smaller_ than the compressed kernel that
> > installed with frozen (2.2.14).  Even if the new kernel is the
> > only boot option in /etc/lilo.conf, I'm told that it is too big,
> > but it is, by any measure that I can find, smaller than one that
> > works (and can be re-installed by lilo without errors).  Given
> > that, I'm assuming that lilo's ability to measure kernel size is
> > broken, but I could easily be missing something :).