Bug 1967

Summary:	lilo cannot read ramdisk size at boot time from boot device or kernel or initrd image
Product:	[Retired] Red Hat Linux	Reporter:	techie
Component:	lilo	Assignee:	Erik Troan <ewt>
Status:	CLOSED NOTABUG	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	5.2	CC:	techie
Target Milestone:	---
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	1999-06-02 20:29:08 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description techie 1999-04-03 20:59:18 UTC

Hi,
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
/boot/dev.

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!)

Background:
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
techie

Comment 1 David Lawrence 1999-04-08 17:33:59 UTC

This is being forwarded to a developer for further review.

Comment 2 techie 1999-04-13 19:52:59 UTC

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
ALWAYS
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,
b/c
then the kernel will use the default ramdisk size of 4096K.
(I thought that if you ran "rdev -r <kernel> RAMDISK_SIZE" on the
kernel,
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
problem.


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
size
before writing
"ramdisk=0" to the kernel option line... or I may be misssing
something major!

Comment 3 Erik Troan 1999-06-02 20:29:59 UTC

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.