[gentoo-dev] Re: usr merge

[Duncan]

Luca Barbato posted on Sat, 09 Apr 2016 15:03:15 +0200 as excerpted:

> On 09/04/16 14:37, Rich Freeman wrote:
>> I've certainly haven't had many problems with dracut.  When it fails it
>> is usually because I'm doing something ELSE that is off-the-wall and it
>> just doesn't have a plugin for it yet.  (And in those cases it isn't
>> like the kernel tends to get it right without an initramfs.)
>>
>> I'd certainly want to test it on a merged /usr, but I'd be surprised if
>> it doesn't work, since it was designed to run on distros that are using
>> a merged /usr.
>
> I think that should be the first thing to do not the last one =)

FWIW, dracut works just fine with a "reverse-merged" /usr (usr -> .), as 
well as the bin/sbin merge.  And if it works with that, it'll certainly 
work with (normal) merged usr, as AFAIK upstream's fedora/rh sponsored.

>> In an ideal world, you might argue that / should just be a tmpfs or
>> something almost as ephemeral.  It is just a place you hang everything
>> else off of.

> That would be the core concept, but then you can just not have /bin
> /sbin /lib

That's in the context of (forward) /usr merge, which would make all those 
symlinks to the appropriate /usr location anyway.  Those symlinks could 
of course be created dynamically, as could the various mountpoint 
directories.

Of course /etc would have to be dynamically mounted in that scenario as 
well, but that's not a big issue as long as there's an initr*

I actually thought about doing a tmpfs-based / here, or effectively just 
never doing the pivotroot off the initramfs, with everything else 
dynamically mounted over top the initramfs dirs, but decided to go a 
different way instead, putting (almost) everything installed by the PM 
on /, and doing a reverse-/usr-merge, with /usr -> . , with / then ro-
mounted by default.  Seemed simpler for what I wanted to do than the 
tmpfs or stay-on-initramfs / route.

>> The thing I like about the merge is that it basically puts all your
>> distro-supplied stuff in one place.  /usr basically becomes the OS
>> minus state.  If things started out that way and you just had a short
>> stub loader that gets things initialized, and I were arguing that
>> instead of that little initialization stub you should break up /usr so
>> that the root count mount /usr, would that sound all that compelling? I
>> think having it all in one mountpoint seems a lot more compelling.
>
> you cannot ever have everything in 1 mount point, you just move the
> problem somewhere else you notice less (initramfs), but the problem
> remains and either is solved or not.
>
> having everything in /usr and then copy it over ${somewhere} is there,
> it can be debated if /bin or initramfs is the best place to put it.

I suppose many of us have made that point at least to ourselves, at some 
point. =:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman