On Fri, 2010-06-11 at 22:19 +0200, Daniel Baumann wrote: > is it? there are many things that don't work properly once you don't > use > an initrd with initramfs-tools. Does it? I did so very long and still have several systems that use no initrd. I think we should not start to "force" users to using such things, if not necessary :)
> i'm not sure it's worth the effors to support non-initramfs related > things, in particular because the fsck -a goes away at some point > anyway Uhm... you mean btrfsctl -a? Or btrfsck -a? Has upstream announced this? And is the module than doing the scan? > (am currently thinking about just applying the patch to add -a and be > done with it). Well perhaps you can have a look at that redhat udev thingy,... (I'm absolutely no udev expert ^^) whether this is a better solution. In the end I'd like to see that both initramfs/non-initramfs systems support this,... and that stuff is only added to the initramfs if needed (see #584714) :) > > 2) Does btrfsctl automatically load the btrfs module, or do we have > to > > manully do that before? (which is somehow ugly IMO) > off-hand i'd say no, but didn't check (rebooting now sucks :). ^^ dito ;) > > 4) Is there a good way to prevent doubled scanning, if that already > > happened in the initramfs? > the initramfs script could touch something in /var/tmp (or somewhere > like that), and the initscript could skip if the file is found. Yeah,.. the would also be the first solution that came across my mind,.. but better /tmp,.. I guess, as /var/tmp is not clean Cheers, Chris.
smime.p7s
Description: S/MIME cryptographic signature
