CentOS - Feb 2017 - usb drives & Orico ORICO 9548U3-BK

Everyone,

Is there a way to manually assign usb drives to a specified device
label.  Is there a way to force two usb drives to be labeled as
/dev/sdc and /dev/sdd?


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.

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.

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


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.

The only way I have been able to make this archive server function is
to keep a mouse and keyboard plugged in to the system, and even with
the keyboard and mouse attached I can not do a software reboot, I am
required to turn off the power supply for a couple of seconds and then
turn it back on before I hit the power switch on the computer.  I have
played with the bios setting until my eyes are blurry, but have not
been able to solve the problem.  I am using  a ASUS H110M-E/M.2 LGA
1151 Intel H110 HDMI SATA 6Gb/s USB 3.0 Micro ATX Motherboard.

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

Anyone have any ideas?

Thanks for your responses!!!!

Greg Ennis

> Is there a way to manually assign usb drives to a specified device
> label.  Is there a way to force two usb drives to be labeled as
> /dev/sdc and /dev/sdd?
> UUID=f915a354-28bf-4110-bec9-3767ef1fe52c /boot??? xfs????defaults??0 0
Don't use device names, use UUIDs like the above.

> 
> 
> 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.

> 
> 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.

-----------------------------------------------------------------

Pete,

Thank you for such excellent help; I appreciate your wisdom and
challenges.  The machine I am working on is still at the 'lab' stage so
everything can be changed at this point.  I don't have the benefit of
much 'perceived wisdom' in that most of my knowledge comes from
mistakes I have made or mistakes others on this list have made that Ican learn
from.  So thanks again.

Here are some of my thoughts... right or wrong.

#1. 3.0 USB drives
I originally performed some testing on a small usb passport 3T drive
and was amazed by the response and access times.  I stumbled across the
Orico cabinet during a NewEgg search, and decided to give it a try.  I
was even more impressed with the response and access times.  I decided
to attempt a mdadm raid on the the Orico and everything has worked
better than expected except for the problems I have had with device
assignments.   I did have an electrical failure at my home related to
weather of which the ups powered down after 30 minutes that caused one
of the raid 5T drives to become corrupted.  I reformatted the drive and
rebuilt the raid with mdadm, and everything worked a lot better than I
expected.  I will only be using this system to store *.tar.gz backup
files from other systems.  What should cause me to fear the USB 3.0
connection.

#2. /etc/mdadm.conf
The tutorials I read about how to use mdadm did not include mdadm.conf,
and this was not created when I installed mdadm.  I will take a look at
the man pages.... thank you.

#3.  UUID's
Thanks for the suggestion to use names instead of device addresses and
how to get the names with lsblk --fs /dev/sda.   Using this should fix
my problem of reassignment device names at boot time. Thanks much!!!

#4.  Partitionless disks
I orginally installed Centos 7.3 on an SSD, and then installed the hard
drives subsequently.  I noticed that I gained quite a bit of disc space
 by not using a partition.  Since the files I will be storing on these
discs are large and will only be accessed for archive purposes I wanted
to use as much of the disk as possible.   The original google searches
I made related to using a partitionless disk did not give me compelling
rational to use a partition, however I would surely like to hear from 
you and others about this.


Thanks again for your help, and instruction!!!!!

Greg