On Thu, Sep 15, 2011 at 1:59 PM, Mick <michaelkintz...@gmail.com> wrote: > On Thursday 15 Sep 2011 16:13:26 Michael Schreckenbauer wrote: >> On Thursday, 15. September 2011 16:48:45 Joost Roeleveld wrote: >> > I agree he is wrong about the solution as well. >> > >> > I have actually just posted my idea to the gentoo-dev list to see how the >> > developers actually feel about possible splitting udev into 2 parts. >> >> I've read it there. Thanks for doing this. > > Thanks Joost for posting in the dev list and for explaining your proposed > approach there. I've just read your thread in the dev list: > > http://thread.gmane.org/gmane.linux.gentoo.devel/72969 > > > Zac's response helped me understand better what the Gentoo devs have been > suggesting here: > > http://archives.gentoo.org/gentoo-dev/msg_020fa80d72c84c5b587b90d8001264ef.xml > > and it does make sense - their version of initramfs-'lite'. > > From what I understand: > > 1. The minimal initramfs will only need to be built once (and rarely rebuilt > thereafter). This removes one of my fears and it was a main objection for me > - I would hate to have to rebuild initramfs every time I roll a new kernel, or > libs and what not of fs happen to be udpated, etc.
In my experience, it takes more time to build the kernel than it takes to rebuild the initramfs. And if you choose to use dracut, the process is automatic (you always call dracut with the same options, unless you suddenly add LVM or something similar). I didn't use an initramfs for my first years using Gentoo. Since I started to use media-gfx/splashutils a couple of years ago, every time I upgraded my kernel, I splash_geninitramfs'd my initramfs. Now I do the same, but with plymouth and systemd using dracut. It's just part of the process of getting a new kernel. > 2. If initramfs fails, then Zac says it will drop you into a minimal shell, so > we should still be able to recover/troubleshoot/reboot from there. >From the last response in the -dev list (from Rich Freeman): “It should be noted that the alternative is to use a more full-featured initramfs like dracut, which will also be updated to support mounting /usr (it already parses /etc/fstab to remount root anyway). ... Note that dracut does drop you to a shell if it fails (this is configurable), but by default this shell is dash, not bash. No doubt it would work fine either way, but bash is likely to be a little slower. I don't think RAM use is likely to be a problem - it should be completely de-allocated before init runs.” > The only drawback is the 2 minutes it will take a user the first time this > change is introduced to build the initramfs and change the kernel line in > grub.conf. I am warming up to this proposal because it seems to me that it > will end up being less painful that I originally thought. Reading the homepages of the projects involved always helps to better understand the possible outcome of using the new technologies. Perhaps you should take a look at dracut: Maybe a complete initramfs solution will convince you, especially if an initramfs will be needed anyway. > However, I still see it as a workaround to a more elegant solution, which as > Joost and others suggest would involve separating udev's probing for devices > with the rules running of scripts for them. Maybe that's the more elegant solution. Certainly it will take a lot more effort, in the sense that somebody has to implement, test and debug said solution. I sincerely wish them good luck. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
