You are not logged in.
Pages: 1
Interesting article: http://lwn.net/Articles/299483/
If this is possible with Fedora, it should be possible with Arch, no?
In my specific case, I think udev is causing 10-15 seconds to populate /dev and connecting to the WPA2-network takes also 10 seconds. I might look into using udev only for removable storage - looks interesting.
Zl.
Offline
Well, speeding up Arch is going to be fun - unless you more or less forked the distro, you probably wouldn't get better than just short of 10 seconds, since udev is run twice: once in the initramfs disk to scan for HDDs and such, and again once the hard disk has mounted and all, and you'd have to do some serious hacking to make the initramfs get by without running udev that first time.
-dav7
Last edited by dav7 (2008-10-10 17:10:30)
Windows was made for looking at success from a distance through a wall of oversimplicity. Linux removes the wall, so you can just walk up to success and make it your own.
--
Reinventing the wheel is fun. You get to redefine pi.
Offline
This blog from a mandriva dev talks about reducing boot times in a broader sense, rather than a "how I hacked my boot times for this 1 specific computer" sense.
ARCH|awesome3.0 powered by Pentium M 750 | 512MB DDR2-533 | Radeon X300 M
The journey is the reward.
Offline
Well, speeding up Arch is going to be fun - unless you more or less forked the distro, you probably wouldn't get better than just short of 10 seconds, since udev is run twice: once in the initramfs disk to scan for HDDs and such, and again once the hard disk has mounted and all, and you'd have to do some serious hacking to make the initramfs get by without running udev that first time.
No serious hacking required. Just recompile the kernel to not use initramfs at all and use an old fashioned static /dev filesystem. People used to do that instead of using devfs, I don't know of anyone doing it instead of udev, but I don't see why it couldn't be done trivially.
Dusty
Offline
They've also hacked seriously the X server (without releasing the code), and they got 5 seconds only with an SSD drive... on magnetic hard drives their modified version of fedora would boot twice slower
Major distributions are already working on boot times, we'll see... for the moment Arch boot process still remains the better!
Offline
Old topic, but; has anyone tried it? git://git.kernel.org/pub/scm/linux/kernel/git/arjan/linux-2.6-fastboot.git
Offline
I'm trying to try it, but I'm having some troubles 'cause I don't really know what I need or don't need to have built-in.
Offline
the bigest thing in my boot is udev, in that atricle, it mentioned using a static /dev folder, instead of udev, how would i go about doing this?
Desktop: E8400@4ghz - DFI Lanparty JR P45-T2RS - 4gb ddr2 800 - 30gb OCZ Vertex - Geforce 8800 GTS - 2*19" LCD
Server/Media Zotac GeForce 9300-ITX I-E - E5200 - 4gb Ram - 2* ecogreen F2 1.5tb - 1* wd green 500gb - PicoPSU 150xt - rtorrent - xbmc - ipazzport remote - 42" LCD
Offline
Compiled 2.6.27 with http://www.thinkwiki.org/wiki/Fastboot_Patch_2_6_27 and CONFIG_FASTBOOT=y , shaved some seconds of the boot time, but have not measured it exactly yet.
Offline
Compiled 2.6.27 with http://www.thinkwiki.org/wiki/Fastboot_Patch_2_6_27 and CONFIG_FASTBOOT=y , shaved some seconds of the boot time, but have not measured it exactly yet.
How do you do that exactly?
Archi686 User | Old Screenshots | Old .Configs
Vi veri universum vivus vici.
Offline
Was lazy and didnt use a pkgbuild:
http://kernel.org/pub/linux/kernel/v2.6 … 27.tar.bz2
untar
patch -p1 < fastboot_2_6_27.diff ( http://www.thinkwiki.org/wiki/Fastboot_Patch_2_6_27 )
Follow http://wiki.archlinux.org/index.php/Ker … nal_method and add CONFIG_FASTBOOT=y to config
Dunno if there's a diff for 2.6.27.4 or if it works anyway
Offline
I've been using fastboot for a few weeks so far. It definetly speeds up the kernel part of the boot process. Haven't noticed it breaking anything yet so far.
Offline
Alright, thanks FALK
Archi686 User | Old Screenshots | Old .Configs
Vi veri universum vivus vici.
Offline
Pages: 1