Bug 3681 - LILO cuts the appends!
LILO cuts the appends!
Status: CLOSED WORKSFORME
Product: Red Hat Linux
Classification: Retired
Component: lilo (Show other bugs)
6.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 1999-06-23 15:18 EDT by sinsalaco
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:
Environment:
Last Closed: 1999-06-23 16:00:58 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description sinsalaco 1999-06-23 15:18:45 EDT
if i write in lilo.conf somethig like:

append="hda=dma"

It says at boot:

unknown option (or somethig similar): "hda=dm"

as if it doesn't read the last letter.

Writing at the lilo prompt: linux hda=dma works ok.
Comment 1 David Lawrence 1999-06-23 16:00:59 EDT
I could not replicate this problem as reported on a stock install of
6.0 in our test lab. After rebooting a cat /proc/cmdline showed the
hda=dma was properly passed to the kernel.
Comment 2 Rick van Rein 2000-03-23 15:39:59 EST
I think the trouble is caused by a maximum line length. If "hda=dma" is one of
many arguments, it may be cut off. Especially if the last "a" is the 79th
character. [I am on i386]

I am also experiencing trouble. I am working on an extension that requires a few
longwords in hex on the commandline, and these always get cut off after 78
characters. For numbers, that just means calculations go wrong... rather fatal
in my case :-/ The numbers are also in "append" lines.

If I do `lilo -q -v` it displays its intentions to pass >78 chars to the kernel.
Looking up the maxlen of a commandline in the i386 kernel code led to the value
of 256 chars [kernel 2.2.14], so that shouldn't throttle the commandline either.

Something is withholding characters somewhere. I am unsure where...

Please DKL, pick this up again and see what happens for longer appends.
Comment 3 Rick van Rein 2000-03-23 16:45:59 EST
I did one other test, to ensure if LILO is the troublemaker, and it is. Loadlin
accepts arbitrary long cmdlines (oh well, as far as M$-DOS will allow it ---
anyway, beyond 78 chars).

Since [on i386] the COMMAND_LINE_LENGTH is 256 (apperantly including a trailing
zero), I set out to update LILO. In lilo.src.rpm from RH 6.1, I altered the
patch to change line 196 of lilo.h, from 0x4e (78 in hex) to 0xff (256 minus
trailing zero). It seems to work ON I386.

If you cannot rebuild, you may use my *crude* RPMs (i386 and src) which are
temporarily available at
	http://members.home.nl/hackers/rpm/lilo-0.21-10RvR.*.rpm
Install it with -U --force to overrule the existing lilo [from RH 6.1 in my
case], rerun the lilo command to get the new length of the commandline boiled
down to the boot data structs, and reboot. In my case, the longer commandline
was established, and it is passed over nicely as it should.

That's good, because I am now running with two DIMMs of 32MB each, which are
statically damaged; specifying the faulty addresses on the commandline can now
be done, so that I may use those DIMMs as if they were okay to start with :-]

Note one thing: I have _shifted_ the problem from 78 chars max to 255 chars max.
The limit will probably always be there due to physical conditions at boot time.
It's purty bad that LILO doesn't complain...

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