OMV 6 boots only once after restore from dd backup (move from VM to bare metal)

  • With the new Broadcom policies regarding ESXi, i decided to move away from VMWare. Fired up a Proxmox VE hypervisor on a different hardware, moved the other VMS there, and the plan for OMV was to convert it to bare metal. The "old" OMV was running on VMWare with HBA pass-through. The plan for the migration looked straightforward:

    • Restore a backup to a brand new USB thumb drive
    • Fix the networking (new network adapter device names)
    • The shares should come up automatically since all the data drive are connected to an HBA that was presented to the OMV VM through PCI pass-through.


    Initially, the migration was OK... until the first reboot. It straight refused to boot. The machine complains that there is no valid boot media. I managed to boot from the USB using SystemRescue ISO (on a different USB thumb drive) using the "Boot local Linux installation" (findroot), but that's not a solution. Tried every Grub repair scenario i could find with no success. If i restore the DD backup again, the system boots with no issue... until the next reboot. I am yet to try restoring from a backup (DD again) made while the system was running on bare metal (newer).


    Any takes on what might be happening?

    Maybe i should ditch the USB thumb drive and use an internal disk (i have a spare 120G SSD that i can use for this)?


    EDIT: If it makes a difference, the restore was done using rufus on Windows.

    • Offizieller Beitrag

    An alternative path could be omv-regen. I think it's simpler.

  • An alternative path could be omv-regen. I think it's simpler.


    Interesting... Didn't know about this.

    I have the option to do the regen from a working bare-metal installation (re-image the USB thumb drive from the backup) or from the VM (i can still boot the old ESXi on the same hardware).


    EDIT: Reading through the docs makes me wonder why this not the default recommended backup/restore process instead of the "standard" disk image approach.


    EDIT2: I guess the requirement to use the current available version of the system and plugins might be a deal breaker for a long term backup solution. Hence the recommendation to do the backup and regen as soon as possible.

    • Offizieller Beitrag

    Reading through the docs makes me wonder why this not the default recommended backup/restore process instead of the "standard" disk image approach.

    If you read the omv-regen documentation carefully you will see that it has a clear limitation. The success of the regeneration depends on the system being up to date at the time of backup and regeneration.


    That makes omv-regen useful for moving the OMV system to other hardware or another location, or simply moving the OMV configuration to a newly installed system. But omv-regen is not useful as a permanent backup. The backup you make today with omv-regen probably won't be useful in a day or two to do a regeneration, at least a full regeneration. If you need a backup that you want to be able to restore at any time, the right way is openmediavault-backup.


    I created the omv-regen script and maintain it, however I use the openmediavault-backup plugin with fsarchiver to have a system backup. And I also use omv-regen in an automated way simply to have config.xml as a reference and a few other things.

  • A quick follow-up...

    The culprit ended up being faulty USB thumb drives (plural). The migration issue was finally resolved by restoring a recent fsarchiver based backup (was able to create one in one of these occasions where the system would actually boot) to the internal SSD.

  • macom

    Hat das Label gelöst hinzugefügt.
  • macom

    Hat das Label OMV 6.x hinzugefügt.

Jetzt mitmachen!

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