Re: The lilo problem

[David Butts <dbutts@genuity.com>]

Hello, all-

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 :).

Thanks,
David

On Fri, 19 May 2000, Mike Bilow wrote:

> I have serious doubt that 62942 is even a Lilo problem, more likely BIOS.
> 
> At least two of these (63516, 63925) seem like doc errors at worst.  If
> the kernel image is too big, then it is too big.  It just happens that the
> error falls out of running Lilo.  The warning issues as a result of the
> uncompressed size of the kernel, not the compressed size.  This is
> actually a result of a documented trade-off in Lilo, where the LARGE_EBDA
> compile-time option is selected:
> 
>    LARGE_EDBA Loads LILO at a lower address in order to leave more space
>     for the EBDA (Extended BIOS Data Area). This is necessary on some
>     recent MP systems. Note that enabling LARGE_EDBA reduces the maximum
>     size of "small" images (e.g. "Image" or "zImage").
> 
> I personally cannot think of any logical reason why it is desirable to
> have a zImage instead of a bzImage kernel, unless the machine is broken.  
> (Remember that Lilo itself is specific to the i386 platform.)  Note that
> LARGE_EBDA was selected to fix a number of important bugs (e.g., 58602) on
> certain platforms.

<snip>

> -- Mike
> 
> On 2000-05-19 at 19:47 +0200, Richard Braakman wrote:
> 
> > I think lilo is the package most likely to break the next test cycle.
> > 
> > Package: lilo (debian/main)
> > Maintainer: Vincent Renardias <vincent@debian.org>
> >   62942  lilo and serial console problems
> >   63095  lilo installs rescue disk in boot sector, clobbering Windows
> >   63229  lilo: potato lilo fails on ibm netfinity 5500
> >   63516  lilo: command 'lilo' fails (not SEGFAULT) if kernel is not bzImage
> >   63925  lilo: After upgrade - `Fatal: Kernel /vmlinuz is too big'