Bug 2028

Summary: lilo in 5.9.7 doesn't accept non-bzImage kernels anymore
Product: [Retired] Red Hat Linux Reporter: Pekka Pietikäinen <pp>
Component: liloAssignee: Cristian Gafton <gafton>
Status: CLOSED WONTFIX QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 6.0   
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 1999-04-07 17:09:28 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

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
machines.
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
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.