Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 2028 - lilo in 5.9.7 doesn't accept non-bzImage kernels anymore
Summary: lilo in 5.9.7 doesn't accept non-bzImage kernels anymore
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: lilo
Version: 6.0
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Cristian Gafton
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 1999-04-07 08:22 UTC by Pekka Pietikäinen
Modified: 2008-05-01 15:37 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 1999-04-07 17:09:28 UTC

Attachments (Terms of Use)

Description Pekka Pietikäinen 1999-04-07 08:22:29 UTC
When upgrading 5.9.1 to 5.9.7 my non-bzImage kernels stopped
working (lilo complained they were too big even though they
were fine with 5.9.1's lilo). No reason why not to use bzImages
though, but still the new behaviour was quite unexpected
and could cause problems for some people upgrading their

Comment 1 Cristian Gafton 1999-04-07 17:09:59 UTC
as of lilo-0.21-5 we compile lilo with large EDBA support, and intend
ship such a lilo with 6.0.  this means we can boot out of the box on
that use bits of the high 640k for their bios.  Things like 4-way
boxes and IBM machines with raid cards that use the memory for raid
control goop.

tech bits:  the large edba patch we're using re arranges where some of
stages are loaded so as not to step on the high 640k that the bios may
using.  in doing so, it shrinks the space we have in the low 640k for
zImage kernels.  bzImage kernels are loaded in high memory and can
be Quite Huge.

#define MAX_KERNEL_SECS 1024    /* absolute maximum kernel size */
#define MAX_KERNEL_SECS  896    /* absolute maximum kernel size */

zImage kernels loadable by lilo now have to be < 458752 bytes instead
of the previous 524288.

so if people do a 6.0 upgrade their new lilo may not be able to load
kernel's they've installed themselves if they used zImages.  lilo will
whine at run time (as opposed to boot time) that one of the kernels
referencing in lilo.conf is too big.  to get around this you can
the kernel as bzImage or recompile the lilo source rpm without the two
LARGE_EDBA defines in the makefile.

I'm told we've shipped bzImages for a while, and the kernels in 6.0
bzImage so we're fine, but this may surprise some people out there.

Note You need to log in before you can comment on or make changes to this bug.