On Tue, Mar 23, 2004 at 09:38:03AM -0700, Jerry G. DeLapp wrote:
> I've been fooling with mkautoinstallcd and with booting with hand entered 
> parameters as well as using --append.  I think that Server.pm probably needs 
> something like the attached patch.  The current append list is about 100 
> chars already, and the hard limit is 255.  

Where is the hard limit documented?  I'd like to have that in a comment so we know
where to check if this changes - I'll wait for that before I commit.

> This patch should prevent a bogus 
> append string. I say 'something like' because the attached patch will result 
> in the temporarily mounted iso image being left mounted after the croak.

I think the right solution is a function that gets executed on exit that makes
sure mounted images get dropped.  There are already croaks calls in that same area
that would potentially cause the program to exit w/ a mounted image, so I don't
think another would hurt.  I'll put that on the todo list for mkbootmedia, though
I think the only time it'll get bitten is when a user ctrl+c's at a bad time.

> The patch also prevents an unfortunate occurance should someone put the word 
> APPEND in a comment in the pxe config file ;-).

I modified your patch like so:

-                    if (/APPEND/) {
+                    if (/^\s*APPEND\s+/) {

There's already a pxelinux field called IPAPPEND, no reason there couldn't be one 
called
APPENDFOO later.  The extra \s+ should catch that case.

fyi, mkbootmedia does a if (/^\s*APPEND.*/) already, I've also modified it to make sure
there's a white space character afterwards.

> Also, I had additional questions about the current default append string.  
> Through experimentation with 3.2.0 I've found that an awful lot of the 
> parameters entered there are redundant when booting from a CD.  For example, 
> with current kernel you don't need to specify load_ramdisk=1 if you specify 
> initrd=.

Yeah, I never use that - and, according to Documentation/kernel_paramaters.txt, this
is a "List of ramdisk to load from floppy" - this is clearly being used incorrecly
and unnecessarily.  Ditto w/ prompt_ramdisk. I've removed them from CVS.

I also killed 'rw', because we're using a read-only ramdisk, ramdisk_blocksize since
that's not needed on x86 (nor other architectures, now that I've added patches to 
hardcode
the value in the kernel, and mkcramfs should do the right thing on most arches anyway).
In addition, I removed console=tty0 because that is either already the default and
therefore not needed, or it is not the default and will just cause confusion in that 
case.

So, we're down to:
  APPEND vga=extended initrd=initrd.img root=/dev/ram

vga=extended is obviously not necessary, but I'll leave it up to Brian to decide if it
should be removed - I do prefer the way it looks.

>  The reason I bring this up is that when I reentered the default 
> part by hand I found I ran out of space on the kernel command line before I 
> was able to enter the full set of additional variables that usually appear in 
> the local.cfg file.  This argues for getting rid of redundancies if possible.

agreed.

> I found that with 3.2.0 you could successfully boot a cd with just the 
> following line at the boot prompt: kernel initrd=initrd.img root=/dev/ram.  
> This set does leave "enough space" to fully specify the variables in 
> local.cfg.

> What I don't know is whether PXE booting needs more parameters to 'do it 
> right'.

nope, not in my experience - once the bootloader has loaded everything in the right
place and handed over the flow of control to the kernel, nothing should be different.

thanks Jerry!


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
Sisuite-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/sisuite-devel

Reply via email to