Beiträge von Adoby

You need to provide more information.

What types of "files"?
How are the files updated?
From where are the files updated?
How are the files accessed?
How are the sites connected?
Why not just use a central cloud solution?

This is a great opportunity for you to test your backup system. Just pretend that the old drives died and restore to the new drives.

What does it matter if you loose links to old paths? Just use the new paths. KISS!

Install to the new system partition then restore the data. Fix new backup scripts/routines. Done!

Read only allocated partition should do it. But I don't use Windows, so I can't test it.

I remove the SD card and use a Linux Laptop with a SD card reader to back it up.

I use a script, and dd and partclone. It only copies the partitions. There are other tools that do the same.

I agree it would have been great if you could backup/restore the rootfs from OMV.

See: New to OMV and Linux

I've never figured out how to fix this. I just restore a working backup of the rootfs to the SD card and carry on.

This happened to me a lot because my HDDs are incompatible with hdparm and activating ANY of the physical disk properties caused them to unmount and fail to mount on reboot.

Now I stay away from enabling any of the physical disk properties, and OMV works fine. Also I reflashed the SATA firmware. Se recent posts. YMMV.

OMV doesn't expand the rootfs to fill the available space. Only to 7-8GB. So it should work perfectly to restore the rootfs from a 32GB card to a 16GB card or the other way around, if you don't manually resize the rootfs. I do this, and it works fine.

Just make sure to use a tool that doesn't image the whole card, but only the actual partitions.

Yes that looks right. Everything disabled.

But it should be "/dev/sda" not "/ dev / sda". I assume that the firmware update fails otherwise?

You should get:

"Programming & Compare Success!!" response if the update was successful.

You have to power cycle after successfully updating the firmware. A reboot is not enough. Pull the power plug and wait a few seconds before reinserting it again.

The drive should now spin down after 30 minutes. However you need to make sure that you don't run any software that access the drive, or the 30 minute spin down delay restarts. You must have the rootfs on the SD card or on a remote network share, and not access /dev/sda at all for 30 minutes for this to work.

When you access /dev/sda the HDD will spin up again. That may take a second or two. A small delay in the access while the drive spins up. As you saw above in my smart data it means an increase in start_stop_count. Also you hear the drive spin down or up.

This works fine on all of my HC2s, including with my two 12 TB Ironwolf HDDs.

OK. If it was a physical partition on a physical drive, then this would be easy, just boot from another partition on another drive and install and run for instance parted to resize the partition. Or gparted if it is a full Linux desktop system.

But since it is a partition on a virtual drive I suspect it is not that easy to access the partition on the virtual drive. You may need to use some VMware tool or utility to resize the partition inside the virtual drive while the VM is not running.

If space runs out on the root filesystem OMV will crash.

If you have some software that store data in the root filesystem you can move that data to the data partition and link to the original place in the rootfs. Or mount another partition in the rootfs. Either is good practice to avoid any catastrophic problems with a full rootfs. Also it makes backups of the rootfs smaller and faster to do. I do this for Emby, for instance.

OMV automatically resizes the rootfs on first run. Typically expanding it to 7-8GB. Perhaps that was what happened to you. If you want to resize the rootfs you typically do that after the first run when the install is done. I have no idea how you do that best in your VM environment.

https://wiki.odroid.com/odroid…requtils_cpufreq_govornor

I don't run S. M. A. R. T. other than manually from the GUI. I used it initially only to get HDD temperatures to ensure that the HDDs didn't run too hot. I had problems with the cooling, but I fixed it with a ultra low noise Noctua A12x25 FLX fan for all five HC2s.

Also I underclocked four of my HC2 to 1400 MHz because they are still able to saturate GbE and I only use them as file servers. That makes the HC2s run cooler with less power. One HC2 runs full speed. It is the one with a SSD and on which I run Emby, LMS and some other software. I updated the SATA firmware on all 5, and set spin down to 30 minutes on all of them.

Yes. I set it to 30 minutes when I updated the firmware to SATA. You can set it to whatever you want, as long as it is 3 minutes or longer. See example 4 in the link above. It works fine without hdparm settings in physical disk properties. When I tried the physical disk properties the HDD was permanently unmounted after the first spindown and would not mount on reboot.

Sorry about that. But that is what you get for not giving relevant information along with your question.

One possibility:

Odroid HC2 8TB WD red too big?

I used the S.M.A.R.T. tab in the OMV GUI. Devices, /dev/sda, Info and Attributes.

