Bootscript Future

Nathan Coulson conathan at
Thu Jul 15 13:31:27 PDT 2004

> Nathan Coulson wrote:
>> I noticed there have been some complaints about the current status of
>> the
>> lfs-bootscripts with their position within the LFS Project, and I wish
>> to
>> (hopefully) find out what we [The Bootscript Team (whoever's left)] can
>> do
>> to help.
>> First off, I dont believe the scripts should be able to handle any
>> situation on their own, but can be extended to handle any situation.  To
>> that end, I am attempting not to fix user mistakes in customization, or
>> automatic detection of what should be done.  In the event I do correct a
>> user, I attempt to provide a warning message to the user.
> I read the wiki page and I agree with this.  That would dumb down the
> user responsibility way too much.
>> Next, I am going to break up the scripts into their subsections, to give
>> a
>> more individualized view [giving the users on this list a chance to
>> comment on key decisions].
>> a) I layed down a base set of policies which the scripts "should" follow
>> at
>> [that reminds me, I should wipe the 2.1 migration text now that it's in
>> the book].
>> b) Udev and Hotplug: I am not entirely satisfied with these scripts as
>> of
>> yet, but they do work fine.   (Please note that the hotplug script is
>> not
>> installed by default)
> How are you going to handle the split (or difference) between the three
> tiers of development in your scripts?  For example, today stable has one
> version of the scripts - good.  Then testing and unstable seem to be
> sharing a version that includes both udev and hotplug, but both of those
> things are not in both places.

Well, right now we have a contrib directory for additional scripts
submitted by users, that could be of use to the end user, but not
installed by default [Hotplug used to be there, then I threw it in the
main scripts when it "appeared" that it would be going back to stable] 
(make install-hotplug still installs it)

In the past, Zack started making alternative sets of bootscripts, but I
got them synced up via use of the contrib dir.  I dont really want to be
supporting 2 simular yet different sets of bootscripts if there is no

>> c) modules: This script provides automatic loading of modules at
>> boottime.
>>  I would prefer alternatives to using this script, but I do not have any
>> better ideas at this current time.  Other then that, it is a great
>> script
> I don't do modules, so I can't properly comment.
>> d) Networking: I am farely happy with the current state of the
>> networking
>> system.  You can configure it through user customized files, which are
>> run
>> by a script named in the SERVICE= line.  With the move to directory
>> based
>> configuration, we can return to configuration by the name of the
>> internet
>> interface, fixing a few scripts in BLFS.  Easly extended onto by adding
>> new user created service scripts [or blfs].
> I like the new network stuff as well.  I need to learn iproute2 now.
> This kind of stuff probably needs to either end up in the book or the
> book needs to provide pointers to documentation on iproute2.  ifconfig
> has been around for a long time and so a lot of folks will not know
> about this different package.

in the past, it appears the LFS Project prefers to point to documentation
over including it themselves.  (although I dont think there is a suitable
location for such a link as of yet).  In the other packages included in
the book, we usually dont say how they work and therefore it'll have to be
mentioned in relationship to the bootscript configuration themselves
if/when we provide more information.

(Currently I do not decide what documentation goes into the book, and
therefore the above will have no impact on what actually happens in the
book.  I am just basing it on statistical information I have observed over
the last few years, and what may happen because of our current policies).

BTW, here's something I've been looking through lately, perhaps it'll help out
whoever reads this email.

>> e) functions: bunch of functions used by all the scripts.  It does seem
>> a
>> bit overbearing to new users at this time.
> I see this as an excellent educational opportunity.  I think having the
> entire scripts in the book is overkill, but dedicating a chapter or at
> least a few pages in the book on the subject of the scripts would be
> great.  The package needs good documentation (as all good packages need
> documentation), so why can't the LFS book provide the medium?
> chapter07/usage.html is a small start.  We could go into more depth
> though.

Well other then that README file I was working on, and the comments within
the scripts, we really dont have any further documentation.  I would love
to see a page or two on configuring some things within the bootscripts, so
users can do what they like with their system.  (At this particular time,
I dont have the time to do this myself)

I think Nick may be writing something about them, but not sure what his
plans were. (sorry nick, if this was supose to wait)

>> f) createfiles: when I had /tmp erased at shutdown, I wanted a way to
>> make
>> sure that files/directories could be created at startup [Nice way to
>> populate /tmp, or /var/run].  Zack Winkles built this for me.  Since
>> this
>> exists, it will help simplify some configuration in the BLFS book, or
>> hints.
> I don;t see any issues here.
> Overall, I like the package.  I know some think that we should tell the
> user how to write their own.  That could be a book in itself.  Scripting
> is not simple, it takes skill - especially the stuff you guys are doing.
>   Requiring the user to type in the scripts by hand would be very error
> prone and could easily increase the traffic on -support.  Requiring the
> user to write their own from scratch would significantly raise the bar
> to entry for the book IMO.  Even with direction, we would have to do a
> lot of writing to do that.  This would also significantly increase the
> traffic on -support.  I still think we can come to a compromise for both
> camps here.  Have the scripts provide base functionality for the book
> like you have done.  If you provide more in the package than the book
> requires, then have the Makefile provide the targets that we need to
> only install the bare bones stuff.  Put in the book and/or README that
> there is more if you want/need it or just ant to try it out.  The book
> would not go into any more detail about that, it would be up to the
> reader to explore.  The scripts are customizable and with good
> documentation provide a means of education and the ability to
> add/remove/hack/whatever to each user's content.  I change them some,
> for my own needs.  It took me awhile to read through the code to figure
> out what they were was doing, but I got it eventually.  There is still a
> lot I don't get, but hopefully the next book can alleviate that issue.

It is probably true, that people writing their own scripts would add alot
of complexity to LFS, and increase our lfs-support problems.

What kind of changes have you made?  I unfortunately do not really know
what people do with the LFS-bootscripts once they install them.  (I know
some used the createfiles thing mentioned above to make /dev entries for
things that udev misses, and I wanted it there for XFree86's
/tmp/.ICE-unix. [since I put in the changes to wipe /tmp])

I do not believe much can be done before the LFS 6.0 release, unless we
had more volunteers familiar with the bootscripts able to write some nice
documentation on how to use some of the options, or to document how the
functions in /etc/rc.d/init.d/functions work.

BTW, if you notice things that do seem overly complex, just drop me a
line.  If the scripts themselves are their documentation, it helps when
they're readable.

> James
> --


More information about the lfs-dev mailing list