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 ) id 1RjQFj-0008Ic-1y for garchives@archives.gentoo.org; Sat, 07 Jan 2012 06:59:43 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id B4FFF21C04C; Sat, 7 Jan 2012 06:59:32 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 203AF21C028 for ; Sat, 7 Jan 2012 06:58:59 +0000 (UTC) Received: from [192.168.26.5] (ip98-164-193-252.oc.oc.cox.net [98.164.193.252]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: zmedico) by smtp.gentoo.org (Postfix) with ESMTPSA id 79DF71B4004 for ; Sat, 7 Jan 2012 06:58:59 +0000 (UTC) Message-ID: <4F07ED32.2030707@gentoo.org> Date: Fri, 06 Jan 2012 22:58:58 -0800 From: Zac Medico User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:8.0) Gecko/20111120 Thunderbird/8.0 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 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] rfc: locations of binaries and separate /usr References: <1325616625.7238.23.camel@TesterBox.tester.ca> <20120103190255.GA13817@linux1> <20120103191206.GP780@gentoo.org> <20120103200120.GB13936@linux1> <20120103212215.GU780@gentoo.org> <20120103230918.GA7247@linux1> <4F03A1AA.6070205@gentoo.org> <20120104091743.0e1cd91a@pomiocik.lan> <4F0440B3.4090500@gentoo.org> <20120104163734.07439f2b@pomiocik.lan> <20120104163315.GV780@gentoo.org> <20120104174742.11d7002d@pomiocik.lan> <20228.34930.732592.657243@a1i15.kph.uni-mainz.de> <1325698374.22213.10.camel@TesterBox.tester.ca> <4F050DA9.4060704@gentoo.org> <4F07B7AC.8070007@gentoo.org> In-Reply-To: <4F07B7AC.8070007@gentoo.org> X-Enigmail-Version: 1.3.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Archives-Salt: 0ff62b92-def1-4acd-800b-95b561a12d5a X-Archives-Hash: ceb908069aafdfff50e7f2d0732bf209 On 01/06/2012 07:10 PM, Michael Weber wrote: > On 01/05/2012 03:40 AM, Zac Medico wrote: >> The FHS notion of "root filesystem as a recovery partition" existed long >> before the relatively modern development of things like busybox and >> initramfs made it more practical to use an initramfs as a recovery >> partition. Anyone who wouldn't prefer to use an initramfs for their >> "recover partition" probably just doesn't realize how well suited an >> initramfs is for the job. It's so well suited for the job that it makes >> the old FHS notion of "root filesystem as a recovery partition" seem quaint. > > Please stop hailing to busybox. I think it's a bulk load of faulty, half > implemented code that's not worth the time compiling. > > You can do better w/ the real tools. (Not my crappy little initrd > script, but the well established, fully operational, as used to programms) > > http://xmw.de/dotfiles/scripts/mkinitramfs.sh That seems like an awfully large initramfs to load into memory for every boot, just to have it wiped from memory after switching to the real root. It's fine as long as you're not trying to shave every last microsecond off of your boot time though. An alternative approach to a having a bulky initramfs "recovery partition" like yours would be to put the content of a livecd/usb recovery disk onto a spare partition, and configure your lean busybox initramfs to mount that as the root if something goes wrong with your real root. -- Thanks, Zac