File System not initialising

I seem to have come across this problem, where I go to create a file system for one of my 3TB drives, however it goes through the whole process, I can see the window showing me the process it's going through and in the background, I can see that the disk is 'Initialising'. However once the process of formatting and creating the file system stops, the disk just simply disappears from the list as if it was never there to start with.

Is there anything you can think of that I'm doing wrong at all? I have made sure to wipe the drive first each time.

sda is an 80Gb disk for the OMV OS.sdb is a 2TB drive intended for raid mirroringsdc is a 2TB drive intended for raid mirroringboth drives were used previously with an old FreeNAS raid system and are in good shape as the system was not used much, spending most of its time off.Before starting a new installation, I used the CLI to perform hard drive preparation.These are my steps:

sgdisk --zap-all /dev/sdbsgdisk --zap-all /dev/sdcthen:dd if=/dev/zero of=/dev/sdb bs=4M count=1dd if=/dev/zero of=/dev/sdc bs=4M count=1I used an ISO image of OMV from the website burned to a DVD yesterday afternoon.Performed full installation to sdaOpened the web GUIperformed quick wipes on both drivesmoved to File System and attempted to create file systemShortly after the formatting process begins, the drive shows up in the list seen in the background as initializing.Just after the popup window announces that it completed with success, the drive disappears from the list.Tried it again, same drive, sdbSame result.Tried with sdcSame result.Pulled together information, replied to your post.What am I doing wrong?

This should disappear once the system is updated.The fasted way to do the update on a fresh install is omv-update from CLI. Or use the update in the GUI, but in some cases this will cause some errors and the update has to be started several times.

As your system might be a bit messed up I would start with a fresh install and then update.

Then I would secure wipe ONE drive and let it complete. Then make a filesystem on that one drive and check if it disappears. May be also try a different file system type like btrfs instead of ext4. Not sure if it makes a difference, but it does not harm. And if it works you can quik wipe the drive and create ext4.

Forget about the second drive until you have the first one up and running.

I would also not use RAID, but this is another point and can be discussed once you have one drive working.

If one wants a "spinning" hard drive that's virus free, free from persistent partition flags, with a fully wiped boot sector, etc., DBAN does the job. Since the boot sector is the first place DBAN wipes, it only takes a few minutes to clean things out. For this purpose, starting a build with a clean drive, a full pass is not really necessary.

DBAN appears to be a windows program.I would need to pull the drives from the OMV box and use a USB external device to connect and wipe from a Windows PC.I don't think I need DBAN for this.I'll go with diskpart first, and see if it'll do the trick.I just don't follow the need for using another OS to fix a hard drive for Debian OMV, why can't OMV do it?

Used diskpart to examine drives. One of them has a partition, no volumes, or anything else.The other one didn't have any partitions.Removed the partition found, re-installed drives into OMV....quick wipe...File System, used btrfs, looked good at first, then:Failed to execute command 'export PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin; export LANG=C; mkfs -V -t btrfs -O skinny-metadata,^mixed-bg -L 'Bee' '/dev/sdb1' 2>&1' with exit code '1': /dev/sdb1 appears to contain an existing filesystem (zfs_member). ERROR: use the -f option to force overwrite of /dev/sdb1 btrfs-progs v4.7.3 See http://btrfs.wiki.kernel.org for more information.

OK, my bad,DBAN is an ISO image.I'm booting to the CD now on the OMV box, let you know...First boot crashed, just one of those things...Ctl-Alt-Del...worked 2nd time...Selected interactive mode...Selected both of my 2TB disks...used default setting of DoD Short...F10 and now we wait...looks like about 17 mins...Wait, that's incorrect, that says 16 hours...Whattttt?It was difficult to get the programs attention because I don't know the break command because I didn't read the directions fully.Anyway, started over using Quick Erase.If it truly performs the header stuff first, then I should be good to go after a few minutes.The time estimate is 6 hours...Aborted the process after 15mins.

After using DBAN, the quick wipe, & format still failed in exactly the same way.

After using wipefs -a /dev/sdb and wipefs -a /dev/sdc, I performed quick wipes on both drives, then moved to File System and created on /sdb an ext4 format, or partition, not really sure which.Drive appeared in the background as before, and...Holy Smoke, the drive remains!Let me try /sdc now...It worked as well...so THANK YOU THANK YOU THANK YOU for your help.macom suggested that I not use a RAID mirror for my data storage, why is that?If all goes well this machine will be used for CCTV archiving for a small private school and it seems to me that RAID would be a good choice, so I look forward to hearing a response.Thank you again for responding and for providing a solution.I'm still curious about the need to jump through so many hoops to trick OMV into using the drives.

macom suggested that I not use a RAID mirror for my data storage, why is that?

Because it can be problematic when not used with server grade hardware. Why do you want raid? If you want it for redundancy because the system can't be down, then maybe it is ok. But it isn't backup and a scheduled rsync job is better than a mirror in my opinion.

OK, I'm having trouble seeing your responses in the forum. Sorry about that. I'm having to check my Notifications often, then I see responses that I'm not seeing.Now that the drives are successful in File System, I can mount them.