Re: The lilo problem
It's not the size of the kernel itself, but the size reported at the end
of the compile:
Root device is (3,1)
Boot sector 512 bytes.
Setup is 1284 bytes.
System is 405 kb.
I don't remember which one, but I think IF the system is bigger than the
boot sector you will get a kernel is to big message.
Hope this helps...
Steve Przepiora
On Sat, 20 May 2000, David Butts wrote:
> 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'
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>
Reply to: