I decided to build an archive server for the purpose of backing up other fedora/centos desktops at the office. I built a machine and have installed Centos 7.3 on it with all updates current. I also purchased a 3.0 usb sata drive cabinet (Orico ORICO 9548U3-BK) and installed two 5T black WD drives. There was no problem installing the usb cabinet or the drives. I formatted each drive with xfs as /dev/sdc and /dev/sdd, and then combined them into a software mirrored raid with mdadm as /dev/md0.
I've always thought that the perceived wisdom is to not try and do software raid across USB - especially when both drives are at the other end of the same USB cable. Sure USB 3 is faster and there's a better chance it will appear to work at a reasonable speed, but it's not something I would contemplate.
Everything was working perfectly until I removed the terminal, keyboard and mouse and tried to reboot the machine. It took a while to figure out, but when the mouse and keyboard were removed the boot process assigns the usb drives differently which makes /dev/md0 created by mdadm fail.
Which means that the drive letters are explicitly mentioned in /etc/mdadm.conf - you can change it to be wildcarded or leave mdadm to figure it all out itself. See 'man mdadm.conf'.
My fstab file looks like :
/dev/mapper/centos_poar-root / xfs defaults 0 0 UUID=f915a354-28bf-4110-bec9-3767ef1fe52c /boot xfs defaults 0 0 /dev/mapper/centos_poar-home /home xfs defaults 0 0 /dev/mapper/centos_poar-u /u xfs defaults 0 0 /dev/mapper/centos_poar-swap swap swap defaults 0 0 /dev/sda /u0 btrfs defaults 0 0 # entries below were combined into one mirrored raid system #/dev/sdc /u1 xfs defaults 0 0 #/dev/sdd /u2 xfs defaults 0 0 /dev/md0 /u1 xfs defaults 0 0
Another likely issue is that you explicitly mention /dev/sda in the fstab - if the drives are re-ordered, then /dev/sda will not be what you think it is. It's a much better idea to use UUIDs when mounting drives. You can find the UUID with
lsblk --fs /dev/sda
BTW, are you really using partitionless disks - is it really /dev/sda and not /dev/sda1 ?
This works perfectly when a usb mouse and a usb keyboard are attached, but when I remove the mouse and keyboard the system will not boot because the usb drives are relabeled as /dev/sda and /dev/sdb.
I would have thought that any SATA drives would have been processed before the USB drives - certainly it looks that way on my system. Try going through the output of dmesg to see if you can see what is really happening when in the boot sequence.
My thought is that if I could force the usb drives to be labeled as /dev/sdc and /dev/sdd whether the mouse and keyboard are attached or not, I might be able to fix the problem
It's much easier to make sure you don't explicitly use drive letters - because, as you've found out, they can change. Use filesystem labels or UUIDs or disk IDs. The disk IDs can be found in /dev/disk/by-id and they should remain the same.
P.