Bug 2028 - lilo in 5.9.7 doesn't accept non-bzImage kernels anymore
lilo in 5.9.7 doesn't accept non-bzImage kernels anymore
Status: CLOSED WONTFIX
Product: Red Hat Linux
Classification: Retired
Component: lilo (Show other bugs)
6.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Cristian Gafton
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 1999-04-07 04:22 EDT by Pekka Pietikäinen
Modified: 2008-05-01 11:37 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 1999-04-07 13:09:28 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Pekka Pietikäinen 1999-04-07 04:22:29 EDT
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
machines.
Comment 1 Cristian Gafton 1999-04-07 13:09:59 EDT
as of lilo-0.21-5 we compile lilo with large EDBA support, and intend
to
ship such a lilo with 6.0.  this means we can boot out of the box on
boxes
that use bits of the high 640k for their bios.  Things like 4-way
intel
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
the
stages are loaded so as not to step on the high 640k that the bios may
be
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
still
be Quite Huge.

#ifndef LCF_LARGE_EBDA
#define MAX_KERNEL_SECS 1024    /* absolute maximum kernel size */
#else
#define MAX_KERNEL_SECS  896    /* absolute maximum kernel size */
#endif

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
the
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
you're
referencing in lilo.conf is too big.  to get around this you can
relink
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
are
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.