Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Mirror raid often is not available #63
My Mirror raid often is not available and to correct it I need to run this command on an ssh command line
My Raid volume is than back online but this should not be the normal behaviour.
I had this problem on my Raspberry Pi 2 running Raspbian GNU/Linux 8 (jessie). I had a RAID array on /dev/sda1 and /dev/sdb1 which failed to assemble at boot. I had in my /etc/mdadm/mdadm.conf file the entry
ARRAY /dev/md/0 metadata=1.2 UUID=53454954:4044eb66:9169d1ed:40905643 name=raspberrypi:0
(your numbers will be different; see other answers on how to get this.)
I had in my /etc/fstab file the entry
/dev/md0 /data ext4 defaults 0 0
(and of course /data indeed existed)
Like the OP, I could assemble and mount the RAID array by hand after boot, but I could not get it to happen automatically during boot despite apparently correctly setting it up.
I was able to solve the problem as follows. I investigated the script at /etc/init.d/mdadm-raid and inserted a line of debug code
ls /dev > /home/pi/devices.txt
Rebooting and checking this file I learned that devices /dev/sda and /dev/sdb existed at the time the mdadm-raid initialization happened, but the partitions /dev/sda1 and /dev/sdb1 were missing. I edited the /etc/init.d/mdadm-raid file and inserted the line
after the header (i.e. after the ### END INIT INFO but before the script begins). This caused the partitions to be detected and so the mdadm-raid script was able to assemble the RAID array, resolving the problem. Hope this helps someone!
It supports raid because omv package is architecture agnostic. It doesn't remove UI elements based on the platform.
You should consider using raid in a rpi only as a proof of concept or playing around. The most common reality is what you describe in your issue, reboot and raid is gone.
You can read all over the forum people with problems using RPI. Yes, there are images for the platform just because users demand it and are there, but if it where for me i would remove them.
ATM there is around 4-5 different affordable ARM boards that beat by 10x times what the rpi can do as a NAS server, some of them even have SATA ports now. I personally own a rock64 board, performs very well but i would never consider to run a RAID there.
Is good media player (i give you that at least for x264 media), just a terrible choice for what you really want.
Not much we can do for here. OMV provides a panel for creating MD raids, removing disks from there etc. It also configures /etc/mdadm/mdadm.conf, notifications, and does not go beyond that, is expected to just boot the raid assembled and ready to be mounted by fstab. There is no magic here.
Could be the drives are not ready (due to slow usb bridge) when mdadm is scanning or the fact you created the raid using partitions.
The 2 reasons to to have raid are: availability and performance, you clearly don't have availability (as you mention it rarely works on reboot) and we should not discuss about performance in this case. Also a reminder this RAID is not your backup.
You might want to think your setup maybe consider using as two separate disks (filesystems) an mirror them using a daily rsync job
As an aside, I agree with the other guys that usb is not a great performance interface to run mdadm over however I'm not sure I'd agree that usb is not fit for purpose within a raid environment. Usb adds an additional level of complexity as there is the usb to data interface on both sides of the link. So the throughput will be slower, the links will take longer to raise and lower and the latency will be higher. This in conjunction with the lower processing power of the pi would make it a poor usage scenario, however it should work albeit with everything working a LOT slower, including the initial initialisation and detection of the drives.
Debian/OMV already tries to assemble mdadm raid arrays at boot. Waiting for USB devices is the job of the bios or something else. rc and cron is the wrong idea since services depend on storage which would not be ready.
After all the bad results I have seen with raid and usb and the RPi, I would never go down that road. If you really want to use and rpi and want redundancy, connecting raid to the RPi the wrong way to go in my opinion. You should have multiple RPis with one drive attached to each. Then rsync between them. This is the only way you will ever get halfway reliable redundancy from RPis (and still not very good).
"Having the Raspberry Pi 3, adding the rootdelay=5 to the /boot/cmdline.txt solved this problem”
The credit goes here.