From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from <gentoo-user+bounces-136966-garchives=archives.gentoo.org@lists.gentoo.org>) id 1SDHlb-0000Bi-Fe for garchives@archives.gentoo.org; Thu, 29 Mar 2012 16:00:03 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 72298E0B50; Thu, 29 Mar 2012 15:59:42 +0000 (UTC) Received: from mail.muc.de (colin.muc.de [193.149.48.1]) by pigeon.gentoo.org (Postfix) with ESMTP id 630C6E06B7 for <gentoo-user@lists.gentoo.org>; Thu, 29 Mar 2012 15:57:46 +0000 (UTC) Received: (qmail 18211 invoked by uid 3782); 29 Mar 2012 15:57:46 -0000 Received: from acm.muc.de (pD951B3B6.dip.t-dialin.net [217.81.179.182]) by colin.muc.de (tmda-ofmipd) with ESMTP; Thu, 29 Mar 2012 17:57:44 +0200 Received: (qmail 7241 invoked by uid 1000); 29 Mar 2012 15:56:28 -0000 Date: Thu, 29 Mar 2012 15:56:28 +0000 To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Re: After /usr conflation: why not copy booting software to /sbin rather than initramfs? Message-ID: <20120329155628.GC2961@acm.acm> References: <20120327133728.GA3754@acm.acm> <01c301cd0c22$2fac1300$8f043900$@kutulu.org> <20120327142646.GB3754@acm.acm> <20120327154620.21440f87@digimed.co.uk> <86iphq0vza.fsf@jane.chrekh.se> <003e01cd0c53$a2e99b90$e8bcd2b0$@kutulu.org> <20120327212422.GA3437@acm.acm> <20120327234819.45111444@khamul.example.com> <20120327223544.GC3437@acm.acm> <01bf01cd0c9a$a2259000$e670b000$@kutulu.org> Precedence: bulk List-Post: <mailto:gentoo-user@lists.gentoo.org> List-Help: <mailto:gentoo-user+help@lists.gentoo.org> List-Unsubscribe: <mailto:gentoo-user+unsubscribe@lists.gentoo.org> List-Subscribe: <mailto:gentoo-user+subscribe@lists.gentoo.org> List-Id: Gentoo Linux mail <gentoo-user.gentoo.org> X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01bf01cd0c9a$a2259000$e670b000$@kutulu.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Alan Mackenzie <acm@muc.de> X-Primary-Address: acm@muc.de X-Archives-Salt: 02ed0722-6e27-4c65-9a74-a56f0101dae7 X-Archives-Hash: b22e83183b45c434f72e833a04175490 Hi, Mike. On Wed, Mar 28, 2012 at 12:24:14AM -0400, Mike Edenfield wrote: > > From: Alan Mackenzie [mailto:acm@muc.de] > > Hi, Alan. > > On Tue, Mar 27, 2012 at 11:48:19PM +0200, Alan McKinnon wrote: > > > On Tue, 27 Mar 2012 21:24:22 +0000 > > > Alan Mackenzie <acm@muc.de> wrote: > > Why is nobody else on this thread willing to take up its main point, > > the exact equivalence between the known, ugly, initramfs solution and > > the as yet half-baked idea of putting the same binaries into /sbin? > Well, for one, the initramfs solution is not generally considered "ugly" > except by a select vocal few who object to it on vague, unarticulated > grounds. I'll articulate a few. (i) The initramfs involves having two copies of lots of software around. (ii) What's more, these two copies are often different, one being built with static libraries, the other with dynamic ones. (iii) This situation is not (as far as I know) yet handled by Portage, which means in building such software statically, you've got to save the dynamic version somewhere else whilst you're doing it. (iv) The initramfs requires a potentially long script to make it work. I think that qualifies the initramfs solution as ugly. > That notwithstanding: > The binaries on the initramfs are not always the same as the ones installed > in the system; frequently they are statically linked versions, or > stripped-down versions, or otherwise unsuitable for being used after the > full system is booted. (Dracut, for example, forces you to add > USE=static-libs to a lot of the packages it wants to put into your initramfs > image.) Putting those binaries into the execution path of the system is a > bad idea because you don't always them to run once the system has booted -- > I want the full set of udev rules, not the bare handful that my initramfs > has on it. My idea was for /sbin to vanish from $PATH just as soon as the boot had been completed; PATH gets set anyway on the initialisation of something or other, so this would happen automatically, just like the initramfs disappears when the switch_root is done. > [ more criticism, a lot of which I accept. ] I think I have the elegant solution: that would be for the kernel to be able to mount several partitions at system initialisation rather than just the root partition. With this, all the issues we've been discussing simply wouldn't arise. I accept that this solution will never happen. Sadly. > --Mike -- Alan Mackenzie (Nuremberg, Germany).