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 D06B41381F3 for ; Tue, 20 Aug 2013 14:31:18 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 732BDE0D0C; Tue, 20 Aug 2013 14:31:11 +0000 (UTC) Received: from mail-ea0-f170.google.com (mail-ea0-f170.google.com [209.85.215.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 39268E0CC1 for ; Tue, 20 Aug 2013 14:31:09 +0000 (UTC) Received: by mail-ea0-f170.google.com with SMTP id h14so260101eak.29 for ; Tue, 20 Aug 2013 07:31:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=9doRW4M9tJVjEQymcsk1VofrAa8oCYUd3fFeM4qMZng=; b=a6i7SJCxvJ4WesodZCscsQKWAMsRPsX4zsqUiLXLZyCsaw2rSSV1uHcetW/S40ZmZ/ +9H27gr0pbuqgE5I8C/3kNQBbwHQchArPhmMfxV6k3R28ThLhoMovx2D99LNxBFkFJDy CXxWolSj/WW5n1EvhmmOWevfJDnFHc/EOvivofFKVnEc8p63n+J82fwbfQGMTfrcdELa SHXJDU4RRpKKuVBjSMdzSP0h+FlZfTwP5hd+LWkdfTdfCtoDcJCqaa3dm0VN8iSpknwV oCUqD+D+7wqJY2BZniCKDNx8SYBW5qJUIxVodGNMZI7Boc5Y9Tm61xTxFau1oRFwgcTZ /L6w== X-Received: by 10.15.52.2 with SMTP id o2mr634081eew.83.1377009068759; Tue, 20 Aug 2013 07:31:08 -0700 (PDT) Received: from [172.20.0.40] (196-210-127-211.dynamic.isadsl.co.za. [196.210.127.211]) by mx.google.com with ESMTPSA id f49sm2803430eec.7.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 20 Aug 2013 07:31:08 -0700 (PDT) Message-ID: <52137CE3.6060708@gmail.com> Date: Tue, 20 Aug 2013 16:27:47 +0200 From: Alan McKinnon User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130809 Thunderbird/17.0.8 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Re: Optional /usr merge in Gentoo References: <5211226F.2000000@libertytrek.org> <201308182208.43780.michaelkintzios@gmail.com> <521142A7.1020702@coolmail.se> <52121D0F.5030004@libertytrek.org> <521243C2.404@thegeezer.net> <20130819232019.149767a4@hactar.digimed.co.uk> <20130820110320.6b328728@hactar.digimed.co.uk> <3b25885ef537f466ddee4beafbec6879.squirrel@www.antarean.org> <20130820132207.30d0ea8b@digimed.co.uk> <52137842.6000408@libertytrek.org> In-Reply-To: <52137842.6000408@libertytrek.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Archives-Salt: db539ab6-5cbb-4c03-8600-1d6b22880e5f X-Archives-Hash: e36dc035935e92f7efebfaca4dbdfc92 On 20/08/2013 16:08, Tanstaafl wrote: > On 2013-08-20 8:22 AM, Neil Bothwick wrote: >> On Tue, 20 Aug 2013 14:10:21 +0200, J. Roeleveld wrote: >> >>>> Not really, because make is intelligent enough to no bother >>>> recompiling anything for which the source has not changed. >>> >>> True, but why recompile the kernel just to redo the initramfs? >>> As mentioned, I don't update/recompile the kernel as often. >>> "genkernel" puts the initramfs where it needs to be, kernel-make >>> doesn't. >> >> That depends on your needs. The reason I do it this way is so that the >> initramfs is locked to the kernel. Once that kernel boots, it will always >> boot because the initramfs cannot be changed. If I make a change to the >> initramfs, that's a new kernel and however broken it may be, the old one >> will still work. > > So, you're saying that whoever it was that said that some userland files > (that the initramfs 'refers to') could get updated, causing it to get > out of sync - and presumably causing it to fail to boot if/when you > rebooted - was wrong? > > The main thing about this whole initramfs thing is, like Dale, I just > don't understand it. I understand grub and grub.conf. I understand > enough about compiling a kernel to be able to get it done and be > reasonably sure it is done right. What part don't you understand? How to use it, how it works, how to build it? The full correct way to test such a thing is to configure and build the new kernel, build the initramfs, install the whole lot, add new stanza to grub.conf and reboot. If it fails, reboot with the old kernel, then investigate. You have servers and the only time you would really be building a new kernel is to do an update you plan to use, correct? Presumably you have a defined maintenance window for that, so make full use of the time. You can copy debian's scheme in grub.conf to configure a known good fallback that will be used if the boot fails. > > But if my system ever failed to boot because of a problem with the > initramfs, I basically would be hosed. You can't fix them (well, not easily), you just rebuild them. If it helps, think of an initramfs as a minimal system image that is compressed and stored in a file. The kernels mounts it at /, uses it briefly to looad some drivers and do kernel-space setups then invokes some internal magic to toss it and mount the real (and now accessible) / correctly. It's magic because you cannot do this anymore once init has started > >> The kernel and initramfs are so closely coupled, it just seems sensible >> to keep them in the same file, since neitherof them is any use without >> the other. > > See above... > -- Alan McKinnon alan.mckinnon@gmail.com