Trying regeneration on an RPI4 with updated Raspbian and it now has been stuck on "Configuring salt systemd" for at least 30 minutes. Is this "normal"?
It's not normal. What part of the database was being regenerated at that time? Can you post the last lines of the output? You can see it in the log. It is in /var/log/omv-regen
I had to interrupt the process. I'm going to give it another go and post the output /var/log/omv-regen if it gets stuck again I'm a little unclear about the procedure, so I want to check if I've understood the process correctly.
Previously I had Debian installed on an SD-card and the Pi was connected to an external usb-drive where OMV was installed. My goal now is to install Raspbian on a smaller usb-stick and keep the Pi connected to the same external drive.
I installed Raspbian on the new stick after disconnecting the external drive and ran apt upgrade and apt full-upgrade. I shut down the Pi and connected the External drive and started it up again.
After the Pi had booted up, the external drive, where the OMV-regen-backup is located, was not mounted, so I mounted it under /media/External and ran OMV-regen regenerate.
Edit: Forgot to mention that I obviously installed OMV before running OMV-regen.
I'm planning to update OMV from v6 to v7. Will OMV-REGEN config backup restore previous v6 config on v7 after update? Has anyone else tried doing this.
Same result on second try, system stuck and had to pull the power. When trying to log in again, my password is rejected. Pulled the stick and connected it to my laptop, checked /var/log but the log file was empty. I'm giving up on this for the time being, guess I'll have to set everything up from scratch again.
Previously I had Debian installed on an SD-card and the Pi was connected to an external usb-drive where OMV was installed.
That's confusing. You cannot have Debian installed on one drive and OMV installed on a different drive. Maybe you mean you have a USB data drive and the OS on the SD card?
After the Pi had booted up, the external drive, where the OMV-regen-backup is located, was not mounted, so I mounted it under /media/External and ran OMV-regen regenerate.
If that drive was configured in the original system that will not work. The best procedure is to copy the backup to a folder in rootfs. You can do it via ssh, with WinSCP or whatever you want. In the worst case you can mount another drive or a different pendrive with the backup, but it is not the best.
I'm planning to update OMV from v6 to v7. Will OMV-REGEN config backup restore previous v6 config on v7 after update? Has anyone else tried doing this.
That can't be done. The regeneration will leave the system as it was in the original system.
If you want to update I suggest you follow the usual procedures for this. Search omv-release-upgrade in the forum.
That's confusing. You cannot have Debian installed on one drive and OMV installed on a different drive. Maybe you mean you have a USB data drive and the OS on the SD card?
If that drive was configured in the original system that will not work. The best procedure is to copy the backup to a folder in rootfs. You can do it via ssh, with WinSCP or whatever you want. In the worst case you can mount another drive or a different pendrive with the backup, but it is not the best.
That's what I meant.
I realized that mistake and on the second attempt I copied the backup to a rootfs folder, still got stuck in the same place.
Made a third attempt with a new backup placed in a rootfs folder, same result. I'm posting the last lines of the terminal output below as no log is available:
Formatting database
Reading the value of /config/system/usermanagement/users in original database...
Reading the value of /config/system/usermanagement/users in actual database...
Regenerating /config/system/usermanagement/users...
Creating temporary database...
Deleting current /config/system/usermanagement/users node...
Copying original users tag...
Moving users to /config/system/usermanagement...
/config/system/usermanagement/users node regenerated in the database.
Applying configuration changes to salt modules...
Configuring salt postfix...
Salt module postfix configured.
Configuring salt rsync...
Salt module rsync configured.
Configuring salt rsyncd...
Salt module rsyncd configured.
Configuring salt samba...
Salt module samba configured.
Configuring salt systemd...I would if I could but the system becomes inaccessible after it's stuck at this line. It seems to be stuck forever and if I pull the power and restart and try to log in again it rejects my ssh password. Anyway, since I seem to be the only one having this problem, I'm not going to pursue this further, I'm going to do a clean installation. Big thanks for trying to help me though!
I'm trying to migrate an ARM (armbian) install of OMV 7 to amd64. When I run the restore (regenera) in omv-regen, it says the system is "The current system is not configured. It's right."
Then it runs apt, finds no packages to install, then returns to the menu without installing any configuration. The /etc/openmediavault/config.xml file hasn't changed and nothing else runs. What did I do wrong?
Ah, the problem was that the backup was taken with a previous version of OMV. omv-regen was generating an error to this effect, but it wasn't showing up in the UI or in the log. Once I redid the backup, everything worked.
I'm glad you solved it.
but it wasn't showing up in the UI or in the log
Regarding that, I can say that I am working on a new version of omv-regen that greatly improves Log management and many other things, but I think it will take a while to release. So I won't touch anything in the current version unless it's a serious bug.
Advice needed: I have a failing HD (according to SMART info) that houses my OMV OS. The system is currently running well (for now!), with 30+ docker containers, SMB shares on 3 external storage drives, etc. I wish to replace the 320Gb system HD with a (much) faster 256Gb SSD. I currently use the Backup plugin with a scheduled fsarchiver option.
What is the preferred (read - easiest!) option to swap out the old, slower, failing HD with a newer, faster, but smaller SSD?:
1. Follow the instructions elsewhere in this forum and attempt a restore of the fsarchiver onto the newer SSD (where I think I might run into problems using gparted to restore the partitions from the backup, because the new drive is smaller) or
2. Create a new install on the SSD, then use omv-regen to recreate my installation on this new SSD?
or maybe a third option:
3. Install OMV onto a 64Gb USB stick and use omv-regen to recreate the system onto that? Thinking that would make system backups easier in the future. Power down. Clone USB stick. Power up.
In the end, the obvious indicator of success is that I power up my system after the swap and all services work as before!
Any advice welcome!!
UPDATE: Just realized that omv-regen is not intended to be a full OS backup. I have made mods to the base Debian, specifically the addition of all the Nvidia drivers, which was not trivial to get up and running (and keep running!). I think my solution will have to be using Clonezilla (with the icds option) to create a clone of my current drive onto the new system drive.
all options (and variants of) are feasible but I see the hassle you have with additional config (in your update).
For option 1 - i think (not 100%) that you will need to resize source HD to 256gb or smaller then clone it. And I would look into the smart error details first as depending on the drive (and file system) status you might be cloning a screwed system and/or clonezilla might not like it...
I personally would go down the option 2/3 route. It might be more work but you will end up with a better system design and a stable one too!.
For me, it is a waste of 256gb ssd to run OMV/linux.
I would suggest 32/64gb USB (preferably a ssd over sd) for OMV / linux install
Use the 256 ssd for fast/frequent system data (e.g. docker install, persistent docker data, plex etc)
Do you have direct access to the system (monitor keyboard) or is it headless?
Display MoreFor me, it is a waste of 256gb ssd to run OMV/linux.
I would suggest 32/64gb USB (preferably a ssd over sd) for OMV / linux install
Use the 256 ssd for fast/frequent system data (e.g. docker install, persistent docker data, plex etc)
Do you have direct access to the system (monitor keyboard) or is it headless?
I agree with the waste, but I got the 256Gb SSD very cheap. I currently have the docker compose plugin installed and configured as having the Compose Files on a shared disk (not on the system disk). Because I have to configure Nvidia drivers for use in Plex/Jellyfin/Tdarr/etc, the OMV instructions say that I have to leave the Docker Storage setting blank, which then runs Docker on the OMV system disk. This is another reason I have decided to use a decent SSD as the system disk.
I do have direct access to the system.
My first thought is to:
1. Power down the system
2. Install the new SSD
3. Boot from a CloneZilla Live image
4. Format the SSD (ZFS?)
5. Follow these instructions to use CloneZilla to clone a larger disk to a smaller disk. (-icds option)
6. Power down the system
7. Remove the old system HD
8. Boot the system AND EVERYTHING WORKS! 
Any (other) suggestions appreciated!!
It gets messy and more complicated to backup/restore if you combine omv os with omv system data together.
That's why I think a separate sd card just with omv os on it will be better. I don't have nvidia gpu (i use intel cpu/gpu) but have gpu transcoding working fine in plex/docker with docker installed and running on a separate omv system data ssd. So I would check your assumptions on this config requirement. If you can separate os and system / appdata I 100% would.
Format ssd as ext4 as it will have omv installed on it and ext4 plays better with docker. With zfs I would only use it on data disks and would look into btrfs as it's built into linux without having to run proxmox kernel.
I don't think your clone approach will work. You can't go from larger to smaller disk even with -icds option. You can go smaller to larger... It is possible to do what you want if you resize the source disk first using gparted - but that is risky. Have a full disk backup/clone first. Not fsarchiver option!
So overall I think your process could work with some tweaks. If it were me, I would do it differently using a clean install and either manual reconfig or omv-regen.
Don’t have an account yet? Register yourself now and be a part of our community!
