Re: truncation of settings.s (was : how to pass parms to rc.custom?)

"John Lumby" <[email protected]> Sat, 19 Feb 2005 17:29:03 -0500
Newsgroups gmane.linux.tomsrtbt
Message-ID <[email protected]>
That was fast!

I don't know much about lilo, grub is all I've ever used.    Just for fun, 
since I had the tomsrtbt up, I copied the lilo command and here-doc input 
out of buildit.s into a file in /tmp, created its .../mp dir for it and 
copied all the files it wants as input off the diskette onto .../mp (boot.b, 
settings.s and the bz2bzimage), and tried running it, and it came back with 
an odd message
Sorry, don't know how to handle device 0x0103

I don't know why it wouldn't work, as it ought to be much the same 
environment as when I run buildit, no?      But then, I don't know where it 
was trying to put whatever.

I think it would probably be easier to re-run buldit. right? ...     (or 
easier still to ignore the truncation - the little penguin is still there 
but now a microbe)

John

----Original Message Follows----
From: Tom Oehser <[email protected]>
To: John Lumby <[email protected]>
CC: [email protected]
Subject: Re: truncation of settings.s  (was : how to pass parms to 
rc.custom?)
Date: Sat, 19 Feb 2005 16:52:15 -0500 (EST)


Look at the lilo configuration in buildit.s.

settings.s is double-duty-

- When it *runs*, it just ignores that part.

- When *lilo prints it*, the script part scrolls past.

But *when you run lilo* is when it builds the boot logic that
knows what to display!  So, if you *increase how many sectors
it takes*, you have to re-run lilo!

Note, you can make it longer- as long as it still fits in the
*same number of sectors*.  SO, since it is 967 bytes long, you
have to either keep it *somehow* <= 1024, maybe by editing some
other part of it shorter- or re-run lilo.

-Tom

On Sat, 19 Feb 2005, John Lumby wrote:

 > Date: Sat, 19 Feb 2005 16:41:11 -0500
 > From: John Lumby <[email protected]>
 > To: [email protected]
 > Cc: [email protected]
 > Subject: truncation of settings.s  (was : how to pass parms to 
rc.custom?)
 >
 > I notice that when I add lines to (the top of) settings.s on the 
diskette,
 > then the same number of lines (or characters ?) as I added, are truncated
 > from the bottom of the logo that is displayed on initial boot..    Not a 
big
 > problem, everything else works, but odd.    I have a feeling of deja-vu 
all
 > over again - did I report this before and you explained it?   Or did I
 > notice it before and figure out why?      Can't remember.
 > Anyway on looking at it now, I can't see what actually displays that 
logo.
 > It seems that /etc/rc.S dot-sources settings.s and  the code in 
settings.s
 > itself dd's it to /dev/null ...     so how does it end up on the console?
 > Can you explain (again?) how this works and whether there's something 
simple
 > I can additionally edit in settings.s or rc.custom.gz on the diskette 
that
 > preserves the full boot logo.  (without having to re-buildit)
 >
 > John
 >
 > ----Original Message Follows----
 > From: Tom Oehser <[email protected]>
 > To: John Lumby <[email protected]>
 > CC: [email protected]
 > Subject: Re: [tomsrtbt]   how to pass parms to rc.custom?
 > Date: Tue, 21 Dec 2004 13:12:25 -0500 (EST)
 >
 >
 > The intention was that most users would be customizing settings.s and
 > rc.custom.gz without rebuilding.  If you are doing a rebuild anyway,
 > I think you can modify 1/settings.s, and settings there will be kept.
 >
 > -Tom
 >
 > On Tue, 21 Dec 2004, John Lumby wrote:
 >
 >  > Date: Tue, 21 Dec 2004 11:56:35 -0500
 >  > From: John Lumby <[email protected]>
 >  > To: [email protected]
 >  > Subject: [tomsrtbt]   how to pass parms to rc.custom?
 >  >
 >  > In the supplied rc.custom.gz, there is this (at line 4):
 >  >
 >  > if [ "$IPADDR" != "" ]
 >  > then ... do stuff
 >  > fi
 >  >
 >  > How would I set IPADDR to something such that the stuff is done?    Is 
it
 >  > simply a matter of setting it in 1/settings.s?      That's what I 
think I
 >  > deduce from looking at
 >  > 2/etc/rc.S
 >  > I have been a bit unwilling to put "permanent" settings in 
1/settings.s
 >  > since I notice that buildit completely rewrites it (1/settings.s) 
every
 > time
 >  > I buildit   (why does it do that?     doesn't trust me?   I guess 
that's
 >  > wise ...)    I suppose I can edit the settings.s on the diskette, 
which
 > is
 >  > the way I am supposed to do it according to the FAQ.     But I wonder 
if
 >  > there's some place on the build directory where I can safely store
 > settings
 >  > like this and have them included in every diskette I build without 
having
 > to
 >  > think about it.
 >  >
 >  > John
 >  >
 >  >
 >
 >