Changes to contrib bootscripts

DJ Lucas dj at linuxfromscratch.org
Sun May 22 20:20:12 PDT 2011


On 05/21/2011 12:32 PM, Jeremy Huntwork wrote:
> On 5/21/11 12:52 PM, DJ Lucas wrote:
>> Oh, I didn't realize that it had continued beyond the new network script
>> and ifup/ifdown scripts, or rather I read it as just example, not an
>> actual suggestion. Give me a few minutes to run through the thread again.
> I didn't actually see the new scripts. I took a cursory look at what was
> in subversion and it looked the same as before... Maybe I missed something?
>
> JH
Well, so much for a few minutes. As far as what has changed at this 
point, ifup and ifdown were completely rewritten for use in /sbin (help 
text added, -d option for a configuration directory, -c option for a 
configuration file (used by the updated network script), -f option to do 
a flush and down of interface in ifdown, and long "--" options are 
accepted for each). I have come to the conclusion that it'll have to be 
made modular for BLFS purposes, and each of the network service scripts 
adjusted to account for the added functionality. Basically, at the end 
of the network script, cycle through all network interfaces in 
/sys/class/net/*, and run each interface name through the available 
scripts in /lib/network-devices to see if the associated service is 
running for the interface, and kill it if so. The default ipv4-static 
and ipv4-static-route scripts will be excluded as when the interface 
link is set down, the kernel will take care of any actual ipv4 or ipv6 
addresses and routes in the kernel routing table.

Also, any issue with reverting back to /etc/rc.d/* on your end? This 
appears to work with shipped package bootscripts if a /etc/init.d -> 
/etc/rc.d/init.d symlink is created. If so, it will be a simple Makefile 
value change (make ETCDIR=/etc install) as I'll take care of fixing the 
path in /etc/default/rc in the Makefile and in process-scripts.sh for 
the book.

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