Bootscript future

DJ Lucas dj at
Tue Aug 10 21:40:29 PDT 2010

Hash: SHA1

On 08/10/2010 03:45 PM, Bruce Dubbs wrote:
> Jeremy Huntwork wrote:
>> Hey All,
>> So with my LightCube OS project (which is actually nearing first alpha 
>> release), I am at the point where I need to decide what to do for boot 
>> scripts. I have been using LFS and BLFS scripts up to now, but I'm not 
>> sure if I will continue to do so in the future.
>> (I also played with systemd, which is really cool, but it's not 100% 
>> yet, in my opinion, nor does my OS generally need it, due to its goals).
>> It depends on a couple of things, really. Firstly, what's the goal of 
>> LSB compliance with the scripts, and how far away is that? I want to 
>> meet that, if possible.
>> Secondly, is there any likelyhood that LFS/BLFS will want to adopt 
>> chkconfig for their scripts. It's dead easy to set up, but it does 
>> require modifying the scripts to contain runlevel and order information, 
>> and a description (no big deal, really). chkconfig also is a super small 
>> package with no need to use crazy dependencies (unless you want to use 
>> the semi-graphical ntsysv program).
>> Thoughts?
> If there were updates to the bootscripts to make them LSB compliant, I 
> would support that.  I think that the chkconfig program should be 
> deferred to BLFS though.
>    -- Bruce

Actually, for LSB compliance, the 'distribution supplied boot scripts'
need not use /lib/lsb/init-functions at all.  All that is required is
that the scripts provide the LSB header information, and can therefor be
manipulated by {install,remove}_initd.  That said, I have been working
on a replacement for the LFS bootscripts for some time, and have a fully
compliant set in LFS/trunk/BOOK/bootscripts/contrib/lsb-v3/, with quite
a few of the BLFS scripts completed as well in

I've been using them for quite some time, and even apply a patch to my
jhalfs copy of the book.  All that is required from the book POV is to
install Dan Nicholson's initd-tools package (which provides the
install_initd and remove_initd programs required by LSB) to utilize the
scripts (or any script with LSB header information).  The scripts that
I've written do not use /lib/lsb/init-functions directly, but rather use
another functions script (/etc/init.d/lfs-functions) that wraps around
the LSB functions to give us something similar to the simplicity that
has always existed in lfs-bootscripts, while keeping the output
consistent regardless of whether it is one of our scripts or a vendor
supplied script.  The scripts also contain all of the added niceties
that were requested previously (single step booting, sane boot logging,
distro independence, verifying weather a pid file is sane, validating
signal name/number, etc.).  In addition to the above, we no longer need
to keep track of the symlink number of a script, this is totally
dynamic.  I think they are ready for prime time, everyone should really
should give them a try on your next build.

As far as chkconfig, I'm personally not a fan, just because it
duplicates the purpose of the LSB tools, but it does allow you to change
started runlevels which the LSB tools do not (I'm pretty sure that would
conflict with Dan's tools, so if we did that, we'd need to use what RH
and others use for the install_initd and remove_initd tools (which
require python IIRC).  IMO, it would be easier to just edit the runlevel
header information in the script rather than using chkconfig.

Also, the service program could easily be a function provided in
/etc/profile.d/ if the magic to build it is not found easily
in sysvinit.

- -- DJ Lucas
Version: GnuPG v2.0.15 (GNU/Linux)


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

More information about the lfs-dev mailing list