Beiträge von bbddpp

Thanks for sticking with me. So it's reasonable to assume that within 2 weeks a new out of the box external USB drive could be killed by the system? If that's the case, seems to be a good reason for no one to ever want to connect an external USB to OMV.

Are there any settings/configurations I can make to a physical disk in the settings when I add it to have OMV go easier on the device? I don't need the thing to be lightning fast, reliability is the key here. It's just storing or streaming video.

ryecoaaron,

Let me apologize -- I was mistaken on the quality of this drive. I found a driver to read the drive in ext4 format under Windows, and it's DEFINITELY messed up. The drive worked well as an NTFS drive for Windows for some time, however, OMV seemed to eat this thing for breakfast somehow.

I was reading some posts around the web about some external drives not being suitable to work with Linux/Debian and as a result that the drive basically was having its hardware corrupted by the system? Is it possible that the way I have this thing configured in OMV or set it up is causing it to quickly deteriorate?

Thankfully, Seagate has a warranty on this and I'm going to swap it out once I get as much data off it as I can (it was just a video backup drive, nothing that cant be replaced).

If I hook up the new one and the same thing happens to the new drive, can I assume OMV or Debian is eating this drive alive? Hopefully you have some ideas of what I can check/try when I configure the replacement drive to make sure I'm not setting something up wrong.

See anything weird? This all from syslog:

Jun 27 10:27:23 WallMedia kernel: [83638.888807] EXT4-fs (sdg1): mounted filesystem with ordered data mode. Opts: acl,user_xattr,usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0,acl
....snip...
Jun 27 11:06:47 WallMedia kernel: [ 2.721394] sd 6:0:0:0: [sdg] 625142448 512-byte logical blocks: (320 GB/298 GiB)
Jun 27 11:06:47 WallMedia kernel: [ 2.721646] sd 6:0:0:0: [sdg] Write Protect is off
Jun 27 11:06:47 WallMedia kernel: [ 2.721650] sd 6:0:0:0: [sdg] Mode Sense: 23 00 00 00
Jun 27 11:06:47 WallMedia kernel: [ 2.721909] sd 6:0:0:0: [sdg] No Caching mode page found
Jun 27 11:06:47 WallMedia kernel: [ 2.721947] sd 6:0:0:0: [sdg] Assuming drive cache: write through
Jun 27 11:06:47 WallMedia kernel: [ 2.723959] sdg: sdg1 sdg2 < sdg5 >
Jun 27 11:06:47 WallMedia kernel: [ 2.725306] sd 6:0:0:0: [sdg] Attached SCSI disk
....snip.....
Jun 27 11:06:47 WallMedia kernel: [ 3.148591] EXT4-fs (sdg1): mounted filesystem with ordered data mode. Opts: (null)
Jun 27 11:06:47 WallMedia kernel: [ 3.313434] usb 6-5: string descriptor 0 read error: -22
Jun 27 11:06:47 WallMedia kernel: [ 3.313475] usb 6-5: New USB device found, idVendor=13d3, idProduct=3393
Jun 27 11:06:47 WallMedia kernel: [ 3.313477] usb 6-5: New USB device strings: Mfr=1, Product=2, SerialNumber=3
...snip...
Jun 27 11:06:47 WallMedia kernel: [ 9.354911] sd 6:0:0:0: [sdg] Unhandled sense code
Jun 27 11:06:47 WallMedia kernel: [ 9.354915] sd 6:0:0:0: [sdg]
Jun 27 11:06:47 WallMedia kernel: [ 9.354917] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Jun 27 11:06:47 WallMedia kernel: [ 9.354918] sd 6:0:0:0: [sdg]
Jun 27 11:06:47 WallMedia kernel: [ 9.354919] Sense Key : Medium Error [current]
Jun 27 11:06:47 WallMedia kernel: [ 9.354921] Info fld=0x0
Jun 27 11:06:47 WallMedia kernel: [ 9.354923] sd 6:0:0:0: [sdg]
Jun 27 11:06:47 WallMedia kernel: [ 9.354924] Add. Sense: Unrecovered read error
Jun 27 11:06:47 WallMedia kernel: [ 9.354926] sd 6:0:0:0: [sdg] CDB:
Jun 27 11:06:47 WallMedia kernel: [ 9.354926] Read(10): 28 00 00 00 03 30 00 00 08 00
Jun 27 11:06:47 WallMedia kernel: [ 9.354931] end_request: critical medium error, dev sdg, sector 816
Jun 27 11:06:47 WallMedia kernel: [ 9.354969] Buffer I/O error on device sdg, logical block 102
...snip...
Jun 27 11:06:47 WallMedia kernel: [ 14.712365] Adding 7179260k swap on /dev/sdg5. Priority:-1 extents:1 across:7179260k FS
Jun 27 11:06:47 WallMedia kernel: [ 14.722056] EXT4-fs (sdg1): re-mounted. Opts: (null)
Jun 27 11:06:47 WallMedia kernel: [ 15.330584] EXT4-fs (sdg1): re-mounted. Opts: errors=remount-ro

