You are not logged in.
Interesting topic. :)
Offline
Yes.
rezzo
Thanks you have got link to this topic in your sign.
MOD:
Maybe you can stick it?
Offline
Hello Everybody! I'm trying Archlinux but a newbie with Linux... and I have a little problem:
I followed the Zer0's tips and I've changed in the rc.sysinit the line "/sbin/modprobe $mod" into "/sbin/modprobe $mod &"
Now everything seems to work fine apart from a strange error that appears during the boot.. it says something like:
"/ETC/RC.SYSINIT: cannot redirect standard output from /dev/null no such file or directory"
What does it mean? How can I solve this? Have any suggestions?
Sorry for my bad english! :-)
Offline
make sure you added "&" to the correct location in /etc/rc.sysinit
Offline
nevermind, I followed the instrutions above oon editing /etc/rc.sysinit and now have the same error.....so I guess remove the "&" for backgrounding modules.
Offline
@somairotevoli: that's what i've done. Thanks :-)
Offline
I have written a howto on speeding up udev http://wiki.archlinux.org/index.php/Speedup_udev
Offline
I have written a howto on speeding up udev http://wiki.archlinux.org/index.php/Speedup_udev
Just a quick comment - modprobe.conf blacklisting is not the same as the way we do it. It will actually not work at all. Here's why:
modprobe's "blacklist" option blacklists modules loaded by that name and that name only. If I have:
blacklist foo
blacklist bar
And run "modprobe foo", it will not load foo. However, if some module "foo2" also depends on foo, "modprobe foo2" will still load foo because blacklisting does not match dependent modules.
Furthermore, all module loading at boot time is done via modalias lines and again these fail the modprobe basic blacklist check. If we modprobe "pci:23e4098349830348234" which aliases to "foo", it will still load it.
That's the whole reason we did blacklisting the way we did.
Offline
Thanks, that explains why blacklisting "the /etc/modprobe.conf way" doesn't always work.
I updated the wiki accordingly.
Offline
nevermind, I followed the instrutions above oon editing /etc/rc.sysinit and now have the same error.....so I guess remove the "&" for backgrounding modules.
So the suggestion of changing in rc.sysinit the line "/sbin/modprobe $mod" into "/sbin/modprobe $mod &" doesn't work?
ARCH64 | XMonad | Configs | myAURpkgs | ArchWiki Contribs | Screenies
Offline
somairotevoli wrote:nevermind, I followed the instrutions above oon editing /etc/rc.sysinit and now have the same error.....so I guess remove the "&" for backgrounding modules.
So the suggestion of changing in rc.sysinit the line "/sbin/modprobe $mod" into "/sbin/modprobe $mod &" doesn't work?
No, it doesn't.
stefan.
"root# su - bofh"
OS: F10_x64, Arch, Centos5.3, RHEL4.7, RHEL5.3
Desktop Hardware: Dell Precision M65 laptop, core2duo, 2gb, 80gb 7200rpm
Registered linux user #459910 since 1998
Offline
I have written a howto on speeding up udev http://wiki.archlinux.org/index.php/Speedup_udev
Using the technique described as "option 2" on the page linked above by nebygemini, I reduced udev processing time from 12 secs to 2.6 secs. I've only just rebooted for the first time, so there may be some unexpected consequences (i.e., glitches and gotchas), but so far this has been a very nice little time saver. I had just been wondering how to reduce udev processing time, especially since the processing time is explicitly reported by default on more recent releases.
Last edited by dhave (2008-03-08 14:13:39)
Offline
I found a blog about this arch boot discussion.
http://prasetyams.net/2008/06/27/speedu … t-process/. This may be helpful. I yet to try this one.
Offline
I tried the hack as said in the wiki I got only 2 sec improvement.For me waiting for the system to come up with few more seconds is not a big deal hence I got all things reversed to the normal system way. Any how such hacks give me the confidence to tinker the system. :-P.
Offline
I got some issues. I've disabled autoload moudles, changed udev, changed mkinitcpio hooks but now when I'm booting the system Loading Modules takes 16seconds before rest of the system is booted, so now it takes longer to boot. How to solve that?
Offline
revert the changes and do it step-by-step. i don't think anyone can give you more than a sophisticated guess here.
btw, major necrobump
no place like /home
github
Offline
btw, major necrobump
Indeed: https://wiki.archlinux.org/index.php/Fo … Bumping.27
Closing
Offline