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