A faster default

RedShift · 2009-01-26 10:26:45

This is a dangerous modification, and could (and will) lead to race conditions. All this backgrounding stuff may make your system boot faster but will make it unreliable as a side effect.

vh22 · 2009-01-26 15:19:12

I've been exploring the rc.sysinit file a little more. I originally thought no race conditions would occur since you leave the settle command in the foreground, so the boot process would wait at that step anyway. I see there is a race condition now because both udev and the rc.sysinit script will be loading modules, but from what I can tell, it is a relatively harmless race condition. The worst that could happen is the script tries to load a module udev already loaded or vice versa.

I have been using this since I posted it on a system thats rebooted about 3 times a day (its a laptop). So far no failed boot.

I tried this and had problems! I do network with wicd, which is started as daemon. On standard configuration it connects to my wireless and wired networks without any problems. When I did this change, the boot was really a bit faster, but no internet at all, even restarting wicd daemon didn't help. So in my opinion this shouldn't become standard in Archlinux!!!
I'll try it again, maybe something else was the culprit, but I'm 98,54% sure

Not sure why this occured as I used wicd too with no problem. But if it was indeed this modification that caused problems, then I agree it shouldn't be made standard.

koch · 2009-01-26 22:39:30

i had problems too booting with wicd in rc.conf and the client in openbox autostart file but that doesn't matter to me because i start the client on demand.

(oh, i just saw that i am here since one year, cool, i missed my birthday)

Last edited by koch (2009-01-26 23:27:18)

B-Con · 2009-02-08 04:02:24

Note that this may create the *llusion* of a faster start time then what you actually get. Note lines 188 and 123, those take snapshots of the current time before and after the trigger and settle udev commands. By moving the udev trigger line out of that section, you effectively compute the time it takes for settle to run, which won't be long. That makes the "UDev uevent processing time" output useless.

Obviously if you use a stopwatch and watch your system boot, that will be reliable, but using the self-reported udev uevent processing time isn't helpful any more.

Last edited by B-Con (2009-02-08 04:02:40)

Duologic · 2009-02-08 11:56:21

true, the processing time you get from rc.sysinit is useless, most advance you'll see when you use a stopwatch or bootchart

Peterix · 2009-02-08 19:21:23

This isn't safe at all. If you speed up your boot beyond certain limit, you'll end up with unbootable system. Fsck needs properly created devices in /dev/ (so that mount works) and you're playing with fire here.
I solved that by making the devices in /dev manually like this:

mknod /dev/sda b 8 0
mknod /dev/sda1 b 8 1
mknod /dev/sda2 b 8 2

Obviously, it's an ugly hack.

Duologic · 2009-02-09 18:04:02

fire is fun :-)

Arch Linux

#26 2009-01-26 10:26:45

Re: A faster default

#27 2009-01-26 15:19:12

Re: A faster default

#28 2009-01-26 22:39:30

Re: A faster default

#29 2009-02-08 04:02:24

Re: A faster default

#30 2009-02-08 11:56:21

Re: A faster default

#31 2009-02-08 19:21:23

Re: A faster default

#32 2009-02-09 18:04:02

Re: A faster default

Board footer