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