The mdadm race problem has bitten me several times. Sometimes putting timing waits helps. Sometimes referring to the filesystem differently in the fstab helps. (/dev/sdc vs UUID=) Sometimes adding a bootwait option helps. Search for mdadm and race. On Thu, 21 Mar 2013, Yaron wrote: > They get MOUNTED after the OS boots. I think mdadm tries to start the array > up well before that, for some reason it fails and dumps me into busybox. I'm > not entirely sure what exactly is going on, really, RAID's never been my > thing. > > On Thu, 21 Mar 2013, Mike Miller wrote: > >> But if it fails after the OS is done booting, why does it dump you into >> busybox? I think that happened to me only when my updated kernel was not >> being found because it had been written to the wrong partition. That >> shouldn't happen in a brand-new setup, though. Under what conditions does >> busybox make an appearance? >> >> Mike >> >> >> On Thu, 21 Mar 2013, Yaron wrote: >> >>> I'm not using a partition table on the RAID device at all, but that's moot >>> since I'm not booting off it. It gets mounted well after the OS is done >>> booting... but it makes the boot process hang for random reasons. >>> >>> On Thu, 21 Mar 2013, Mike Miller wrote: >>> >>>> On Wed, 20 Mar 2013, Yaron wrote: >>>> >>>>> Ok, I've been running a software RAID5 on one of my older systems for a >>>>> while. Almost every time I reboot, it claims the RAID is degraded and >>>>> dumps me into busybox, where all I can really do is exit and HOME it'll >>>>> see the drives next time I reboot. This is solved by rebooting anywhere >>>>> from 2 to 20 times. >>>>> >>>>> I figured it was this system or these harddrives or this SATA controller >>>>> or... whatever. But I just set up a brand new RAID array on a brand new >>>>> machine using brand-new drives and a brand-new array, etc, etc. Same >>>>> exact issue. >>>>> >>>>> Anyone have ANY idea if this is ME doing something wrong, or what? >>>> >>>> >>>> I don't really know anything except that the tricky part of making my >>>> RAID 1 work was figuring out how the boot partition is supposed to be set >>>> up. I didn't get that right and then after a kernel update it wouldn't >>>> reboot unless I went back to the earlier kernel. That might be >>>> irrelevant, but judging from things I was reading on web forums and >>>> advice I was getting, this is a tricky issue. With larger drives (more >>>> than 2.2 TB) we have to use GPT instead of MBR and then all kinds of >>>> little annoyances come along. Are you using GPT? >>>> >>>> Mike >>>> _______________________________________________ >>>> TCLUG Mailing List - Minneapolis/St. Paul, Minnesota >>>> tclug-list at mn-linux.org >>>> http://mailman.mn-linux.org/mailman/listinfo/tclug-list >>>> >>> >>> >>> >>> -- >>> _______________________________________________ >>> TCLUG Mailing List - Minneapolis/St. Paul, Minnesota >>> tclug-list at mn-linux.org >>> http://mailman.mn-linux.org/mailman/listinfo/tclug-list >>> >> _______________________________________________ >> TCLUG Mailing List - Minneapolis/St. Paul, Minnesota >> tclug-list at mn-linux.org >> http://mailman.mn-linux.org/mailman/listinfo/tclug-list >> > > > > -- > _______________________________________________ > TCLUG Mailing List - Minneapolis/St. Paul, Minnesota > tclug-list at mn-linux.org > http://mailman.mn-linux.org/mailman/listinfo/tclug-list > -- Gerry Skerbitz gsker at skerbitz.org