Re: [gentoo-dev] rc-scripts speedup - or not :/

[Joseph Carter <knghtbrd@efn.org>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sun, Apr 20, 2003 at 05:03:39PM +1200, leon j. breedt wrote:
> sorry about blowing smoke...i think i just witnessed one of faster bootups
> after changing to LC_ALL=C. this will teach me...

I have gotten fast booting of a Gentoo box nearly down to a science at
this point.  ;)  Setting LC_ALL=C is not something I've done yet.

I have a notebook which lacks APM and found swsuspend unstable.


My assumption was that there were core things which must be done before I
login to the system, and anything else could be done behind the scenes.  I
have actually speculated that it is probably safe to build a config which
does little more than mounting filesystems, bringing up lo, and starting a
display manager.  I'm not that far along yet.  Here's what I have done so
far:

My kernel has everything built as modules which can be, but it still takes
too long to boot.  (Before I modularised everything, the kernel itself
took 14 seconds, now it's about 10 seconds..)  I do not know how to make
it any faster to boot.  Tips here are welcome.  Keep in mind I am not
looking for the "feel" of being fast.  I'm doing this with a stopwatch.

Runlevel boot contains bootmisc, checkroot, clock, hostname, localmount,
modules, net.lo, rmnoilogin, and urandom.  I've modified modules to simply
perform the modprobing in the background, and I do not bother to print out
the eend for the notices of module loading.  Everything else normally in
boot was removed because I don't need it.

Runlevel default has been totally gutted.  It contains metalog and extra,
that is all.  I'm not sure metalog will not be removed soon.

Runlevel extra is interesting.  Here is /etc/init.d/extra:

#! /sbin/runscript

depend() {
	after *
}

start() {
	/sbin/telinit b &>/dev/null &
}


The things that actually live in runlevel extra are cupsd, gpm, ifplugd,
local, metalog, and pcmcia.  The inittab line basically starts this in the
background with output sent to the bitbucket.

It still takes a significant amount of time for the services to all start,
but they need not be running at that point, so I don't have to care.


Before I began this effort, I found two problems.  First, as soon as the
e100 module was loaded, hotplug would be intelligent enough to try and
load the damned network script.  Absolutely brilliant, given that it's a
laptop, the ethernet connector is permanently affixed, that net.eth0 does
not as Gentoo provides it support anything more intelligent than dhcpcd,
and that I almost never plug in an ethernet cable unless I'm leeching.  I
have ifplugd to handle this interface.

Why is this significant?  It added several seconds to the boot sequence as
runlevel 3 tried to down eth0, which meant letting dhcpcd sit there for as
much as ten seconds attempting to commit suicide.  I spent nearly an hour
trying to figure out how it was getting started, and modified net.agent to
treat eth0 as an assumed preconfigured interface.  Some mechanism to tell
hotplug to not try to configure certain interfaces other than editing bash
scripts would be nice.

Another error which was pre-existing and never isolated is this:

insmod: insmod: a module named usbcore already exists
insmod: insmod: insmod
/lib/modules/2.4.20-acpi-r9/kernel/drivers/usb/usbcore.o failed
insmod: insmod: insmod usbcore failed

I cannot find what is attempting to insmod usbcore.  In fact, I cannot
find any scripts which call insmod at all in /etc or in /sbin.  hotplug's
usb-agent will try to modprobe it, but that's not an issue really since
modprobe would deal sanely.  I am considering that I might want to modify
init.d/modules to modprobe certain things at boot time and certain other
things in extra.

I guess it might work to grab the most current initscripts, but my
notebook is a machine which really should not be compiling all the time,
so I've been hesitant to run ~x86 when not necessary.  Doesn't seem to
matter though, /sbin/rc is basically the same as on my notebook and that
is probably where further optimisations would be made.

I welcome assistance, a clue where the above insmod error is from, and a
suggestions as to how to get the boot under 17 seconds.  This is down from
24, but I am aiming for less still.  (I note that booting Debian used to
take over a minute on my notebook..)

- -- 
Joseph Carter <knghtbrd@efn.org>                      This end upside-down
 
"Nvidia's OpenGL drivers are my "gold standard", and it has been quite a
while since I have had to report a problem to them, and even their brand
new extensions work as documented the first time I try them.  When I have
a problem on an Nvidia, I assume that it is my fault.  With anyone else's
drivers, I assume it is their fault.  This has turned out correct almost
all the time."
        -- John Carmack
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: 1024D/20F62261F1857A3E79FC44F98FF7D7A3DCF9DAB3

iEYEARECAAYFAj6iWDYACgkQj/fXo9z52rPUWgCeLyIne2AvXyhy+rBAl60ZNl3e
VSMAn0hfI4plMCdWSyGYROlLOkz1fXTV
=69Ch
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list