From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([69.77.167.62] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1LDtdq-0004Eo-F7 for garchives@archives.gentoo.org; Sat, 20 Dec 2008 04:40:42 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 3864CE04D8; Sat, 20 Dec 2008 04:40:41 +0000 (UTC) Received: from rv-out-0708.google.com (rv-out-0708.google.com [209.85.198.251]) by pigeon.gentoo.org (Postfix) with ESMTP id E5573E04D8 for ; Sat, 20 Dec 2008 04:40:40 +0000 (UTC) Received: by rv-out-0708.google.com with SMTP id b17so1353283rvf.46 for ; Fri, 19 Dec 2008 20:40:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=up9/LLuKGxB9gb96RcRh6C8u6Qhd4darXk7qmzsxsQw=; b=MIa66pEl+EQDICQzc0uZucIoX6xsvbXP3OYk/anut9KZ7aRwpvLFMgKtIKs4w8ywx4 syF4bMfSJ6hnT3St+mfGhMG7K4fnqlCEYlU7KUky0if37PJwfvgb0XEDFjiiZ6HOoBQm QRGEywwi6UjzLgoRvO6NOTzMD6q0xcmyuAeoY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=baWNCmxQDbGpzeH+uD4IUvwRT2EDmx82UgxGIYGkiHlF5YfkJtNoObl6lmDAIluEoI w5fv/SG680o/BmutBOryRHuUXECr1b5tA8n29NQjDN/lDpW8ydYXvqWUyknWduW6jGL6 K4ye83H6RB+54dC6SlHek5wg5nTvBgSZgKFxk= Received: by 10.141.29.16 with SMTP id g16mr1912064rvj.287.1229748040502; Fri, 19 Dec 2008 20:40:40 -0800 (PST) Received: by 10.141.18.21 with HTTP; Fri, 19 Dec 2008 20:40:40 -0800 (PST) Message-ID: <7a329d910812192040na259a95v5223ced5977a5823@mail.gmail.com> Date: Fri, 19 Dec 2008 20:40:40 -0800 From: "Wil Reichert" To: gentoo-amd64@lists.gentoo.org Subject: Re: [gentoo-amd64] Re: genkernel changes In-Reply-To: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-amd64@lists.gentoo.org Reply-to: gentoo-amd64@lists.gentoo.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <7a329d910812190750n606b52efl5c3a8cb3cb0560ad@mail.gmail.com> X-Archives-Salt: 7966a5b4-cc73-4463-991c-e7cc4b502dbf X-Archives-Hash: d1bcc8fe56f47557018be77b55e3f5e5 On Fri, Dec 19, 2008 at 4:05 PM, Duncan <1i5t5.duncan@cox.net> wrote: > "Wil Reichert" posted > 7a329d910812190750n606b52efl5c3a8cb3cb0560ad@mail.gmail.com, excerpted > below, on Fri, 19 Dec 2008 07:50:34 -0800: > >> I build my own kernels but since my / partition is lvm I use genkernel >> to create an initrd. Previously 'genkernel --lvm initrd' did what I >> wanted but it seems that the since genkernel-3.4.10.902 thats no longer >> the case. Reading the man page it seems that the initrd parameter has >> been replaced by initramfs. However, when I attempt to run it with that >> I get >> >> matter boot # genkernel --lvm initramfs Error: Unknown option >> 'initramfs'! >> >> I can easily roll back to a previous version of genkernel, I'm just >> wondering if genkernel is broken or I'm just doing something wrong? > > I do /not/ use either genkernel or an initramfs/initrd, so this is from > various reading I've done and I have no idea how accurate it might or > might not be. Never-the-less, it's likely the case based on what I've > come across on the subject. > > Formerly, the kernel used a separate "init-ram-disk" aka initrd (init-r- > d). Now, the kernel uses (if enabled) an "init-file-system", directly > appended to the kernel itself, not a separate file. > > Therefore, what I'd guess is happening is that there's no separate > command to make it in the new genkernel, since it's not a separate file. > Rather, it probably reads the associated kernel option as to whether to > create it or not, and then does so before generating the final kernel, > finally appending the compressed initramfs to the already created kernel. > > Far be it from me to tell you how to arrange your system, and it sounds > like it's a bit late for you anyway, but this is something to keep in > mind for those just setting up. While I'm running both LVM2 and kernel/ > md RAID (0,1 and 6, 0 for speed on stuff like ccache and the gentoo tree > where redundancy isn't needed, 1 for /boot since that's all grub > understands, and 6 for the main system), the fact that LVM2 requires > userspace help and therefore an initrd if the / filesystem is to be > placed on it, while with RAID the necessary info can be auto-detected or > passed on the command line, was the reason I chose to go with partitioned > RAID for / (and a backup I call rootbak) instead of putting it on LVM2. > /home and my media and mail and news partitions, etc, with their backups, > are all on LVM2, but / and rootbak are directly on partitioned RAID-6. > > Also, / (and rootbak) include /usr and /var as well (except for > /usr/local and /var/log, with /var/tmp being a symlink to /tmp, which is > tmpfs), so the full installed system along with the portage data in > /var/db and /var/lib/portage, are all on the same volume and managed > together, thus kept in sync. This is because I had some major headaches > in a disaster recovery scenario where the /, /var, and /usr partitions > weren't in sync with each other, so I didn't know /what/ package versions > I actually had on disk. Keep it all on the same volume and it stays in > sync, if I go to rootbak, tho it may be dated, it too is in sync. > > Thus I can pass the necessary parameters to assemble the partitioned- > RAID-6 upon which the / filesystem is located directly to the kernel, and > don't need an initrd/initramfs. Later, as the system boots normally, it > loads the raid and lvm services (baselayout-2 with openrc treats them as > full services, not the "addons" baselayout-1 used, and loads them as > such), bringing up the rest of the RAID devices, and then LVM on top of > the RAID-6 (the RAID-0,1 only have a single partition/volume each anyway, > so no need for LVM there). I thus entirely avoid the complexity of an > initramfs/initrd. > > As I said, whether something like this may or may not have been better > for you, it's kind of late now that you're / is on LVM, but it's > something others just setting up should at least evaluate as an option, > as they plan out their system. > > One other comment for those considering this. I only created my main / > and a single rootbak backup for it. If I had it to do over, I'd create > two backup / images, thus handling the case of tragedy striking just as I > was updating the first backup and the resultant loss of both it and the > working /. That should be a rather rare event, but were I prepared for > it I'd certainly have rather better peace of mind now. Yep, I understood the limitations when I configured it like this. Used to keep around a 'real' partition for / & had everything else lvm'd but it eventually just seemed unnecessary. Move to all lvm a couple years back & its hardly even been an issue. I like the ease in which you can do snapshots & move lv's around to various drives. BTW, I figured out the answer to my problem. The man page for genkernel used to have an action called 'initrd'. In 3.4.10.902 the man page changes that to 'initramfs', but it should be 'ramdisk'. Just submitted bug 251702. Wil