Simplifying the LFS Bootscripts

Bryan Kadzban bryan at kadzban.is-a-geek.net
Sat Jan 8 15:16:23 PST 2005


Nathan Coulson wrote:
> a) createfiles could be moved to BLFS

I think that probably makes sense.  Now that udev is a lot more mature
(and so are most kernel drivers), there's a lot less need for creating
devices with createfiles.  I can't think of anything else I'd use it for
on boot either (though that doesn't mean there isn't anything...).

> b) ifup and ifdown check for onboot, we could move that check over to
> network again, and take out the hotplug check [People report it does
> not work as I expect anyway].

I assume you mean move the [ "$ONBOOT" = "yes" ] (or whatever it looks
like) check from the ifup/ifdown script into network?  This would
increase the size of the network script's for loop, but that's not a
huge deal.  Plus it would save one script execution if ONBOOT was no.

> c) could simplify ifup and ifdown, if they "only" check for 
> /etc/sysconfig/ifconfig.eth0/*, and do not check for additional 
> options for individual scripts

I think that makes sense too.  No sense in putting checks in there for
services that aren't going to be used.  (If I understand the issue here,
anyway.)

> a) Kevin says that ip up "interface" check in ifup will cause
> problems with ppp, and other simular protocols

This makes sense to me.  I know that (at least with PPPoE) the ppp*
interfaces won't exist unless and until pppd is actually running.  But
the bootscript is what will start it up, so if the bootscript bails,
then it won't do any good.

Maybe another variable in the sysconfig file, to tell the script which
interface to ensure the availability of, or if it's set to "none" then
skip the check?  Of course, that will re-complicate the scripts a bit.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfromscratch.org/pipermail/lfs-dev/attachments/20050108/2b4b9b96/attachment.sig>


More information about the lfs-dev mailing list