It's optional. You can choose before making the regeneration.
Too late, already disassembled the old box
Made the backup with default
Questions about omv-regen
-
-
Too late, already disassembled the old box
Made the backup with default
The backup has all the information. Regeneration options are configured on the new system before doing the regeneration.
-
I will reply and give you a heads-up:
I used the same hostname I had on the CM4 when installing the DebianOS.
My router assumed the same IP for it, yeahhhSorry, I was mislead, the IP changed to 207.
I ran a IP scan and saw 130 still mentioning the hostname but it's not ON.
Will force it to change via omv-firstaid
-
-
Another thing it showed was that not all disks were there.
I saw that it was refering to the original eMMC drive that had the OS so, I assume this is normal and continued with the regeneration.
-
Another thing it showed was that not all disks were there.
I saw that it was refering to the original eMMC drive that had the OS so, I assume this is normal and continued with the regeneration.
Yes, it will not always show existing disks. I haven't always managed to detect them and I left it at that, too much work considering what I charged to do it
. It will warn you but it will not prevent you from continuing. -
Yes, it will not always show existing disks. I haven't always managed to detect them and I left it at that, too much work considering what I charged to do it
. It will warn you but it will not prevent you from continuing.It's doing its thing.
Fingers cross because the wife wants to watch Argylle,
-
-
-
¡Hombre de poca fé!
(I know you understood, you speak Spanish)
Hit the 1st wall:
compose is installed but docker isn't.
omv-extras docker repo wasn't ticked.
After adding the docker repo, all containers were failing, although the settings were all correct (docker root, shared compose ymls, etc)
Reinstalled docker and it just stayed there chewing.
Refreshed the page and docker was installed and running but the containers were all failed.
Edited every single one just by adding a line and removing to force the save.
Pulled the images again (I had arm64 and now it's amd64) to make sure that no leftovers were on it.
Checked them to see if any error would come up.
Started each one and ALL is running as it was.
I did this in a rush and probably I might have not done it as you created (the script).
But it's working so, happy days,
-
omv-extras docker repo wasn't ticked.
That shouldn't happen. If docker was checked in the original installation it should be checked in the new installation. See https://github.com/xhente/omv-…/omv-regen.sh#L1682-L1683
Please look at the backup config.xml file and look for the omvextras section. You should find something like this.
Code<omvextras> <docker>1</docker> </omvextras>I need you to tell me if the value of the docker field is 0 or 1.
Was omv-extras installed before using omv-regen on the new system?
-
-
That shouldn't happen. If docker was checked in the original installation it should be checked in the new installation.
I didn't configured anything when doing the backup and probably screw up somethings.
I just followed your steps of the guide.
I'll check that tomorrow.
Everything is running for now so, no worries
-
I didn't configured anything when doing the backup and probably screw up somethings.
What do you mean by this? I'm just trying to track if there are any errors.
Answer me to this:
Was omv-extras installed before using omv-regen on the new system?
-
Yes
-
-
Ok, thanks, then I think I know what the problem is. I'll figure it out when I have a moment.
I used Debian netinst for the OS.
Used OMV script which installed OMV7, extras and even flash memory plug since I run on a USB stick
-
-
This doesn't seem to be working for me. I have OMV installed (OS on same disk as data). I installed a fresh system on a new box. I ran the omv-regen backup (and didn't select optional folders). I have a very basic OMV install that is just a NAS, so I just need the users (3-4) and shared folders (3-4) transferred to the new system. I installed OMV on a separate disk in the new system. I put the old disk (with OS and data on it) in the new system, ran omv-regen regenearate, and it didn't work. Says the old backup is incomplete. I moved the old disk back to the old system, ran the backup again. Moved it to the new system, transferred the files, and ran it again... nothing. Apparently, I don't get it. I'm thinking it would be faster for me to just setup the new users, and setup everyone again.... Any thoughts? I think I have a very straightforward setup, and this should be simple, but apparently, I'm not doing something right.
-
This doesn't seem to be working for me. I have OMV installed (OS on same disk as data). I installed a fresh system on a new box. I ran the omv-regen backup (and didn't select optional folders). I have a very basic OMV install that is just a NAS, so I just need the users (3-4) and shared folders (3-4) transferred to the new system. I installed OMV on a separate disk in the new system. I put the old disk (with OS and data on it) in the new system, ran omv-regen regenearate, and it didn't work. Says the old backup is incomplete. I moved the old disk back to the old system, ran the backup again. Moved it to the new system, transferred the files, and ran it again... nothing. Apparently, I don't get it. I'm thinking it would be faster for me to just setup the new users, and setup everyone again.... Any thoughts? I think I have a very straightforward setup, and this should be simple, but apparently, I'm not doing something right.
I didn't expect someone with shared folders in rootfs to try using omv-regen. One of the design principles of OMV is to keep user data and the operating system on separate drives. You cannot install OMV on one drive and at the same time connect another drive on which there is another OMV installation (along with data). I'm not sure what can happen if you start the server with two OMV installations but it sure isn't good.
I would try to do the following. You will need another drive the same size or larger than the current size of the shared folders:
- Boots the original system with OMV and data on the same drive.
- Connect a new drive and move shared folders to the new drive. Use rsync to copy the folders. Then edit the relative path of each shared folder in the OMV GUI to point to the new drive.
- Now you have the data on a separate drive and can use omv-regen normally. Make the backup, install OMV on a new drive for the operating system (you can use a pendrive), connect the drive that only has data and regenerate the system. When you check that everything is working, you can format the original drive and use it for whatever you want.
If you have a backup drive with a backup of the shared folders it will be easy to do so. If you don't have it, maybe it's time for you to consider having it. If you don't have another drive of that size and you don't want to buy it, I can't think of what to do, because no matter what you do you will still have the user data mixed with the original OMV operating system. This is one of the reasons to always have user data and the operating system on separate drives. Maybe someone has another idea.
-
The files are on a separate partition than the OS... I don't know if that matters.
QuoteThen edit the relative path of each shared folder in the OMV GUI to point to the new drive.
Can you explain on doing that? Thank you!
-
-
I think I understand, I just go into each Shared Folder in the system, and update it's location to the new hdd. I have everything rsync'ing over... it will be a while. 1.4TB of data. I have a very old slow system.
-
The files are on a separate partition than the OS... I don't know if that matters.
Well, that might make things easier, but it would still require deleting the boot partition before connecting that drive to the new system, losing the ability to come back if something goes wrong.
Can you explain on doing that? Thank you!
Sure, it's simple. You can do everything from the GUI.
Let's take as an example the EXAMPLE shared folder whose path is /EXAMPLE in rootfs:
- Create a shared folder with the name EXAMPLE2 on the new drive, but when you create that folder, in the relative path field replace EXAMPLE2/ with EXAMPLE/. That will create the /EXAMPLE folder on the new drive but in the GUI it will appear as EXAMPLE2.
- Create an rsync job to sync the two folders. The source is the /EXAMPLE shared folder and the destination is the /EXAMPLE2 shared folder. Run the sync. If you have never done it, test the result before by pressing the Trial Run button. Make sure it will do what you want or you could delete your data. If you don't press the Delete button it will never delete anything.
- Delete the rsync job and delete the /EXAMPLE2 shared folder. Data will not be deleted on the drive.
- Edit the /EXAMPLE shared folder. In the relative path field, click the tree icon on the right and look for the new drive in the /srv folder and inside look for the /EXAMPLE folder that you just copied. Select it and accept the changes.
Now the shared folder you had set up is pointing to the new drive.
Participate now!
Don’t have an account yet? Register yourself now and be a part of our community!