nas1: (My first HC2.)
Power_cycle_count is 75
Start_stop_count is 952
Power_on_hours is 2007
Power_off_retract_count is 21

It doesn't seem so.

nas1: (My first HC2.)
Power_cycle_count is 75
Start_stop_count is 951
Power_on_hours is 2006
Power_off_retract_count is 21

nas2:
Power_cycle_count is 41
Start_stop_count is 274
Power_on_hours is 1339
Power_off_retract_count is 14

I use 12TB IronWolves with two of my hc2.

I updated SATA and disabled all physical disk properties. Disk->edit. Otherwise OMV quickly dropped/unmounted them.

When I updated SATA I also set spindown to 30 minuters.

Now my IronWolves seem happy...

https://wiki.odroid.com/odroid-xu4/software/jms578_fw_update

Don't backup /tmp.

It is very difficult to correctly fully backup a live root filesystem.

The best way may be to boot from other media and run a backup on the filesystem when it is not live.

It would be great if OMV added some functionality so that you can set a flag somewhere and reboot. And during the reboot a clean full snapshot of the root filesystem is created. Or restored.

It is difficult to figure out the actual size of rsync snapshots. The reason is that several snapshots may share copies of the same file, if the file didn't change between snapshots. That is why you use rsync snapshots.

But the snapshots looks as if they each have a separate full copy of the whole file system. The best way to estimate the size may be to look at free space left on the filesystem and compare that to total space on the filesystem.

Some filesystems don't support hard links that rsync uses to "reuse" unchanged files from the latest snapshot to the next snapshats. If you stick to Linx/Posix filesystems you should be OK. I think ntfs works, but may need some special flags to correctly identify matching files.

If you make many changes to the main filesystem then all changed files will have to be synced the next time. That can take a while.

if you want to improve rsync speeds, don't use SMB/CIFS. Use nfs. Don't use ntfs, use ext4 or some other Linux native filesystem. Don't sync over the network, sync to a local HDD over SATA.

I sync over nfs to/from ext4 filesystems. The transfers are fast and saturate my GbE network.

I use rsync from scripts and as cron jobs. Not from the OMV GUI or plugins. I feel I get better control that way. But that is most likely because that is how I'm used to do it. YMMV.

Hopefully someone else can check your config and spot problems.

Zitat von BC547

Hey Adoby, thank you for the info.
I expanded the second partition by first logging in over ssh as root and then checking the partitions
through 'parted -l' I searched for the SD-card which I identified by its size and then looked at the
size of the two partitions. the second one in btrfs format was very small and so I resized it
with 'parted /path/to/the/drive resizepart -partition number-(2 in my case) Start End ( in sectors)'

This worked and the second partition is now about I gigabyte. I think I had a mishap with the sectors
otherwise it would be larger. Anyhow the error persists and when I try to run 'dpkg --configure -a'
I get:
dpkg: error: failed to write status database record about 'hostpad' to '/var/lib/dpkg/status': No space left on device

What is the problem here ?
Thank you again,
Per

Alles anzeigen

Again, use at least a 8GB card. Also heed ryecoaarons warning:

Zitat von ryecoaaron

The OS partition should be at least 3 GB.

If you have problems expanding the 2:nd partition the card might be bad? The Sandisk Ultra A1 16 or 32 GB cards are nice... I wouldn't buy anything less today.

There are two partitions on the card. A small /boot partition that is around 55 MB. That is fine.

There should also be a root filesystem partition that is at least a few GB in size.

If you install using a SD-card > 8GB then during the install process the root file system partition is expanded to 7 GB. That should be ample room for updates and extra plugins and apps.

Use a good quality card that is at least 16-32 GB. I use 8/16 GB Transcend Premium Class 10 400X and/or 32 GB Sandisk Ultra A1.

If you use a card < 8 GB or the install fails, then the root filesystem partition might not have been expanded. You can expand it manually using for instance parted or gparted.

The install fails if your OMV server can't connect to the internet during the install. You MUST install with your OMV server connected to a network with a router and a DHCP server connected to the internet!

When I install on my 8 GB Transcend cards the install is OK but the root filesystem isn't expanded. If I expanded it manually everything works fine. if I don't expand the root filesystem I get errors like yours when I try to update or add extra plugins. When I install using 16 GB Transcend cards or 32 GB Sandisk Ultra A1, then the root filesystem expansion works fine.