This bug is intented to be a holding place for ideas on how to
speed up startup.
Some ideas already bounced around:
Parallell init scripts
Lockfiles on a ramfs?
blocke on #rhl-devel mentioned that gentoo does this. Speculation
that it might improve startup times.
Try to startup up X once instead of twice (rhgb, [gxk]dm)
How about a simpler version of parallel init scripts: modify rc so that all
scripts with the same number get started || stopped in parallel in background?
It wouldn't gain as much speed as Ted / Richard's ideas, but it would be a lot
more compatible with standard SysV init behavior
If you don't care at all about compatibility, I've never seen a faster boot than
minit http://www.fefe.de/minit/ or http://www.fbunet.de/minit.shtml . It's a
little too similar to djb's wackiness for my taste, but it is quite speedy
there's also runit
http://smarden.org/runit/index.html which I've never tried, but looks similar to
It was also discussed on #rhl-devel that disk I/O and harddrive seek times was
what causes the apparent slowness in the bootup scripts.
I also brought up an extention of the "start X up only once idea" in that to
give the illusion of a faster boot system (for a better end user experience) the
following could be done:
For systems configured to use runlevel 5 as the default start X as soon as the /
partition and any other needed partitions (if /tmp is split out into its own,
etc) are mounted r/w. Delay the start of the graphical boot until this point
and reuse this copy of X to start gdm after the boot "appears" complete
(modification to gdm most likely needed).
While services such as portmap and xinetd (for fam), xfs, kudzu etc and such
should be up and running before gdm starts other services like sendmail, etc
could wait until after gdm is started on a desktop or workstation system. Again
its all to give the illusion to the end user which is important on a desktop
system. (Most likely this behaviour would be looked down upon for server
environments so a toggle in /etc/sysconfig would be desirable)
To avoid a race issue between X and the gettys a configurable hardcoded vt would
probably need to be assigned to X (as long as its configurable I personally
don't see the harm)
Also see http://www.fastboot.org
How about you make a way for the machine to tell the difference between starting
up from a halt (or poweroff) and a simple reboot. If it is just a reboot have
kudzu short circuit. That would save a few seconds right there. Just have to
document kudzu so that people know if they want it to scan they have to do a
init 0 and then restart, not an init 6.
Also, all network related services (that require network access to start) should
auto-detect an "up" interface, (no up interface, just fork a wait and retry
process into the background and exit the current process so the boot will continue).
Also Interfaces should have an option in the ifcfg-DEVX file for
"MII-TOOL-COMPATIBLE=[yes|NO]" or "ETH-TOOL-COMPATIBLE=[yes|NO]"
if one of these options is present, and the interface is active when the service
is starting, then the service startup script will check for the presence of
"LINK STATUS GOOD" if there is no link status on any of the active interfaces,
then the startup script should fork a "wait and try again later" process into
the background, and then it should let the boot process move on.
We already check for link before bringing up any DHCP interface; moreover,
there's no reason to specify separate ethtool/miitool settings; everything in
the future should support ethtool.
I agree there's no need for separate mii-tool and ethtool settings but PLEASE do
add such an option - as long as there are drivers not compatible with neither...
It's nothing short of ugly to have to do chmod a-x /sbin/ethtool kind of stuff
to disable link-up detection for incompatible drivers.
Any such drivers should be reported as kernel bugs, seriously, as that means the
driver is returning *wrong* results. If the tools return 'not supported', we
assume the link is *up*.
Ok, will do so from now on. Last I checked pcnet32 driver could crash the whole
box just by running mii-tool as a normal user but that was quite a while ago,
need to recheck.
However I still think having such an option would be good as there really isn't
any guarantee AFAIK that new drivers will automatically support ethtool. And
there are cases when you don't even *want* to check whether the link is up
right now (collague of mine just stumbled upon this a couple of weeks ago) -
don't remember off-hand whether the link-up check is done for interfaces with
static IP's but IIRC it is.
Nope, link check is only done for dynamic IP.
*** Bug 104968 has been marked as a duplicate of this bug. ***
Chris Ricker wrote:
> If you don't care at all about compatibility, I've never seen a faster boot
than minit http://www.fefe.de/minit/ or http://www.fbunet.de/minit.shtml .
LiNUX init _must_ be LSB compatible:
LSB init script tests - http://www.physik.fu-berlin.de/~tburnus/lsb/
Linux Standard Base Specification, System Initialization -
There is a /. article about "Replacing the Aging Init Procedure on Linux" at:
Note that minit is not really faster in and of itself; it's only faster if you
restrict *what it runs* (minit running the same script as regular init is only
faster by a couple of percent)
*** Bug 124406 has been marked as a duplicate of this bug. ***
*** Bug 132480 has been marked as a duplicate of this bug. ***
Has anyone at the Fedora team looked at initng? It's a quite new
project, but it's already stable enough for me to have it as default
in my Grub config. By switching from SysVinit to initng I shortened my
boot time by about 30 seconds.
Have a look at http://initng.thinktux.net/
I'm sure this has been thought of, perhaps it is already done.
Allow the user to start typing in the username and password during RHGB. I
spend 2-5 seconds at this screen depending on how co-ordinated I am at the time.
This would reduce the time to "login" for desktop users.
(In reply to comment #7)
> Also, all network related services (that require network access to start) should
> auto-detect an "up" interface, (no up interface, just fork a wait and retry
> process into the background and exit the current process so the boot will
However, NFS is a network related service, and if the /home directory is mounted
via NFS, then you wouldn't want to give desktop users the illusion that they
could log in before /home is successfully mounted!
Based on the date this bug was created, it appears to have been reported
against rawhide during the development of a Fedora release that is no
longer maintained. In order to refocus our efforts as a project we are
flagging all of the open bugs for releases which are no longer
maintained. If this bug remains in NEEDINFO thirty (30) days from now,
we will automatically close it.
If you can reproduce this bug in a maintained Fedora version (7, 8, or
rawhide), please change this bug to the respective version and change
the status to ASSIGNED. (If you're unable to change the bug's version
or status, add a comment to the bug and someone will change it for you.)
Thanks for your help, and we apologize again that we haven't handled
these issues to this point.
The process we're following is outlined here:
We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.
This bug has been in NEEDINFO for more than 30 days since feedback was
first requested. As a result we are closing it.
If you can reproduce this bug in the future against a maintained Fedora
version please feel free to reopen it against that version.
The process we're following is outlined here: