Moving existing HDD-s + config.xml + fstab content (except new OS drive) into new hardware

  • Hi.


    I moved all existing HDD's and config.xml and fstab content (except new OS drive) into new hardware with fresh installed OMV.

    As I mentioned config.xml has been replaced by this from the older hardware. It must work, because all drives have been moved from the old OMV into this new one. So all UUID, and so one remains the same.


    The same for fstab except / and SWAP (because of new OS drive).


    So I made omv-salt deploy run fstab (everything OK, no any errors.

    After reboot everything seems to work excelent (including samba and all shares. But I noticed that e-mail notification doesn't work anymore. So I tried to disable the notifications and enable it again. When I try to save my settings I see:




    Any help how to find the reason / how to make this working again ?

    Thank you and best regards

    Mariusz

  • An existing config.xml from one installation is not portable to another fresh installation.

    --
    Google is your friend and Bob's your uncle!


    OMV AMD64 7.x on headless Chenbro NR12000 1U 1x 8m Quad Core E3-1220 3.1GHz 32GB ECC RAM.

    • Offizieller Beitrag

    Any help how to find the reason / how to make this working again ?

    An existing config.xml from one installation is not portable to another fresh installation.

    It can be done, but more needs to be done. This script does it for you.

    • Offizieller Beitrag

    Any help how to find the reason / how to make this working again ?

    Do not run omv-regen on the installation you have now. It must be a clean installation of OMV.

  • Thankl you. I will check your solution.


    Paralelly I checked which modules returns mistakes and I see that only smartmontools makes the issue:


    #omv-salt deploy run smartmontools

    • Offizieller Beitrag

    Paralelly I checked which modules returns mistakes and I see that only smartmontools makes the issue:

    You will have more errors than that. Although in the GUI it seems that things work, the reality is not. Look at everything the script does during the process, it's done in an orderly fashion applying changes at each step. https://github.com/xhente/omv-regen/blob/master/omv-regen.sh

  • Unfortunately, with this script I cant do it (I forgot thjis was OMV v5).

    "Unsupported version. Only OMV 6.x. are supported. Exiting..."

    So anyway I will try to fight manually to move some parts of config.xml

    We will see...

    • Offizieller Beitrag

    Unfortunately, with this script I cant do it (I forgot thjis was OMV v5).

    "Unsupported version. Only OMV 6.x. are supported. Exiting..."

    In that case you can't use the script, effectively. I put that limitation because this is not tested on OMV5. I don't even remember if the database was similar and I guess many more parts will change.

    If you still want to try it you can edit the script but I don't guarantee anything.

    So anyway I will try to fight manually to move some parts of config.xml

    The process is basically replace one part of config.xml apply salt changes, replace another part, apply salt changes...

    On github you have a table with the salt modules that apply to each section of config.xml. It is long. https://github.com/xhente/omv-regen

  • Is there some reason you haven't stated that makes the original system disk unusable on the new hardware?

    --
    Google is your friend and Bob's your uncle!


    OMV AMD64 7.x on headless Chenbro NR12000 1U 1x 8m Quad Core E3-1220 3.1GHz 32GB ECC RAM.

  • chente

    Hat das Label OMV 5.x hinzugefügt.
  • 1. I would like to use smaller one (32 GB instead of current one 250 GB SSD)

    2. I would like to upgrade to ONM v6 (no reason to stay at v5)
    3. Old OMV was used on other location (got other IP @ old LAN). I'm a bit surprised because I thought that it was configured as DHCP client and it's independent from old IP. But I see this OMV dont ask DHCP server about IP to get it, so I think even if that was OMV6, then omv-regen could be easily usable becauso (maybe) old (bad) network settings would be moved.

  • 1. It's possible to attempt moving from a 250GB SSD to a smaller one, if certain steps are taken.


    2. An OMV 5 is upgradeable to OMV6.


    3. Not possible to say what exactly is happening with this other than to say it's almost certainly fixable.

    --
    Google is your friend and Bob's your uncle!


    OMV AMD64 7.x on headless Chenbro NR12000 1U 1x 8m Quad Core E3-1220 3.1GHz 32GB ECC RAM.

    • Offizieller Beitrag

    But I see this OMV dont ask DHCP server about IP to get it, so I think even if that was OMV6, then omv-regen could be easily usable becauso (maybe) old (bad) network settings would be moved.

    The script checks plugin versions too, for a reason, if the version is different the corresponding part of config.xml may also be different, which would lead to configuration errors.

    I don't think you can use it even by cracking the OMV version check.

    You would end up in less time doing the configuration manually in the GUI.

    • Offizieller Beitrag

    3. Old OMV was used on other location (got other IP @ old LAN). I'm a bit surprised because I thought that it was configured as DHCP client and it's independent from old IP.

    With DHCP the router decides which IP is given to the client. So it is normal that the client gets a different IP at first connection and - depending on the router - at every boot or even in between.

  • 2. An OMV 5 is upgradeable to OMV6.


    Thank you for the hint,

    Then If I will be able to repair the network on that OMV5 (via standard Debian config files /etc/network...) I could even upgrade.

    At the moment I see I have no other choice because of this smartmontools error which I can't managed until still.

    I believe that just one module-mistake separates me from easy success ;)

    All other mudules seems to be deployed orrectly.


  • With DHCP the router decides which IP is given to the client. So it is normal that the client gets a different IP at first connection and - depending on the router - at every boot or even in between.

    Generally yes. I use properly configured Mikrotik at my home(s) / locations networks, so each single MAC is given the same IP each time.

  • Jinja2 errors might give a hint if searched on the forum.


    Usual issues were PIP packages install that break OMV.

  • Finally everytching started working after I applied this:


    Code
    omv-confdbadm migrate conf 6.0.0


    Great :D


Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!