On Fri, Feb 24, 2012 at 5:41 PM, Bryce L Nordgren <bnordg...@gmail.com> wrote: > > > On Thu, Feb 23, 2012 at 11:49 PM, Mathijs Kwik <math...@bluescreen303.nl> > wrote: >> >> This patch forces loading of the btrfs module for everyone, and the >> inclusion of the "btrfs" tool in everyone's initrd. >> >> Perhaps you can just use boot.initrd.kernelModules and include btrfs >> there? >> Normally, it seems nixos' initrd builder detects the filesystem type >> that / is on and includes the needed filesystem module in the initrd. > > > Tried that. No go. Correct me if I'm wrong, but I think initrd is "stage1" > and filesystems.nix, as an upstart job, runs after the stage2 kernel is up > and more or less stable. Maybe we need a boot.stage2.kernelModules?
You are right, but it shouldn't matter. If you load modules in initrd, they stay available for the full run of the system. Anyway. There's also boot.kernelModules. Those get loaded in stage2 and aren't included in the initrd. In your case, where your root fs isn't on btrfs, including the module there should still be fine. > > This patch may be broken, but it's a lot less broken than dropping into an > emergency recovery shell on every boot in the name of saving everyone an > extra kernel module. :) A module that might not be available on some architectures / older kernel versions / custom configs. > > > >> >> Can you make these 2 lines (modprobe / scan) optional, depending on >> any filesystem having an explicit "btrfs" fsType in configuration.nix >> ? >> Then you just need to flag that if you are running a multi-disk btrfs >> configuration. > > > I can take a swing at adding a "btrfs" flag to the module. Expect that my > initial attempt to be crafty will turn out clumsy and awkward, tho. A more > elegant way would be to scan thru the fs types option list in order to > determine if btrfs is specified for one of the mountpoints. I don't know > how one might do that tho. Any clever ideas? Yes, that's what I meant. Scan through configuration.nix's filesystems list for any item with an explicit btrfs fsType (as opposed to just leaving fsType out, which works fine in most setups). I didn't mean adding an extra flag, sorry if I wasn't clear :) I attached a patch that does just that. So if you take care of loading the module in any of the 2 stages (boot.kernelModules should be fine in your case (non-root)), this should have the same effect as your patch. Can you give it a try and report back here (don't forget to cc nix-dev)? Mathijs > > It may be a more pervasive error than just multi-disk configurations. My > btrfs mountpoint is not the root disk (so its not handled by initrd or > grub), and I'm mounting it using the label. I can't prove it, but I suspect > that any of these three conditions may drop the user into an emergency > recovery shell. > > Bryce
0001-optionally-run-btrfs-device-scan-during-mountall.patch
Description: Binary data
_______________________________________________ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
