Changes to contrib bootscripts

DJ Lucas dj at
Fri May 20 23:48:12 PDT 2011

On 05/20/2011 03:47 AM, Matthew Burgess wrote:
> On Thu, 19 May 2011 17:25:15 -0500, DJ Lucas<dj at>  wrote:
>> Matthew Burgess<matthew at>  wrote:
>>> Why renaming things to lsb-bootscripts?  If we're
>>> migrating (which I think we should), shouldn't we just move the lsb
>>> scripts out of contrib and then continue to refer to the package as
>>> the lfs-bootscripts?
>> No change, just file layout in SVN.
> As I noticed after doing an 'svn update' in my own working copy.
>>> chapter07/console.xml: 1) Where did the consolelog script/configuration
>>> go?
>> echo "kernel.printk=4">>  /etc/sysctl.conf
> Ah yes, of course.  Is this documented anywhere though, seeing as it's
> a change from how we handled it in the past?
No actually. It really wasn't mentioned in the book other than in 
passing on the console page, but no example. Should probably find a way 
to put fit that in.
>>> chapter07/network.xml: I quite like Red Hat's layout, but probably just
>>> because
>>> I've become accustomed to it through my day job.  On that distro,
>>> network device
>>> config lives in /etc/sysconfig/network-scripts, and those files namely
>>> ifcfg-<ifname>
>>> and route-<ifname>.  I certainly don't see the need for subdirectories
>>> under
>>> whichever directory is chosen to house the network configuration files,
>>> but
>>> maybe I'm being blinkered by my only needing static wired interfaces to
>>> be
>>> configured.
>> Might have to configure multiple services on one interface, for instance
>> ip and ipx, or maybe one interface does not provide default gw, but a
>> static route is still needed for a dual homed machine.
> OK, I guess that makes sense :)
>>> Why are network scripts put under /lib/network-services? Again,
>>> possibly blinkered
>>> by my exposure to Red Hat, but keeping the service scripts in the same
>>> directory as
>>> the interface config files makes sense to me.
>> Executables don't belong in /etc, this one was covered in Jeremy's thread.
> Yeah, that makes sense too; unfortunately I only glanced over Jeremy's thread.
> Thanks.  In my opinion, this is ready to go in, but I don't know whether you
> want final approval from Bruce?
> Matt.
Thanks Matt. Sorry I took so long to get back to you (I didn't want to 
type a long message on a touch screen). I think we are just about all on 
the same page, but I got the impression above that Bruce did want to 
review it as well. Also, Bryan and Jeremy still have outstanding 
questions. I'll summarize:

1st, Bryan's concern was about moving from 
/etc/rc.d/{rc{sysinit,0,1,2,3,4,5,6},init}.d to 
/etc/{rc{S,0,1,2,3,4,5,6},init}.d - There are a couple of packages, 
non-obvious packages at that, that install their own bootscripts and 
they work in the current proposal without modifications using the lsb 
functions. I suspect that we'll see more in the future, however, I have 
not actually confirmed that they do not work within the old layout 
(sysinit/S change is required). The reason for the new layout originally 
was only to follow other distros' examples of the time that they were 
written (mid 2007). I personally like the new layout better without the 
extra path element, and that is probably only muscle memory...hardly 
justification. Bryan pointed out that the old layout lent itself better 
to tab completion, the savings is only one keystroke, but you actually 
have to type more _characters_ in the new layout as opposed to pressing 
tab repeatedly. I don't yet know how much work is involved in reversing 
that decision, but it should at least be discussed.

I do plan to add a "service" script later that would alleviate the issue 
completely, as was suggested by Jeremy a few months ago, but I'm a 
little stuck as far as how to handle multi-level, conditional tab 
completions in bash, so it is on hold for a sec. Plus, I haven't seen 
how Jeremy and Archaic handle that in LightCube OS yet. My simple 
solution turned out to be not as simple as I had thought. That may even 
turn out to be a C program included with initd-tools or somewhere 
later...IDK as it hasn't been discussed yet. Jeremy, Archaic, any 
ideas/suggestions on that?

2nd, Jeremy's concern was the contents of I agreed with all 
suggestions, including combining lfs-fucntions with init-functions, save 
one. I've made all the agreed changes locally. Most of everything in has been moved into rc, with the exception of clock params, 
hostname, conditional boot off/on and prompt time, boot logging off/on, 
and the command that is run when a boot script ends in an unexpected 
error ('read Enter' in our case). The last one I had just added and was 
on the fence about, but after consideration, I've decided that to be 
something that should be user configurable. Perhaps a function is best, 
as I had suggested originally instead of putting a command in a variable 
in a user configuration file. Make it configurable there by a simple 
yes/no for PAUSE_ON_ERROR or some such.

Theads got long quick, and a little OT at times, but I do believe that 
is the remainder of the concerns.

-- DJ Lucas

This message has been scanned for viruses and
dangerous content, and is believed to be clean.

More information about the lfs-dev mailing list