Hi David,
> >Have you considered compiling the package? Shouldn't be to hard to find and
> >correct the bug/feature/oddity you are refering to, now you know what it is.
>
> I have. Have you ever looked at the source? LILO is not a normal package - it
> includes a massive amount of assembly code, necessary to do the low-level boot
> stuff. The "feature" I observed is likely in the hand-coded assembly portion, a
> place I really don't want to venture.
Ok, so I grabbed the source (lilo-21.4.4). If you look at lilo.h you will
find the variable CL_LENGTH, probably the length of the total command,
including boot=/vmlinuz-#. This defines the length of the variable cmdline,
which is declared as a byte in second.S. It is the last variable, and it's
actually not a byte, but an array of bytes. second.S compiles to boot.b. You
can see that cmdline is at the end of boot.b.
So I increased the value of CL_LENGTH in lilo.h to 0x9e. Running the freshly
compiled lilo I got an error stating something like map size to big. So I
increased MAX_SECONDARY (also in lilo.h) to 12 (I guess 11 would have
sufficed).
To be short, it works. I didn't do a make install, but I copied boot.b,
chain.b and os2_d.b to /boot by hand (after backing up the old files), and
placed lilo in /root for now. I can enter a command line of 0x9e chars on the
LILO: prompt (probably more if you increase CL_LENGTH). Note I didn't apply
any patches, so no graphical interface for me anymore. The club sign before
the LILO: prompt is not my fault, it is there when I compile the clean source
as well.
You could give it a try, maybe applying the patches as well, before modifying
CL_LENGTH and MAX_SECONDARY in lilo.h.
Bye,
Leonard.
_______________________________________________
Redhat-list mailing list
[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/redhat-list
