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 05D7A1381F3 for ; Tue, 2 Jul 2013 17:06:35 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 6D26BE0AAD; Tue, 2 Jul 2013 17:06:33 +0000 (UTC) Received: from mail-pb0-f50.google.com (mail-pb0-f50.google.com [209.85.160.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 92D70E0A82 for ; Tue, 2 Jul 2013 17:06:32 +0000 (UTC) Received: by mail-pb0-f50.google.com with SMTP id wz7so6301426pbc.23 for ; Tue, 02 Jul 2013 10:06:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=ti8wT3ErvYPBp3sx3bZjto7nSCvpGVzQLi84ZKsHdh8=; b=KkuekDX4AzNNMkJ9hXmDLSu7LR7INj1p1ZuuWZwa5EBK66ANxMSbvH8CC9fvs2tEDO pNKKBz7poR5v03xgTomDXE/WAo2+3r9Y0TcpnhKrd48TNp590ctGbwb17U015l43AJHx buhfwmNtMF/Ea2+uh1hHFBj/p+qjS7n/hZXt9m8y/kp4O++LE00b3FAmy2Y8pFU/sk1s y7LXhxvpIfWfS81MOdLvGgF7zksPSrqTB+AQSXT7HsAEisJIRnLQZ1sNajNpdxyDKcBs OEc654kMYdhTZCFgsmlYlT6qrK0ErTF49wmposhAzzCqUgePgWsRX2E4rb11RQkEoiqN MsQg== 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 X-Received: by 10.68.241.135 with SMTP id wi7mr30300796pbc.88.1372784791498; Tue, 02 Jul 2013 10:06:31 -0700 (PDT) Received: by 10.70.126.130 with HTTP; Tue, 2 Jul 2013 10:06:31 -0700 (PDT) In-Reply-To: References: Date: Tue, 2 Jul 2013 10:06:31 -0700 Message-ID: Subject: Re: [gentoo-amd64] Can initrd and/or RAID be disabled at boot? From: Mark Knecht To: Gentoo AMD64 Content-Type: text/plain; charset=UTF-8 X-Archives-Salt: d29dfbf7-0c21-43cf-b344-3b8b15fe594c X-Archives-Hash: 36c9b17c7a1ec3edc471b5644a1b87a5 On Mon, Jul 1, 2013 at 2:10 PM, Paul Hartman wrote: > On Tue, Jun 25, 2013 at 5:51 PM, Mark Knecht wrote: >> This is related to my thread from a few days ago about the >> disappointing speed of my RAID6 root partition. The goal here is to >> get the machine booting from an SSD so that I can free up my five hard >> drives to play with. >> >> SHORT SUMMATION: I've tried noninitrd and noraid in the kernel line of >> grub.conf but I keep booting from old RAID instead of the new SSD. >> What am I doing wrong? > > Here are some things I would try to narrow it down: > > Put raid=noautodetect on your kernel commandline to prevent the kernel > from auto-assembling the array > > It sounds like you are pretty sure it is at least using the boot > sector of the new drive, so I am thinking it is possible there is some > weird combination of using a boot sector from one drive to get you > into the boot partition of another drive. If the old boot drive is > still attached, you could try moving/renaming the grub config or whole > grub folder on the old boot drive to make sure it's not getting used. > > If that doesn't give any clues, I would physically unplug the cable of > every drive other than the SSD (if that is realistic based on your > filesystem layout) and see how far it gets. Maybe if it fails you can > figure out what it's trying to access on the other disks. > > As far as the RAID I think there are at least a few different ways an > mdraid array comes to be assembled: > - your initramfs does it > - your kernel does it (only for a RAID with v0.90 superblock) > - init script does it (/etc/init.d/mdraid) > - udev does it (/lib64/udev/rules.d/64-md-raid.rules) > - you manually do it later on using mdadm > > Viewing dmesg output from around the point where boot begins and the > RAID is assembled might give you some clues about who's doing what. > > I recently upgraded my machine and disks and am using UUID and labels > for everything, I can literally boot from either the old HDD or new > HDD from my BIOS boot menu, plugging them into the motherboard in any > order, and either one will work properly, even though the /dev/sdX > assignments might change from boot to boot. You can use the blkid > command (as root) to see the labels and UUIDs for all of your drives > and partitions. > > Good luck, > Paul > Hi Paul, Thanks for the interest and sorry for the delay in my response. I've ended up going in a slightly different direction in the process which as of yet hasn't yielded much except more work for me. No response is necessary to this post, although I'm always interested in what folks are doing and thinking. This post is nothing more than a status report. First, the purpose of this work: my existing machine has 5 HDDs hooked to the internal SATA controller, an unused SDD and a number of external USB drives holding video & Windows VMs. The RAID6 is slow (my opinion) and I want to investigate other RAID architectures in the machine with the goal of eventually using one (RAID1, RAID5, RAID6, RAID10) in a better optimized and tested setup. The first path I went down was to rsync the exiting Gentoo / to the SDD. For whatever reason that never booted correctly. To get past the issue above I just created a new Gentoo install on the SDD from scratch. This was easy to do in a chroot while I do my trading work throughout the day. As per other posts I decided to create a new boot partition on the SDD with an eye toward possibly using grub2 later. (The SDD is sda, at least in the RAID6 environment. /dev/sda1 is the new boot, /dev/sda2 is the new SDD root) However in the beginning my intention was only to place the SDD kernel on the new boot partition. The HDD RAID6 kernel remains on the HDD boot partition and I continue to use grub on that boot partition to get the machine going. For the SDD boot I just point the root & kernel commands to the first partition on the SDD. This has worked and the SDD boots reasonably well, but it is fragile. It appears that drive ordering changes from boot to boot depending on which USB drives are attached so I probably need to move to something more like your UUID methods. Lastly, because I am still running on the original RAID6 setup I do not want to touch the internal SATA cabling at all. It's important to me that the currently working setup continue to work. I'll just have to struggle along with making the setup more reliable using both the HDD & SDD setups. Due to everything above I've not yet done anything with testing of new RAIDs. Maybe later this week. Who knows? Cheers, Mark