File system seems to keep unmounting and remounting as read-only, etc.

I realize on paper this looks like a bad external drive, however this is the 3rd USB drive I have tried to use on OMV on this system as a device connected via USB, and everyone one gets read/write errors and has this symptom, every time I have tried. I have to think it's a software or hardware issue here, or the way the drive is being accessed by OMV.

I can confirm CPU usage at idle is around 7%, and as soon as I try any operations to the connected USB drive, CPU spikes to 80% - 100% usage during the entire copy operation until the drive spins down. Something's not right.

My problem may be a little different though -- It just has to do with general read/write performance of the system overall when sending data to/from an externally connected USB drive.

I wonder if taking a look at the logs (a certain section) might help. Just in the interest of helping the developers. This may also be something that is just a natural side effect of the way things work. I notice a significant spike in CPU usage while the copies are running and the USB drive is seeing heavy use. If I then try and access the drive otherwise (steam a file from it, get a directory listing, etc) -- Forget it. The entire system spikes to 100% CPU usage and craps out.

I checked my BIOS to make sure that I'm not overworking it or something and everything certainly seems on the level to me. But there must be something I am doing here that is causing OMV to not like passing data via the USB channel (perhaps it's the combination of drives in the system that is causing the bottleneck, since all the file moves taking place are internal).

I'll try and post more detail if I can, I realize these are not easy problems to solve, but I'd sure love to be able to use this external USB drive without troubles since I am fresh out of SATA ports inside this machine.

I've unmounted the drive for now and am running some fsck commands on it. OMV really hates it when I have this drive up though and I constantly get "communication error" thrown by the GUI as soon as I attempt to copy any files to it. Even with it unmounted, the whole system seems really unhappy when I connect a USB drive and try and copy files over to it.

This is more than likely some weird configuration thing that I am doing wrong. Is there an easy way I can just grab some log items for anything related to this drive, sdg, and post here to see if you see anything funny? There an easy way to do that? Not sure where to start and copy/pasting from the log in the GUI doesn't seem possible.

Works great under windows. It's a seagate external drive 5tb brand new out of the shrink wrap.

I had a similar problem with another usb external drive I tried to use with OMV so I yanked it out of the case and put it into a 2 bay esata enclosure which worked better.

Any suggestions on getting a usb external drive to play better? This is the second one that's acted the same way for me.

OK I'm stupid but learning. Thanks.

Got the fsck's to work, thanks for the help. Instead of doing fsck -f -y /dev/sdg1 I was doing fsck /dev/sdg (without the 1 on the end). Duh.

Now I just need to figure out why my external USB storage device is behaving so badly. My kingdom for more SATA ports!

Hi guys,

Not sure why I am not seeing replies, I must be going nuts. Thanks. Anyway...I have the drive connected to a USB3.0 port on the tower and am sure 3.0 ports are all set to active.

I am using the 3.16 kernel right now.

