Re: lilo config is busted, need help fixing it
On Sat, 25 Sep 2010 00:54:12 -0400 (EDT), Stan Hoeppner wrote:
> Stephen Powell put forth on 9/24/2010 4:06 PM:
>> Current stock Debian kernels for the
>> amd64 architecture are right on the ragged edge of being too
>> large for lilo to load below the 16M line
>
> And the bulk of these ~16MB stock kernels is the initrd, correct? Wow
> those are huge. I'm so glad I roll my own, from kernel.org source, and
> forgo the "kitchen sink" initrd setups of the stock kernels.
>
> -rw-r--r-- 1 root root 1.5M Jul 9 09:29 vmlinuz-2.6.34.1
> -rw-r--r-- 1 root root 490K Jul 9 09:29 System.map-2.6.34.1
> -rw-r--r-- 1 root root 29K Jul 9 09:29 config-2.6.34.1
>
> At my pace of kernel file growth, I won't hit the lilo 22.8 16MB limit
> for a few decades. :)
>
> Correct me if I'm wrong Stephen, but isn't this 16MB ceiling more of a
> block device controller BIOS limitation than a lilo limitation?
There are a couple of misconceptions here. It is true that the initial
RAM disk images on disk, when the default value of MODULES=most is
specified, are larger than the size of
the kernel image on disk. But that is not what I'm talking about.
I'm talking about the kernel itself. You see, the kernel image on disk,
which gets loaded by lilo into memory, is partially compressed.
That is, a small portion of the kernel code at the beginning of the
kernel is uncompressed, but the majority of it is compressed. That's
why the kernel image has the naming comvention vmlinuz-* instead of
vmlinux-*. (The initial RAM disk image on disk is compressed too.)
When lilo transfers control to the kernel, one of the first things
the kernel does is to decompress its compressed portion. From what
I can tell, it allocates some memory somewhere large enough to hold
the decompressed portion of itself, does the decompression, frees
the compressed portion of kernel memory, allocates a new chunk of
memory starting where the compressed portion resides and the same
size as the uncompressed hunk, copies the uncompressed hunk there,
and then frees the working copy of the uncompressed hunk. The net
effect is that the compressed kernel is "decompressed in place".
The compressed initial RAM file system image, also loaded by lilo,
has not yet been touched at this point. lilo tries to load the
compressed kernel image between the 1M line and the 15M line
(total 14M), even when large-memory is specified, at as low an
address as possible. lilo must determine whether the *decompressed*
kernel will fit in this space. If not, memory above 16M must be
used.
The compression ratio for an amd64-architecture kernel is significantly
higher than for an i386-architecture kernel. The current version
of lilo underestimates the uncompressed size of an amd64-architecture
kernel and may decide that the kernel will fit between 1M and 15M,
when in reality, it won't. This is especially likely if the compressed
initial RAM file system image is also being loaded in this space.
lilo 23.0 fixes this problem. The uncompressed sizes of stock
amd64 kernel images are quite large, and are close to the 14M limit
of below-16M loading. If the uncompressed kernel won't fit there,
then it must be loaded above 16M, even if the compressed image will fit
below 16M easily.
Some old BIOS do not support the BIOS calls that lilo, running in real
mode, uses to copy a block of memory above the 16M line. This can
be tested for using the lilo diagnostic diskette that I have posted
on my web site. But I am not aware of any 64-bit machines with this
restriction.
--
.''`. Stephen Powell
: :' :
`. `'`
`-
Reply to: