Bug 1967 - lilo cannot read ramdisk size at boot time from boot device or kernel or initrd image
lilo cannot read ramdisk size at boot time from boot device or kernel or init...
Product: Red Hat Linux
Classification: Retired
Component: lilo (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Erik Troan
Depends On:
  Show dependency treegraph
Reported: 1999-04-03 15:59 EST by techie
Modified: 2008-05-01 11:37 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 1999-06-02 16:29:08 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description techie 1999-04-03 15:59:18 EST
I created an 8MB initrd manually, and placed it in /boot.
I edited /etc/lilo.conf so it finds the kernel, initrd, etc.
in /boot.  I copied /etc/lilo.conf to /boot/etc/lilo.conf.
I copied the hard disk devices needed for lilo from /dev/ to

I ran rdev -r <image> 8192, where <image> is the boot
device, /dev/sda6, in my case.  I ran it again with
<image> being the kernel in /boot, and again with the
initrd in /boot as <image>.  I checked each with "rdev -r
<image>", and they all reported back 8192 as expected.

Then I run "lilo -c -r /boot".  It appears to work fine.

THE PROBLEM IS: unless I specify "ramdisk=8192" in
/etc/lilo.conf, when I reboot, the kernel initializes
16 ramdisks of 4MB size, NOT ones that are 8MB size!
This causes multiple I/O errors on dev 01:00, the ramdisk,
as read requests go beyond the 4MB ramdisk boundary.

I even set "root=current" in /etc/lilo.conf.
(If I set "ramdisk=8192" in /etc/lilo.conf, rerun lilo, then
reboot, I get 16 ramdisks of 8MB size, which is correct, but
I shouldn't have to do this!)

I am writing a script to generate a more intelligent initrd,
and I don't want to have to patch lilo.conf with a line
"ramdisk=N", where N varies.  The documentation for LILO
says it is supposed to be able to read the ramdisk size
from the boot image if no "ramdisk=N" line is given in
/etc/lilo.conf, but this clearly doesn't work -- unless I
am forgetting something!

Please feel free to forward this email to the original LILO
developer, or anyone else who may be helpful.
thanks for your assistance!!
Ed Ouellette
Comment 1 David Lawrence 1999-04-08 13:33:59 EDT
This is being forwarded to a developer for further review.
Comment 2 techie 1999-04-13 15:52:59 EDT
Here are more details:

I may have found a bug in lilo, and/or I may have made
a mistake in configuring an initial ramdisk.
Here's the issue:
lilo documentation says that if an initial ramdisk is enabled,
and you DON'T include a line "ramdisk=N" in lilo.conf, that lilo
will use the ramdisk size found in the boot image ( put there with
rdev -r or
compiled into the kernel, etc.).  However, I have found that lilo
defaults the ramdisk size to 4096K when this line is not present!
Here's what may be happening (my guess):
If lilo includes "ramdisk=0" in the kernel option line at bootup when
lilo.conf does not contain "ramdisk=N", I can see how this happens,
then the kernel will use the default ramdisk size of 4096K.
(I thought that if you ran "rdev -r <kernel> RAMDISK_SIZE" on the
that it would "remember" its ramdisk size.... maybe the bug is in the
kernel code?)
I upgraded to version 21 of lilo, and lilo still has the same

When I include "ramdisk=N" in lilo.conf, everything works well, so I
suspect maybe
lilo is NOT checking (properly) that the bootimage has a non-default
before writing
"ramdisk=0" to the kernel option line... or I may be misssing
something major!
Comment 3 Erik Troan 1999-06-02 16:29:59 EDT
I don't think lilo is meant to do this.. The only documentation I can
find is from user.tex:

\item[\craw{ramdisk=}\meta{size}] Specifies the size of the optional
RAM disk.    A value of zero indicates that no RAM disk should be
created. If this variable is omitted, the RAM disk size configured
into the boot image is used.

If I'm misunderstanding the situation, please reopen this bug and
let me know what I'm missing.

Note You need to log in before you can comment on or make changes to this bug.