Bug 30837

Summary: kernel command line truncated
Product: [Retired] Red Hat Linux Reporter: Jim Wright <jwright>
Component: pxeAssignee: Elliot Lee <sopwith>
Status: CLOSED CURRENTRELEASE QA Contact: Brock Organ <borgan>
Severity: high Docs Contact:
Priority: medium    
Version: 7.0CC: dr
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2001-09-11 18:00:10 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Jim Wright 2001-03-06 19:22:45 UTC 
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.
Comment 1 Jim Wright 2001-03-13 20:34:58 UTC 
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.
Comment 2 Michael K. Johnson 2001-03-13 21:42:03 UTC 
Sounds like a bug in pxe, then.
Comment 3 Elliot Lee 2001-09-11 00:13:19 UTC 
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?
Comment 4 Jim Wright 2001-09-11 18:00:05 UTC 
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.
Comment 5 Elliot Lee 2001-09-11 21:55:58 UTC 
Which means I can close this bug report, since 'pxelinux' is part of RHL.