From Bugzilla Helper:
User-Agent: Mozilla/4.75 [en] (X11; U; Linux 2.2.16-22 i686)
The command line passed by the loader to the kernel gets truncated. We
have seen this with both LILO and PXE, leading me to believe it is a kernel
issue and not specific to one loader.
Steps to Reproduce:
1. Set up PXE so it works (HA! good luck)
2. Get to the point where linux.0 asks for command line arguments.
3. Type in:
Actual Results: The output on VC3 when trying to copy over the kickstart
file reports that the directory is 192.168.99.1:/eng and the file is abc.
# cat /proc/cmdline
Expected Results: Should have gotten the full command line.
This is a killer for our use of kickstart. We need to be able to specify
per-machine kickstart files to allow each machine to be individually
configured. With the command line truncated, we can't fit in the necessary
information to uniquely identify clients.
I also have reports of the command line being truncated when booting an
in-service system using LILO. Typical scenario is a video driver with a
long list of arguments.
I believe bugzilla #5747 is trying to say the same thing as this report.
I've been trying to find why the command line I type in
linux.0 is truncated when read by linux.1. I've gotten into the code
to try and track this down.
In pxe-linux/nbp.linux/prepare.c, I've printed the command line as
it is present in the in-memory copy of the (pseudo) boot sector.
It is correct at this point.
I need to come up with assembly code or some trick so I can print
the command line portion of the boot sector after it is relocated
to memory at address 0x9000:0x0024. This is what I'm working on
at the moment.
In examination of pxe-linux/nbp.linux/setup.s, I don't see where
memory corruption could occur. This is the last code executed by
linux.0 before control is passed to the in-memory copy of linux.1.
In arch/i386/kernel/head.S I've added code to dump 128 bytes of
memory starting at address 0x9000:0x0024. This happens after
arch/i386/boot/* has run to decompress the kernel. Otherwise, it
is among the very first things that happen in the running kernel.
From this dump, I see that my complete command line is present
in memory. Almost:
Characters 0 through 27 are as I typed.
Characters 28 through 45 are replaced by nulls.
Characters 46 on are as I typed them, with a final null
So, it looks like something is slapping 18 null bytes in the middle of
where the command line is supposed to be. Since this corruption does
not (consistently) occur when "normally" booting a kernel, I think the
problem must be in the linux.0 code.
Sounds like a bug in pxe, then.
Grr, sorry for the unresponsiveness of the previous pxe maintainer.
Unfortunately I am pretty clueless about how it works. Would you happen to have
found a solution or any more information in the time elapsed since your last report?
The "solution" was to not use the pxe stuff that redhat provides, which is based
written by intel. Instead, I used the much more robust pxelinux package from H.
Which means I can close this bug report, since 'pxelinux' is part of RHL.