[Nix-dev] [PATCHES] vsftpd and filesystems

Mathijs Kwik mathijs at bluescreen303.nl
Sat Feb 25 08:45:30 CET 2012


On Fri, Feb 24, 2012 at 5:41 PM, Bryce L Nordgren <bnordgren at gmail.com> wrote:
>
>
> On Thu, Feb 23, 2012 at 11:49 PM, Mathijs Kwik <mathijs at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-optionally-run-btrfs-device-scan-during-mountall.patch
Type: application/octet-stream
Size: 1482 bytes
Desc: not available
Url : http://lists.science.uu.nl/pipermail/nix-dev/attachments/20120225/aaff321b/attachment.obj 


More information about the nix-dev mailing list