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. Reproducible: Always 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: ks=nfs:192.168.99.1:/eng/abcdefghijklmnopqrstuvwxyz 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. also: # cat /proc/cmdline ks=nfs:192.168.99.1:/eng/abc 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. linux.0 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. 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 on code written by intel. Instead, I used the much more robust pxelinux package from H. Peter Anvin.
Which means I can close this bug report, since 'pxelinux' is part of RHL.