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
