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.
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.
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.
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...