It seems that OMV is able to boot and see the drive, but doing things like attempting to do a large file copy (I cp'ed some stuff from one volume to the external via the shell overnight, woke up to the deadlock again). It seems to do OK when it's the only thing happening on the system, but as soon as a second proceess happens (in this case, it was a sabnzbd download unopacking), everything sort of breaks down.

When I try to access the volume this morning via ssh or visually in Windows, it freezes and doesn't report back.

From the log:

Jun 26 09:08:22 WallMedia kernel: [34238.381250] sd 6:0:0:0: [sdg] Command timed out
Jun 26 09:08:22 WallMedia kernel: [34238.381259] sd 6:0:0:0: [sdg]
Jun 26 09:08:22 WallMedia kernel: [34238.381263] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Jun 26 09:08:22 WallMedia kernel: [34238.381267] sd 6:0:0:0: [sdg]
Jun 26 09:08:22 WallMedia kernel: [34238.381269] Sense Key : Not Ready [current]
Jun 26 09:08:22 WallMedia kernel: [34238.381275] sd 6:0:0:0: [sdg]
Jun 26 09:08:22 WallMedia kernel: [34238.381278] Add. Sense: Logical unit is in process of becoming ready
Jun 26 09:08:22 WallMedia kernel: [34238.381282] sd 6:0:0:0: [sdg] CDB:
Jun 26 09:08:22 WallMedia kernel: [34238.381284] Read(10): 28 00 3f 48 01 41 00 00 09 00
Jun 26 09:08:22 WallMedia kernel: [34238.381297] end_request: I/O error, dev sdg, sector 8493468168

Thanks so much for the fast reply -- The rescue CD and PartedMagic optionss both eventually booted but I'm missing something obvious as fsck is refusing to run due to other processes running.

I tried a umount -a as well after entering the admin password during the boot, and it keeps telling me it can't unmount due to processes currently running.

I'm an idiot when it comes to linux command line so bear with my dumbness. Is the command fsck -f -y /dev/XXX for the drive that is throwing errors at boot?

Another idea...

I do get into OMV eventually - Can I use the GUI to somehow unmount all the bad drives and ssh in and run fsck?

I've got two volumes that OMV is telling me need fsck manually run on them when I boot. When I put in admin password it's not letting me run fsck due to something being mounted.

I tried rebooting under recovery mode, same problem, also tried rebooting under systemrestorecd (plugin i installed a while) and it's just hanging.

I'm sure there is a stupid easy workaround or command I can run to get fsck to run without restrictions. Can someone help a dummy out?

Great info, thanks. I'll install all the "oldstable" updates until the official Jessie-based release comes out late this month.

I love OMV.

I'm an idiot...See it's not official 'til end of June.

Until then, should I be installing all the "oldstable" updates in the update manager to 1.19?

I noticed my update manager getting filled with tons of "oldstable" and was coming here to ask if I should install those...Only to realize, wow, we're on a whole new version now!

While I'm surprised the interface didn't let me bump to 2.0, I imagine I did something to cause this. Does anyone know how I can do an easy update (hopefully headless) from 1.19 to 2.0+ via ssh or the GUI? I assume this won't hurt any of my settings, or break my sickbeard/saznzbd plugins, etc? I hope?

Thanks for any advice. Surfed the forum but surprisingly didn't see any threads on going from 1.x to 2.x so I must be missing something obvious here.

I'm out of SATA ports and bays on my OMV box so I decided until I had more time to relocate files and replace with larger drives, I would just attach a Seagate USB3 external drive. Was able to both initialize the drive as ext4 and mount it no problem.

It's plugged into a USB3 port on my tower.

Here's the issue - Performance is just terrible when copying files to or from the device. Gets as fast as 4 MB/s and then stalls all the way down to 200 KB/s before gradually getting up to 4 MB again, then droping back down, etc. Most of the time it's around 500 KB/s.

So slow that it seems to bog down the entire system as far as response time, not just the drives involved in the copy. I've tried it both over SMB as well as NFS and directly over SSH. It just seems that the speeds writing to this 5TB USB Seagate external are EXTREMELY slow.

I seem to recall having a similar issue prior to this when attempting to attach an external drive and then just gutting the case and putting the drive on SATA. Am I doing something wrong or is there anything I can try? Is there a way to determine if the ports I am connecting to on the case are truly USB3 and not just USB2 (and would USB2 explain the slowness)? They are labeled as 3.0 ports but perhaps the case was assembled wrong and they're connecting over to USB2 busses on the mobo?

Any thoughts most appreciated.

Can we remove the entire sabnzbd directory and everything below it from /home once this new install is completed?

Hoping this Ubuntu newb can get some help.

One of my drives is failing and causing OMV to refuse to boot. It's asking me to run fsck manually (DRDY ERROR) but doing so tells me there is a bad superblock and invalid ext2 file system. I can provide screenshots and further details if you like. Seems I get the "bad superblock" even if I try and run fsck on one of the other drives in my system so maybe I am just going about this the wrong way. Just want to let Ubtuntu have the chance to check this drive, mark any errors, boot into OMV, copy off as much data from it as I can, then swap the drive out. Right now OMV won't even boot, and if I CTRL-D to try, it runs into a heap of errors along the way (I think after several hours it finally got in, but I've since rebooted again and back to the stuck point with the DRDY error at 95% and the manual ask to run an fsck I can't seem to get to run).

I don't use any sort of RAID in my system at all, just a separate drive and file system on each physical disk. So there is no danger of data loss across volumes. Still, I'd like to get the system booting and recover as much data as I can before I swap out this drive.

Can anyone help me get the fsck command or other command I need to run on this drive at the command prompt so I can at least get in?

SABNZBD has always been a problem for me in servers since it doesn't have a GUI-based upgrade method.

It also seems that OMV doesn't have a way to do this with the plugin upgrade, I'm still a version behind.

Is there a trick you can do with SSH or something to shut down, upgrade SABNZBD's code, and restart it, to be on the latest? GUI (like CouchPotato offers) would be best but I don't think this is possible in SAB?

I'll answer my own questions here in the hopes it helps others.

Not at all sure why the system was freaking at my drives, it might have been because they were previously mounted on the backports kernel. After installing the backports kernel, and one at a time adding each disk, I was set. It helped that I found the .cfg file I needed to edit to manually remove the old file system entries too. Big help. Using nano to remove them was the way to go, via ssh.

On to my other issue, the external USB drive. It seems that OMV, once you initialize a disk as an external USB drive, expects it to always be that way. It flat out refused to read the bare drive until I put it back in the enclosure. So, I'm manually copying files to another internal drive from the external so I can free myself from that tether. Lesson learned. Not sure if it is even fixable or not, but for anyone who plans to temporarily use an external USB connected device and then gut the drive for internal, don't.

Things seem pretty stable now. Now I just need to figure out if I need to install any of the firmwares listed on the updates screen from tbe backports kernel...Does it hurt to install all that stuff even if you don't use it or should I just ignore it? I don't see a firmware for my Qualcomm Atheros ethernet anywhere and it's still not functioning so maybe I'll just leave my PCIE card in long term.

Thanks all.

Sort of running out of ideas here, but here's what I tried.

I figured that starting over might be best, and since I am a newb and don't know which system files to edit to modify the file systems, figured out a new way. I decided to fresh format a new external drive with OMV (I run the system via USB) with all the SATA drives unplugged. Then, one at a time, I would plug each drive back in, and mount its file ext4 system. This seemed like a good idea when I did it with the first drive. However, after a shutdown, connecting of the second drive, and a reboot, I had MAJOR issues, and all kinds of I/O errors on the drive that OMV noticed and the system eventually just stopped booting (coincidentally, removing all the SATA drive data cables and rebooting worked like a charm, so OMV was really hating trying to mount that second drive).

Mind you, if I boot the system with a Debian rescue CD, both hard drives are connected and they are showing up just fine.

Is there a way that openmediavault can even do this, or am I barking up the wrong tree? My assumption is that I can just manually add existing ext4 drives to a new OMV installation, one at a time, without having to destroy the data on the drives. Am I mistaken? Is the only way to add a new drive to OMV to connect and initialize/destroy it, and then copy content over to it?

Weird situation here, but something I was surprised that didn't work and I'm hoping can be easily fixed.

I had a file system I created inside of OMV on a USB connected external hard drive. Was working great.

I decided I wanted to rip the drive out of the enclosure and put the bare drive into my server, connected via sata. I figured, the drive is formatted using EXT4, should detect right up.

I was wrong.

OMV can't find my file system anymore. It sees the physical drive but my only options seem to be to wipe it or create a new file system on it, losing all of its contents?

Am I correct that I have no other options? Is there any way to tell OMV to just take an existing EXT4 drive it previously set up and and import it or do I need to put this back in the case, connect it via USB, and copy the files to an internal drive in order to get them off of there before I can use the drive free of the enclosure now?