Re: The lilo problem
I think what you are missing is that the kernel you were using previously
was compressed in bzImage form, while your new kernel is not. This is
Lilo behaving essentially as documented. There would be effectively no
limitation on kernel size using bzImage, since this involves a multipart
loader (which is the whole point of bzImage).
Also, even on a 16 MHz 386SX, kernel decompression time should be minimal.
If you are doing an initrd load, however, this can be very slow since it
goes through ROM BIOS disk access calls rather than Linux. Since I used a
16 MHz 386SX when working on the SCSI stack in Linux back around v0.95, I
can assure you that decompressing the kernel on boot is a LOT less time
consuming than, say, recompiling the kernel on that platform.
-- Mike
On 2000-05-20 at 16:33 -0400, David Butts wrote:
> I expect that 63925 is not just a documentation problem.
>
> I have a 386sx 16, and recently compiled a new kernel for it. I
> chose to compile an uncompressed kernel (make vmlinux), since it
> takes a non-trivial amount of time to uncompress the kernel on my
> admittedly sorry little 386.
>
> I got that 'Kernel foo is too big error', even though my new,
> uncompressed kernel is _smaller_ than the compressed kernel that
> installed with frozen (2.2.14). Even if the new kernel is the
> only boot option in /etc/lilo.conf, I'm told that it is too big,
> but it is, by any measure that I can find, smaller than one that
> works (and can be re-installed by lilo without errors). Given
> that, I'm assuming that lilo's ability to measure kernel size is
> broken, but I could easily be missing something :).
Reply to: