Posts by DeviousDog

Thank you for your assistance @subzero79 and @ryecoaaron. Hopefully this assists someone as I have seen in the forums that there are many issues with RAID.

@subzero79 yes it is now working correctly. I believe the issue had something to do with partition issues and OMV creating 2 file systems on the same HDD, which can cause issues. My question is as to why OMV would not recognize the partitions and /or indicate that there is an already existing filesystem.

Below are some of the relevant configurations after the persistent RAID after reboot if it assists anyone with a similar issue.

cat /proc/mdstat

cat /proc/mdstat
Personalities : [raid1]
md0 : active raid1 sda[0] sdb[1]
      1953383360 blocks super 1.2 [2/2] [UU]


unused devices: <none>

blkid

blkid
/dev/sdc1: UUID="7da352e3-1578-4917-9069-2627852d9716" TYPE="ext4"
/dev/sdc5: UUID="336fba35-418a-4060-81bd-e0b23a83d3ce" TYPE="swap"
/dev/sdb: UUID="77926dd5-6090-65bc-476d-09c5983cffbd" UUID_SUB="dbf65560-ba99-57ee-8d7d-cdcf44a62de0" LABEL="OpenMediaVault:WDRaid1" TYPE="linux_raid_member"
/dev/sda: UUID="77926dd5-6090-65bc-476d-09c5983cffbd" UUID_SUB="0927140f-6dbd-bd54-fbf0-394305e84870" LABEL="OpenMediaVault:WDRaid1" TYPE="linux_raid_member"
/dev/md0: LABEL="WDRaid1" UUID="52e47c5e-01d3-4fca-ba05-dcbafc611780" TYPE="ext4"

fdisk -l

fdisk -l


Disk /dev/sdb: 2000.4 GB, 2000398934016 bytes
255 heads, 63 sectors/track, 243201 cylinders, total 3907029168 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: 2000.4 GB, 2000398934016 bytes
255 heads, 63 sectors/track, 243201 cylinders, total 3907029168 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


Disk /dev/md0: 2000.3 GB, 2000264560640 bytes
2 heads, 4 sectors/track, 488345840 cylinders, total 3906766720 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/md0 doesn't contain a valid partition table


Disk /dev/sdc: 15.5 GB, 15522070528 bytes
255 heads, 63 sectors/track, 1887 cylinders, total 30316544 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: 0x000968db


   Device Boot      Start         End      Blocks   Id  System
/dev/sdc1   *        2048    28983295    14490624   83  Linux
/dev/sdc2        28985342    30314495      664577    5  Extended
/dev/sdc5        28985344    30314495      664576   82  Linux swap / Solaris

This is extremely strange and unusual. After performing the quick wipe and rebooting the server, the RAID persisted. Would it be possible that dual file systems on a HDD caused the conflicts?

After I performed a quick wipe and rebuild the RAID 1 Array, for some reason the data and the file system were still on the drives. I believe that a secure wipe will be necessary. My question is as to why would the file system persist after a quick wipe?

@subzero79 After I backup the data, should I perform a quick or secure wipe on the HDD?

In an attempt to make a backup of my data through windows 7 with EXT2FSD, I observed that the HDD were formatted in RAW Format, which is unusual as during a RAID Rebuild as soon as the disks finished resyncing, they were recognized as EXT4 FS HDD. Could the disks being identified as RAW FS by OMV cause the issues?

I'll do that but RSYNC will have to do if RAID disappears. Maybe the RAID issue is a configuration problem and doing what you said above should work.

Ok so I did reboot after rebuild and initramfs update and the HW RAID did vanish. I know the firmware missing has to do with the Realtek Gigabit Ethernet Controller (I know, not the best for Linux). The backports kernel had many updates pending so I installed them and the fw missing vanished. Does the motherboard have to be RAID Compatible for SW RAID because I know B150 does not support RAID? I believe until I upgrade to an Xeon or AMD Zen platform and get HW RAID, i'll backup my Data to a USB HDD and use rsync for the HDDs.

I did update-initramfs -u again and below is the output.

update-initramfs -u
update-initramfs: Generating /boot/initrd.img-3.16.0-0.bpo.4-amd64
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168g-3.fw for module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168g-2.fw for module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8106e-2.fw for module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8106e-1.fw for module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8411-2.fw for module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8411-1.fw for module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8402-1.fw for module r8169

I am currently re syncing the drives. During the backports kernel install, even though it completed successfully, near the end it said there was a possibly missing firmware with the file ending .fw. When should I run initramfs update? After re sync or during re sync?

@subzero79, I executed the command but I am not sure the RAID changed as it did not appear in the GUI. Do you want me to resync the RAID, or should it already be in sync?

update-initramfs -u
update-initramfs: Generating /boot/initrd.img-3.2.0-4-amd64

@subzero79, below is the output of ls -la /etc/rc[S2345].d | grep mdadm

ls -la /etc/rc[S2345].d | grep mdadm
lrwxrwxrwx   1 root root   15 Feb  6 13:11 S04mdadm -> ../init.d/mdadm
lrwxrwxrwx   1 root root   15 Feb  6 13:11 S04mdadm -> ../init.d/mdadm
lrwxrwxrwx   1 root root   15 Feb  6 13:11 S04mdadm -> ../init.d/mdadm
lrwxrwxrwx   1 root root   15 Feb  6 13:11 S04mdadm -> ../init.d/mdadm
lrwxrwxrwx   1 root root   20 Dec 25 16:56 S08mdadm-raid -> ../init.d/mdadm-raid

Ok I used filezilla to copy the file and this is the output.

Here are the results. I am not sure this is correct because typing

dmesg > /root/dmesg.txt

led to a file creation i believe, but I do not know how to extract the file since I am a Linux noob, so I simply typed dmesg and pasted the contents on Pastebin.

Sorry if I can't reply immediately, I am currently away from home and will return soon. Thank you for your help.

What exactly is dmesg? Is it the OMV log or is it a command to enter in ssh?

If I try mdadm --assemble --verbose --force /dev/md127 /dev/sd[abcdefghijl] like other users have, below is the output

mdadm --assemble --verbose --force /dev/md127 /dev/sd[abcdefghijl]
mdadm: looking for devices for /dev/md127
mdadm: Cannot assemble mbr metadata on /dev/sda
mdadm: /dev/sda has no superblock - assembly aborted

Could the raid issues be associated with the Flash Memory Plugin, or is it just something with OMV or my hardware? I really am at a dead end here. I know the OMV experts like @subzero79 and @davidh2k are great at resolving these issues and their help would be greatly appreciated.

I do not know whether I was clear or how clear I was in my last post, but the raid 1 completely vanishes after reboot and the only solution that I know of is to recreate the array, but that takes at least 6 hours. I do not know what to do to mediate this problem.