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 1SHnGz-0007Rk-Of for garchives@archives.gentoo.org; Wed, 11 Apr 2012 02:27:05 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id E7638E0CFB; Wed, 11 Apr 2012 02:26:42 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 28903E0C84 for ; Wed, 11 Apr 2012 02:25:55 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id B2BF71B4006 for ; Wed, 11 Apr 2012 02:25:49 +0000 (UTC) X-Virus-Scanned: by amavisd-new using ClamAV at gentoo.org X-Spam-Flag: NO X-Spam-Score: -1.939 X-Spam-Level: X-Spam-Status: No, score=-1.939 tagged_above=-999 required=5.5 tests=[AWL=-1.191, BAYES_00=-1.9, RCVD_NUMERIC_HELO=1.164, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from smtp.gentoo.org ([127.0.0.1]) by localhost (smtp.gentoo.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TKpy7yjyd4yk for ; Wed, 11 Apr 2012 02:25:43 +0000 (UTC) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTPS id D40501B4002 for ; Wed, 11 Apr 2012 02:25:42 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1SHnFZ-0006wv-2u for gentoo-dev@gentoo.org; Wed, 11 Apr 2012 04:25:37 +0200 Received: from 109.176.235.157 ([109.176.235.157]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 11 Apr 2012 04:25:37 +0200 Received: from slong by 109.176.235.157 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 11 Apr 2012 04:25:37 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Steven J Long Subject: [gentoo-dev] Re: Re: Re: [gentoo-dev-announce] Council meeting summary for 3 April 2012 Date: Wed, 11 Apr 2012 03:28:45 +0100 Organization: Friendly-Coders Message-ID: References: <20353.41193.129711.306663@a1i15.kph.uni-mainz.de> <20120408220422.GA26440@kroah.com> <4F833687.4040004@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="ISO-8859-1" Content-Transfer-Encoding: 7Bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 109.176.235.157 X-Archives-Salt: df91fd36-68ba-4c12-965d-c87ac28e8432 X-Archives-Hash: 6c4ce9a43e5d81abc579edf9d5d29fa5 Zac Medico wrote: > On 04/09/2012 11:09 AM, Steven J Long wrote: >> One thing that has bothered me with the mooting of an initramfs as the >> new rescue system that rootfs has traditionally been, is at the we are >> told at the same time that the initramfs can be very minimal. If so, how >> does it provide the same capabilities as rootfs (for those of us who can >> localmount without udev-configured devices)? > > We've had some discussion on this before [1], and I've suggested to copy > the content of livecd/usb recovery disk onto a spare partition so that > you can boot into that if necessary. The advantage of using this > approach is that it eliminates the burden of maintaining the "/ is a > self-contained boot disk that's independent of /usr" use case. > It's a nice idea, and could also be done without an initramfs, ofc. You mention configuring "initramfs to mount that as the root if something goes wrong with your real root." Thing is, for most desktop/laptop installs, if something goes wrong mounting root from hard-disk, it's likely that booting into another partition will go wrong too. It's pretty rare to get errors just on rootfs, that aren't to do with the whole drive, and aren't fixed by fsck on a stable fs like ext3. (If you do, you have to go to backups ofc, and would be wise to suspect the whole drive.) At least, that's been my experience using separate partitions for everything. In that circumstance, if a rescue shell weren't available, (you're able to boot the kernel or the the spare partition can't be booted to) I would just boot the latest sysresccd that was around, if not able to download from another box. If it were really that bad, I'd likely want to reinitialise any failing partition, and would probably want a recent minimal install disk. Boot up problems which need admin-work on Gentoo, ime, tend to be about system upgrades not playing nicely, rather than the kernel unable to boot at all (once you know which drivers you need for eg PCI/SATA drives built-in, you usually are able to get at least root consistently, on an older kernel if you're upgrading.) Again, being able to boot into the machine, and have the rootfs at hand for say dispatch-conf and rc-update, works nicely. A rescue partition would effectively work the same as a live-disk, in that you'd need to do all the chrooting etc afaics, and would need to be maintained to stay current. I suppose you could script that, but again, it just seems like a lot of bother to implement an "alternative" that doesn't actually gain anything over the traditional setup (plus making sure that partitions are mounted before udev starts.) As for the burden of ensuring that binaries installed to /{s,}bin don't link to libs in /usr, why not just automate a QA check for that, and let developers decide whether a fix is necessary? After all, core packages that do that even when configured with prefix and execprefix = /, aren't so portable, and Gentoo has always championed "doing the right thing" wrt helping upstream fix portability issues. I realise "core" is subjective, but it amounts to "what our lovely devs decide on for us" which is part of the reason you choose a distro, and the trust you place in its developers. -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)