Lost RAID1 after reboot

    • OMV 2.x
    • Lost RAID1 after reboot

      Hello,

      I tried to set up an NAS with an RAID 1 (Mirror) array on a Raspberry Pi 3. At the Moment I use 2x Western Digital Elements 25A2 USB 3.0 1 TB Harddrives. The Image from the Download Server was written to the SD Card. I've made all Updates & Upgrades incl. the Topic with the PUBLIC_KEY.

      It took around 30 Minutes until the RAID Array was complete. Afterwards I made a User, a Share and configured SMB/CIFS. The NAS was quickly found by my Mac and also from my Windows 10 PC. I've copied some Files on the NAS, what worked perfect. As a further Test I've done a reboot. And now the NAS Share is not found anymore. The HDDs should be EXT4.

      Now to the Facts:
      Version: 2.2.7 (Stone Burner)
      Processor: ARMv 7 Processor rev 4(v7l)
      Kernel: Linux 4.4.13-v7+


      Details Storage - Physical Disks (See Screenshot)
      Device Model Serialnumer Vendor Capacity
      /dev/mmcblk0 n/a n/a n/a 14,84 GiB
      /dev/sda Elements 25A2 Serialnumber Western Digital 931,48 GiB
      /dev/sdb Elements 25A2 Serialnumber Western Digital 931,48 GiB

      Details Storage - RAID Management: (See Screenshot)
      Empty, no Data

      Details Storage - File System (See Screenshot)


      Further Informations:

      cat /proc/mdstat
      Personalities :
      unused devies: none



      blkid
      /dev/mmcblk0p1: SEC_TYPE="msdos" LABEL="boot" UUID="7D5C-A285" TYPE="vfat"
      /dev/mmcblk0p2: UUID="5d18be51-3217-4679-9c72-a54e0fc53d6b" TYPE="ext4" LABEL="omv"
      /dev/mmcblk0p3: LABEL="data" UUID="fa36508a-b3c4-4499-b30a-711dd5994225" TYPE="ext4"
      /dev/sdb: UUID="2df86e3b-ce69-3f15-cab5-71cd1c411e56" UUID_SUB="9fd4398b-3ea3-d849-e1e6-add66ae0b18c" LABEL="RasPi3NAS:OMVNAS" TYPE="linux_raid_member"
      /dev/sda: UUID="2df86e3b-ce69-3f15-cab5-71cd1c411e56" UUID_SUB="fefbed98-7ec4-db1f-3428-7b788e91c792" LABEL="RasPi3NAS:OMVNAS" TYPE="linux_raid_member"



      fdisk -l
      Disk /dev/mmcblk0: 15.9 GB, 15931539456 bytes
      4 heads, 16 sectors/track, 486192 cylinders, total 31116288 sectors
      Units = sectors of 1 * 512 = 512 bytes
      Sector size (logical/physical): 512 bytes / 512 bytes
      I/O size (minimum/optimal): 512 bytes / 512 bytes
      Disk identifier: 0x000b5098


      Device Boot Start End Blocks Id System
      /dev/mmcblk0p1 8192 122879 57344 c W95 FAT32 (LBA)
      /dev/mmcblk0p2 122880 7028735 3452928 83 Linux
      /dev/mmcblk0p3 7028736 31116287 12043776 83 Linux


      Disk /dev/sdb: 1000.2 GB, 1000170586112 bytes
      255 heads, 63 sectors/track, 121597 cylinders, total 1953458176 sectors
      Units = sectors of 1 * 512 = 512 bytes
      Sector size (logical/physical): 512 bytes / 512 bytes
      I/O size (minimum/optimal): 512 bytes / 512 bytes
      Disk identifier: 0x00000000


      Disk /dev/sdb doesn't contain a valid partition table


      Disk /dev/sda: 1000.2 GB, 1000170586112 bytes
      255 heads, 63 sectors/track, 121597 cylinders, total 1953458176 sectors
      Units = sectors of 1 * 512 = 512 bytes
      Sector size (logical/physical): 512 bytes / 512 bytes
      I/O size (minimum/optimal): 512 bytes / 512 bytes
      Disk identifier: 0x00000000

      Disk /dev/sda doesn't contain a valid partition table



      cat /etc/mdadm/mdadm.conf
      root@RasPi3NAS:~# cat /etc/mdadm/mdadm.conf
      # mdadm.conf
      #
      # Please refer to mdadm.conf(5) for information about this file.
      #


      # by default, scan all partitions (/proc/partitions) for MD superblocks.
      # alternatively, specify devices to scan, using wildcards if desired.
      # Note, if no DEVICE line is present, then "DEVICE partitions" is assumed.
      # To avoid the auto-assembly of RAID devices a pattern that CAN'T match is
      # used if no RAID devices are configured.
      DEVICE partitions


      # auto-create devices with Debian standard permissions
      CREATE owner=root group=disk mode=0660 auto=yes


      # automatically tag new arrays as belonging to the local system
      HOMEHOST <system>


      # definitions of existing MD arrays
      ARRAY /dev/md0 metadata=1.2 name=RasPi3NAS:OMVNAS UUID=2df86e3b:ce693f15:cab571cd:1c411e56


      # instruct the monitoring daemon where to send mail alerts
      MAILADDR ...@gmx.at
      MAILFROM root



      mdadm --detail -- scan --verbose
      no Output


      Thanks in advance for your help!

      Greetings from Austria
      Images
      • Storage - File Systems Kopie.jpg

        147.83 kB, 1,280×774, viewed 639 times
      • Storage - Physical Disks Kopie.jpg

        128.98 kB, 1,280×774, viewed 469 times
      • Storage - Raid Kopie.jpg

        122.16 kB, 1,280×774, viewed 437 times
    • Hi,

      I got the very same problem!
      Same configuration - RPi3 with StoneBurner!
      cat /proc/mdstat is empty as well!
      Really weird. It means either something is wrong during our install or there is an inherent instability in stoneburner on RPI3???
      It was so hard to get OMV working to have a just a RAID 1 working....
      Frustrating...

      Well anybody has an idea on how we get back the Raid partition up?

      and / or what I (or we?) did wrong ?

      Really strange it says GPT is corrupted:

      Source Code

      1. root@Minerva:/media# parted -l
      2. Error: The primary GPT table is corrupt, but the backup appears OK, so that will
      3. be used.
      4. OK/Cancel? OK
      5. Model: WDC WD20 EFRX-68EUZN0 (scsi)
      6. Disk /dev/sda: 2000GB
      7. Sector size (logical/physical): 512B/512B
      8. Partition Table: gpt
      9. Number Start End Size File system Name Flags
      10. 1 1049kB 11.5MB 10.5MB grub bios_grub
      11. 2 11.5MB 4096MB 4084MB root boot
      12. 3 4096MB 2000GB 1996GB data
      13. Error: The primary GPT table is corrupt, but the backup appears OK, so that will
      14. be used.
      15. OK/Cancel? OK
      16. Model: WDC WD20 EFRX-68EUZN0 (scsi)
      17. Disk /dev/sdb: 2000GB
      18. Sector size (logical/physical): 512B/512B
      19. Partition Table: gpt
      20. Number Start End Size File system Name Flags
      21. 1 1049kB 11.5MB 10.5MB grub bios_grub
      22. 2 11.5MB 4096MB 4084MB root boot
      23. 3 4096MB 2000GB 1996GB data
      24. Model: SD SL16G (sd/mmc)
      25. Disk /dev/mmcblk0: 15.5GB
      26. Sector size (logical/physical): 512B/512B
      27. Partition Table: msdos
      28. Number Start End Size Type File system Flags
      29. 1 4194kB 62.9MB 58.7MB primary fat16 lba
      30. 2 62.9MB 3599MB 3536MB primary ext4
      31. 3 3599MB 15.5GB 11.9GB primary ext4
      Display All
      ! Started hacking with ZX81 and I am getting younger everyday like Master Yoda ! ! Raspi is to young generation what ZX81 was to mine ! ! I just love Raspi! Triple bang for the Raspi Foundation ! !And thank you guys for OMV !
    • hi rfv-370

      do you use an powerd USB hub? In my case i've connected my USB HDDs directly to the Raspberry Pi. One possible error source could be the insufficient power supply from the Raspberry Pi. I use a 2,5 Ampere power supply.

      maybe i should try this with an USB hub...

      kind regards

      PS: found now the Tec Specs from WD. Maximum electrical current consumption for a 2 TB is 0,67 Ampere at Startup. So with two HDDs maximum around 1,2 A. that means there are still 1,3 Ampere for the Raspi, which should be enough, i hope

      The post was edited 1 time, last by pbauer84 ().

    • Hi pbauer84,
      both drives are in casing with their own power supply, so the usb card of each drive already powered - I guess.
      And I do not understand how a USB connection error could trigger the full raid to disappear...
      I will try to trace all logs to understand what happened - but I need some time - may be tonight.

      What I find strange is that we both experienced the same issue with the same config at the same time...
      This may be related more with OMV on this specific config...and/or an issue with an update....?

      Is there anybody who could help on how to find an explanation ?
      ! Started hacking with ZX81 and I am getting younger everyday like Master Yoda ! ! Raspi is to young generation what ZX81 was to mine ! ! I just love Raspi! Triple bang for the Raspi Foundation ! !And thank you guys for OMV !
    • Hi rfv,

      I am not an Linux Pro, so i am not able to solve this problems alone.
      reagarding this post klick klack, mabye RAID is not the perfect solution for me.

      Maybe a simple Samba Share with an manual Backup for exampe every weekend is easier to maintain and to handle...

      I'd prefer a RAID 1 Array AND a manual Backup, for exampe every week or every two weeks.

      Now i have no backup.

      greeting from Austria
    • Hi pbauer84,
      well yes, actually a samba share + rsync of the full drive will do the same as a raid 1 actually.
      Which I may have to do as I can see a solution right now - but I am uneasy of this situation for several issues:
      1) I have lost data apparently (still checking) - so the there would be a serious RAID issue somewhere
      2) GPT table can't be corrupted just by chance (have you checked yours?)
      3) OMV is not reacting well when I try to re-setup the RAID through the interface

      I am new to OMV and I may do something which frustrate the system philosophy/process...
      But still it is weird...
      I want /need to understand if not I cannot trust the system with my data!
      so I will try to trace the trail
      ! Started hacking with ZX81 and I am getting younger everyday like Master Yoda ! ! Raspi is to young generation what ZX81 was to mine ! ! I just love Raspi! Triple bang for the Raspi Foundation ! !And thank you guys for OMV !
    • Based on the number of problems with raid arrays on RPis that I have seen, I am going to start recommending against using raid on RPis. Maybe it is just some usb drive controllers that spin up to late but there are too many people have problems with them.

      In my opinion, if you are using an RPi for a NAS, you don't need raid. If you want a mirror, use rsync. If you want a real time mirror, use something with sata ports.
      omv 4.1.11 arrakis | 64 bit | 4.15 proxmox kernel | omvextrasorg 4.1.11
      omv-extras.org plugins source code and issue tracker - github

      Please read this before posting a question and this and this for docker questions.
      Please don't PM for support... Too many PMs!
    • Thanks Ryecoaaron,
      this is clear now and I will follow your advise.
      No Raid. Samba + Rsync
      cheers
      best
      rfv
      ! Started hacking with ZX81 and I am getting younger everyday like Master Yoda ! ! Raspi is to young generation what ZX81 was to mine ! ! I just love Raspi! Triple bang for the Raspi Foundation ! !And thank you guys for OMV !
    • Just remember, this is my opinion. You are free to try. I think this thread finally pushed my opinion against raid on the rpi.

      If only the rpi had sata ports...
      omv 4.1.11 arrakis | 64 bit | 4.15 proxmox kernel | omvextrasorg 4.1.11
      omv-extras.org plugins source code and issue tracker - github

      Please read this before posting a question and this and this for docker questions.
      Please don't PM for support... Too many PMs!
    • hi ryecoaaron,

      i haved tried now samba with rsync. i still have problems with the mounting.

      now i use /dev/sda/ as NAS via samba, and /dev/sdb as backup via rsync. i just made a reboot and both HDDs were not mounted! i had to do this manually. maybe the reason for this problems is the general mounting of an USB drive.

      it is really frustrating...
    • Hi pbauer and Aaron,

      one step further in Pi with OMV and probably solving the issue that pbauer and I faced - with RAID and with not mounting drive on reboot:

      I realise (now) that the USB drives are not mounting each time automatically...after a reboot. Ah ah ah!

      Which probably was a real problem for the RAID manager to access the disks....potentially...

      I had this issue of losing the USB drives after having removed the RAID so clearly not a RAID issue but a USB mount issue with fstab.

      So each time I had to manually 'mount -a' ... a pain in the neck... really. Browsing for a boot script around gave me the answer:

      I had to use this post here htpcguides.com/properly-mount-usb-storage-raspberry-pi/ - scroll down to the chapter : "
      Fix Raspberry Pi 2 Mounting Issues"
      This does 2 things - add a delay on bootup and activate "mount -a" via a boot script.

      So now I have USB drives mounting properly mounted at each boot!

      I have not dared to re-configure the RAID 1...(still planning of using rsync instead).

      But if some want to use RAID on Pi they should know about this - I think. (it was new to me!).

      Hope this helps.

      Best

      rfv

      just in case the post is not there any longer: here the solution for mounting each time you boot USB drive script on a raspberry pi (raspi):


      Fix Raspberry Pi 2 Mounting Issues

      Thanks to Jake for bringing this to my attention. Apparently there is a bug in the Pi 2 that messes up automounting. You can fix it by creating a delay.
      Open up the /boot/cmdline.txt file
      sudo nano /boot/cmdline.txtAdd this line to the bottom, you can increase this delay if necessary
      rootdelay=5Hit Ctrl+X, Y and Enter to save and exit, then reboot to see if it automounts now.
      If the Raspberry Pi hard drive still does not automount we can use rc.local (thanks Julian)
      sudo nano /etc/rc.localAdd this lines before the exit line
      sleep 30sudo mount -aexitCtrl+X, Y and Enter to save
      Reboot again to test

      sudo reboot
      ! Started hacking with ZX81 and I am getting younger everyday like Master Yoda ! ! Raspi is to young generation what ZX81 was to mine ! ! I just love Raspi! Triple bang for the Raspi Foundation ! !And thank you guys for OMV !
    • I don't recommend using raid with usb especially on an RPi anymore. The rootdelay may help though.
      omv 4.1.11 arrakis | 64 bit | 4.15 proxmox kernel | omvextrasorg 4.1.11
      omv-extras.org plugins source code and issue tracker - github

      Please read this before posting a question and this and this for docker questions.
      Please don't PM for support... Too many PMs!
    • I also have the problem that my RAID1 array disappears after a reboot.

      I can get it back using: mdadm --assemble --scan

      The array will appear in the WebGUI again and I can mount the filesystem.

      I'm not using a Raspberry.. just a normal server. Any ideas?

      /etc/mdadm/mdadm.conf looks normal.
    • Same concept. Even worse if the drives are usb. While I don't have a system with this problem, I am pretty sure it is caused by the drives being initialized after the system starts mdadm initialization.
      omv 4.1.11 arrakis | 64 bit | 4.15 proxmox kernel | omvextrasorg 4.1.11
      omv-extras.org plugins source code and issue tracker - github

      Please read this before posting a question and this and this for docker questions.
      Please don't PM for support... Too many PMs!
    • They are not USB drives, they are 2 SATA drives.

      Will try with the delay fixes mentioned above. It sucks 'cause I got mysql data on the array and I have to restart mysql too after assembling the array and mounting it...

      Funny I noticed this after booting in clonezilla to make a backup. Thought I messed up big time. I'm a linux noob. But apparantly I'm not the only one with the issue.

      Btw I love OMV, especially the fact that it runs on 32 bit systems (older hardware in general).
    • I just wanted to update this thread since I was having this same problem running two 1TB USB drives in a Mirrored RAID 1 on a Raspberry PI 3. I have been able to do a work around by setting up within OMV 3.0.88 a Scheduled Job to run at Reboot to execute the command "mdadm --assemble --scan" as user Root. This did work for me for the Mirrored RAID 1 to show up under the RAID Management and File Systems upon a reboot. It also remounts as part of the reboot process as well.