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
> >
> >
>
>
