OMV stops responding to remote access

  • Hi guys,

    I've been running OMV for a few months already, and I've been a really happy camper, until it froze twice in the past few days.

    But let's not get ahead too fast... The system is built around a Gigabyte GA-MA69G-S3H AM2 motherboard with 690G+SB600 chipset and Realtek Gigabit Ethernet on-board, a 45W AMD Athlon X2 BE-2350 Brisbane processor with a massive Scythe Ninja passive cooler, 4x2GB RAM modules, all mounted nicely in an Antec NSK-6500 case. For storage, all 4 southbridge SATA-II ports are connected to 4 Seagate SV35.5 (designed for 24/7 writing in video surveillance equipment) drives of 2 TB each and 7200rpm, mounted in an internal, 3-bay cooling rack with a 12cm fan. The drives are configured in a RAID-5. The operating system OMV 0.3.1 Omnius is running on a 8GB 133x Kingston CompactFlash card, mounted in the motherboard's IDE socket through an adapter. (CF cards have IDE interface.)

    This baby has been running flawlessly and quietly for weeks. But then, one morning it wouldn't respond. As it is mounted in a closet with all the other networking equipment, I don't have a display or keyboard as local console. After a reboot, everything seemed fine; nothing showed up in the logs, I only lost about 40 minutes of graphs.

    This morning, it did it again. It wasn't responding even to PING, although the NIC lights seemed normal. After a reboot, nothing was found in the logs either. The gap in graphs shows that something went wrong exactly at midnight.

    The CF card is only 16% full. I'd rather keep this setup than replace the CF with a noisy old IDE drive. I assume I should turn off the automatic graph generation in cron somewhere, but what file do I need to edit?

    What else could be causing this?

    Many thanks in advance!

  • OMV is not optimzed for any kind of Flash/Key drives (not talking about SSDs). So the issue is, that it has a massive amount of write data to the CF and it will wore out your CF pretty fast. Most likely you now have bad cells in the CF and it will let the kernel panic if it wants to write to such a bad block as it carries your root file system.

    It would be best to make a fast backup of your CF and to put it on a external 2.5" USB HD or an internal 2.5" HD.

    Another option may be to optimize it for low amount of write by putting the critical stuff into RAM-disk and mirroring this to flash every hour or so.

    There is a thread here in the forum, which discusses this topic indephts:

  • Thank you for the advice! The problem did not repeat itself so far, but that's no guarantee. In the mean time I upgraded to 0.4.1 Fedaykin, and I'll be looking into the CF mod. Or just throw in an IDE hard drive, the case has 5 more slots available and I have a whole box of old drives, ranging from 2.5 GB to 320 GB.

  • Alright, so today I had another freeze. I selected the quietest IDE hard drive from the box of old parts, a 20 GB Seagate, and cloned the partition from the CF to the drive using CloneZilla. (Had to make an image of the CF on a USB stick, then swap the CF with the hard drive on the IDE connector and restore the image on next boot; can't hook up both of them because of connector mismatch. Oh well, CloneZilla did the job nicely.) Everything is working fine now, I'm just curious if the cloning used the entire drive and increased the partition size, or the drive is using only a 8GB partition. Not that it matters, the whole thing barely uses 1.2 GB anyway.

    Thanks for the tip!

  • No the clonezilla does NOT increase the partition size. So you now have the same partition size as before.

    You can check with fdisk -l /dev/sda or with df -k /

    You can resize the partitions (and move around swap) with parted or gparted. The easiest way is to use PartedMagic. You can download it as a free ISO and boot from a CD to resize the ext4 root partition.

    Your Boot drive would look similar to this:

    So the swap space is at the end in an extended partition. If you want to grow the first partition, where linux is on, you need to move the extended partition all the way back to the end (which is not the best option for swap partitions, and then grow the Linux partition.

    Hope that helps.

  • Hey SerErris, thank you for the detailed explanation! Indeed I was looking at the ol' trusty bootable gparted for this kind of partition reshuffling, but then it occurred to me that, out of the 7.4GB of space allocated to root partition, OMV is barely using 17%. So why bother, especially if relocating the swap so far away will result in a long seek?

    I will try to use gparted to fix the issue with cylinder alignment, though.

  • There is no issue with cylinder alignement on your disk. Your disk is a 512Byte/Sector disk. So there is no reason to realign it.

    The alignement is important for SSDs (which has larger pages) or 4k physical sector size disks.

    My recommendation would be the follwing:

    Still move the SWAP to the back. If you have enough memory >2GB+ then you will barely need the swap space.

    Look at my memory utilisation:

    @openmediavault:~# free
    total used free shared buffers cached
    Mem: 8198152 7923500 274652 0 172964 6701504
    -/+ buffers/cache: 1049032 7149120
    Swap: 9920504 1568 9918936

    So even if I have 9GB of SWAP I did barely use it. And before I will ever write a page to swap, the buffers/cache will get reduced.

    I am not sure at the moment how much RAM you have, but having additional Disk space would not hurt, and having the swap space at the end will not hurt in this case here. Remember your swap space was before on a SLOOOOOW USB key.

  • Thanks for the follow-up! :)

    The box has 4GB of RAM, and it's filled to the brim with page cache. I don't suppose it will ever need to use the swap in this setup.

    The CF card in the IDE adapter was actually one of the fastest on the market, probably on par with the hard drive which replaced it. The swap was likely never used on it either.

  • An update - I used gparted to expand the partition on the drive. Unfortunately, as the extended partition contained a logical partition for the swap, it wouldn't let me move it as-is.

    After several tries of resizing and moving which didn't lead to the desired outcome, I deleted the logical partition for swap and the extended partition. Then, I re-created them at the end of the drive (and even increased the size to half a gigabyte), followed by increasing the primary partition for root to fill the remaining space.

    Everything seems to be working normally now. Thanks again for the help :)

  • :D That's alright, all in all it took more time to move the box in front of the TV and hook it up to a USB CD drive etc. than to repartition everything. A few minutes after trying things I figured I don't actually need any of the data on the swap partition, it just needs to 1) exist as the first logical partition in the extended partition and 2) have the correct partition type. Click-click and it was done.

  • Yep, great that you made it.

    The good thing about SWAP partition is, that there are no valuable data or even structures in it, when the system is shut down. So you simply can move it around. You also could remove it completely, recreated it as another partition number and then change /etc/fstab. Thats all that needs to be done to move SWAP partitions. The swapon command, which is called during boot does the rest :)

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!