Re: [gentoo-dev] Re: udev <-> mdev

[Rich Freeman]

On Sat, Jul 14, 2012 at 9:02 PM, Duncan <1i5t5.duncan@×××.net> wrote:
> Rich Freeman posted on Sat, 14 Jul 2012 19:57:41 -0400 as excerpted:
>>
>> I doubt anybody has tried it, so you'll have to experiment.
>
> "Anybody" /anybody/, or "anybody" on gentoo?  FWIW, there are people
> running it in general (IIRC much of the discussion was on Debian, some on
> Fedora/RH), but I didn't see anything out there written from a gentoo
> perspective.

I'd think that a source vs binary distro wouldn't matter much as far
as a tmpfs-based root goes.  That is, if you're taking about an empty
root that you just mount stuff on top of.

>> I imagine you could do it with a dracut module.  There is already a
>> module that will parse a pre-boot fstab (/etc/fstab.sys).  The trick is
>> that you need to create the root filesystem and the mountpoints within
>> it first.  The trick will be how dracut handles not specifying a root
>> filesystem.
>
> While I do know dracut is an initr* helper, you just made me quite aware
> of just how much research I'd have to do on the topic. =:^\   I wasn't
> aware dracut even /had/ modules, while you're referring to them with the
> ease of familiarity...

See:
http://rich0gentoo.wordpress.com/2012/01/21/a-quick-dracut-module/

Much of dracut's power comes from its modules.  Again, I'm not sure
how it handles not being given a root at all.  You'd have to build a
root, or extract it from a tarball/etc.

Looking at the docs it seems like you'd need a hook for the cmdline
stage that sets rootok (assuming it gets that far without a root, or
if you set it to something like root=TMPFS).  Then you'd install a
hook to mount to mount the tmpfs, and then use the fstab-sys module to
mount everything else.  You'd need to create mountpoints for
everything of course, and not just the boot-critical stuff, since
otherwise openrc won't be able to finish mounting mounting everything.

>
> The big problem with btrfs subvolumes from my perspective is that they're
> still all on a single primary filesystem, and if that filesystem develops
> problems... all your eggs/data are in one big basket, good luck if the
> bottom drops out of it!

Maybe, but does it really buy you much if you only lose /lib, and not
/usr?  I guess it is less data to restore from backup, but...

The beauty of btrfs subvolumes is that it lets you manage all your
storage as a single pool, even more flexibly than LVM.  Sure, chopping
it up does reduce the impact of failure a bit, but I'd hate to have to
maintain such a system.  Filesystem failure should be a very rare
occurance for any decent filesystem (of course, this is why I won't be
using btrfs in production for a while).

Rich