Re: [gentoo-amd64] Can initrd and/or RAID be disabled at boot?

[Mark Knecht]

On Mon, Jul 1, 2013 at 2:10 PM, Paul Hartman
<paul.hartman+gentoo@×××××.com> wrote:
> On Tue, Jun 25, 2013 at 5:51 PM, Mark Knecht <markknecht@×××××.com> 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