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 http://lists.debian.org/lsb-spec/2000/lsb-spec-200002/msg00015.html http://www.atnf.csiro.au/people/rgooch/linux/boot-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 minit
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 - http://www.linuxbase.org/spec/gLSB/gLSB/sysinit.html There is a /. article about "Replacing the Aging Init Procedure on Linux" at: http://developers.slashdot.org/article.pl?sid=03/10/02/1553253&mode=thread&tid=106&tid=185
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 continue). > 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: http://fedoraproject.org/wiki/BugZappers/F9CleanUp 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: http://fedoraproject.org/wiki/BugZappers/F9CleanUp