Using the LSB Bootscripts

DJ Lucas dj at
Tue May 10 05:25:50 PDT 2011

On 05/09/2011 10:33 PM, Bryan Kadzban wrote:
> DJ Lucas wrote:
>> You know what? I think we are over thinking this. How about a state
>> file? Upon successful initialization of an interface, copy the config
>> file to a subdir of /run/network. The ifdown script sources the
>> running copy if it exists and removes it on successful stop of the
>> interface, or ip down interface if it does not exist and exits 0.
> Ooo, I like that idea.  :-)
> Now, to get time to hack it together...  :-(
I'm just about done with the DESTDIR POC (still need to add instructions 
to account for lib64 -> lib since I did this on multilib first) but that 
can use some time to mature a bit anyway, so should have time on Wed if 
one of y'all don't get there first.

The current task list is as follows (for which I believe we have 
consensus from those who have chimed in so far):

     * Most important, pull as much as possible of the items below from 
LightCube OS's files to ease merging and keep the diffs to a minimum so 
that they are easily shared across distributions.
     * Move ifup and ifdown scripts to /sbin.
     * Move network service scripts to /lib/services (there was one 
minor objection here, should that be /lib/network-services or 
/lib/network? I don't really have any preference here, /lib/services is 
fine by me).
     * Move network configuration files to /etc/network.
     * Move network (hostname value) and clock config into 
/etc/default/ (default to UTC?)
     * Use /etc/default for rc configuration files (remaining items in 
/etc/sysconfig currently).

And here is a summary of remaining items that have not come to consensus 
or haven't been brought up previously in this thread:

     * Add initd-tools to book - This is required for the new scripts. 
Jeremy what is the status on this in LightCube OS? I remember a few 
months ago about you possibly taking over maintenance of them, adding a 
service binary/script and such? At last check, Dan did not have them in 
an RCS, which is not an issue for now, just curious about the future of 
the tools. The tarball and homepage are available in Dan's home 
directory on if we need for the book. Dan?
     * Add configurable function to handle script errors in place of 
'read Enter'. Of course, the option exists to kill that completely, but 
it puts the error in plain sight for desktop users.
     * ifup - copy configuration file from /etc/network/$int/$file to 
/run/network/$int/$file upon successful initialization of the interface.
     * ifdown - source configuration files from /run/network/$int/*.
     * ifdown - if interface configuration files do not exist, ip addr 
flush $int, ip link set $int down, exit 0.
     * The three items above are the best I think we can do with it and 
should cover > 99% of all cases, the known exceptions being starting the 
dhcp client or ppp client manually, and possibly manual configuration of 
wireless interfaces (I've never configured wireless in LFS - also what 
about VPN tools started manually?). I believe Bryan is already on board 
with these changes, Bruce, Jeremy, Zach?
     * svn mv BOOK/bootscripts/contrib/lsb-v3 BOOK/LSB-Bootscripts.
     * merge necessary changelog entries and readme from original 
bootscripts with LSB-Bootscripts.
     * Add a copy of the MIT license file to bootscripts.
     * Add needed changes to book rendering for new bootscripts (I have 
this done locally).
     * I just noticed, need to fix setclock UTC logic to use case as in 
all others for 0|y*|Y*|t*|T*,1|n*|N*|f*|F*,* exit 2 (invalid argument).
     * Remove selective boot - personally I'd rather keep that in place 
simply because it was requested so many times in the past, but possibly 
disable the functionality by default?
     * Do something with the tmpfs used for the boot fact, we 
could probably setup the /run mount point directly in the rc script and 
remove it from mountvirtfs.

Hope I didn't miss anything, but I've got to go.

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