From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 5F01659CAF for ; Sun, 10 Apr 2016 07:38:39 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id C5E5021C06A; Sun, 10 Apr 2016 07:38:29 +0000 (UTC) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id BCBB121C057 for ; Sun, 10 Apr 2016 07:38:28 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1ap9wr-0008Fo-S4 for gentoo-dev@lists.gentoo.org; Sun, 10 Apr 2016 09:38:22 +0200 Received: from ip98-167-165-199.ph.ph.cox.net ([98.167.165.199]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 10 Apr 2016 09:38:21 +0200 Received: from 1i5t5.duncan by ip98-167-165-199.ph.ph.cox.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 10 Apr 2016 09:38:21 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-dev] Re: usr merge Date: Sun, 10 Apr 2016 07:38:16 +0000 (UTC) Message-ID: References: <570312c8.1469ca0a.30985.5db1@mx.google.com> <95f08129-4b0e-56f9-0457-67aee185ccac@gentoo.org> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: ip98-167-165-199.ph.ph.cox.net User-Agent: Pan/0.141 (Tarzan's Death; GIT fb7f2ee) X-Archives-Salt: 1361b0dd-5e0c-4332-b4ce-02e92d6d1f67 X-Archives-Hash: 545206ae318d2784ae136e4b8cacdb62 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