At 11:17 AM Friday 5/5/2006, you wrote:
John Coffman wrote:
The problem isn't that LILO can't handle more than some number of
characters; that's a LILO issue and doesn't affect the kernel.
The problem is that some people have reported that the kernel
crashes if booted with LILO and the size limit is more than
255. They haven't so far commented on how they observed that, and
that's a major problem.
Just re-compiling LILO with the COMMAND_LINE_SIZE parameter changed
from 256 to 512 will not work. A .bss area must be moved to avoid
clobbering the kernel header.
If the issue is that LILO doesn't null-terminate overlong command
lines, then that's pretty easy to deal with:
- If the kernel sees protocol version <= 2.01, limit is 255+null.
- If the kernel sees protocol version >= 2.02, but ID is 0x1X, limit
is 255+null.
- Otherwise limit is higher.
When LILO is fixed, it has to bump the ID byte version number.
What ID byte values has LILO used?
For the last 8 years LILO has used 0x02 as the loader ID.
If anyone wishes to test a version of LILO that is able to pass a 512
byte command line, then the "22.7.2-beta8" version in the "beta"
directory should be tried. It moves the offending ".bss" area to
avoid the header clobber. However, I have not yet changed the loader ID.
--John
PGP KeyID: 6781C9C8 (good until 31-Dec-2008)
Keyserver at ldap://keyserver.pgp.com OR http://pgp.mit.edu
LILO links at http://freshmeat.net/projects/lilo
and Help link at http://lilo.go.dyndns.org
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
