My first Raspberry Pi project.

    • Offizieller Beitrag

    openmediavault-diskclone is in the testing repo. It is very basic and just does a simple dd command from the two selected disks. But I have plans to expand it. There is a script that the plugin runs to do that actual cloning. You could schedule this if you wanted a regular clone.


    omv-diskclone /dev/vdX /dev/vdY dd

    omv 7.0.4-2 sandworm | 64 bit | 6.5 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.10 | compose 7.1.2 | k8s 7.0-6 | cputemp 7.0 | mergerfs 7.0.3


    omv-extras.org plugins source code and issue tracker - github


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

  • What will happen if I leave /dev/vdY mounted during a reboot?

    Do we need to change the disk UUID after the dd?

    If you got help in the forum and want to give something back to the project click here (omv) or here (scroll down) (plugins) and write up your solution for others.

  • What will happen if I leave /dev/vdY mounted during a reboot?

    Do we need to change the disk UUID after the dd?

    The results can be unpredictable, but more likely will be reliably not what you desire. And changing only the rootfs filesystem UUID of one disk doesn't fix this.


    If a clone of the boot disk is made with dd, the filesystems on both the original disk and the clone will have identical UUIDs. If both of these disks are plugged in at boot time, one or the other will wind up bing the disk that the OS is run from. But you will have no personal control over this.


    If you were to desire the setup to be a multiboot situation where you choose which disk boots via the BIOS boot menu, then it will not work. This is because the /boot/grub/grub.cfg files on both fisks are also identical, with many references to the same UUID for the OS partition. So in addition to changing the rootfs UUID, you have to make the grub.cfg file refer to the new changed UUID in quite a few places.


    I ran into this exact problem when I wanted to multiboot two different versions of OMV. The first disk was left alone as is at OMV 4. This disk was cloned and then upgraded to OMV 5. When I tried to select which one was to boot from the menu thrown by the PC BIOS it always booted the same version regardless which one I chose. Removing one disk or the other or swapping the physical port positions of the disks if both were to be left in was the only way have the desired one boot.


    Once the edits to the grub.cfg file were made it worked as desired. I run this way now. I can select between booting OMV 5 or OMV 6 on USB sticks with the BIOS menu. One or the other will be the default boot disk if I make no choice at boot time. Which stick is in which USB port controls which is the default.

    --
    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.

  • If a clone of the boot disk is made with dd, the filesystems on both the original disk and the clone will have identical UUIDs. If both of these disks are plugged in at boot time, one or the other will wind up bing the disk that the OS is run from. But you will have no personal control over this.

    This is also the Aquilles heel on the SBCs (at least, on the Pis).


    Case scenario:

    Running OS on the SDcard and dd it to an USBstick.


    On reboot, even if the Bootloader of raspi-config is set to boot from SDcard first, sometimes (most of the times) the Pi loads the /boot from the SDcard but, since the cmdline.txt points to the rootfs PARTUUID that is the same either on the SDcard or the USBstick:

    Code
     cat /boot/cmdline.txt
    console=serial0,115200 console=tty1 root=PARTUUID=4dc9f242-02 rootfstype=ext4 fsck.repair=yes rootwait


    Since the SD bus is slower, most of the times, it will load the USB rootfs partition, instead of the SD one.

    This gives you a hybrid boot that is not intended and won't be easely spotted unless you keep a track on the mount points.


    And if you try to make another dd of the SDcard, it will error since the disk that the command is trying to copy to, is mounted as /root


    For now, the only (real, trouble free) working solution on the Pi is, cloning the OS drive offline.

    • Offizieller Beitrag

    For now, the only (real, trouble free) working solution on the Pi is, cloning the OS drive offline.

    You can clone it online. Just don't leave the the cloned SD card plugged in.

    omv 7.0.4-2 sandworm | 64 bit | 6.5 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.10 | compose 7.1.2 | k8s 7.0-6 | cputemp 7.0 | mergerfs 7.0.3


    omv-extras.org plugins source code and issue tracker - github


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

  • You can clone it online. Just don't leave the the cloned SD card plugged in.

    True.


    But that will change what is beeing attempted here (as I see it):

    Clone the OS to 2nd drive, and have it always attached.


    In case of a failed OS drive, then boot with the clone without the need to physically access the Hardware.


    Unless I've read it wrong, :/

    • Offizieller Beitrag

    Clone the OS to 2nd drive, and have it always attached.


    In case of a failed OS drive, then boot with the clone without the need to physically access the Hardware.


    Unless I've read it wrong,

    That is going to be difficult since you can't remotely control the boot order. While it might protect against a completely failed drive, it won't protect against a bad grub setup or bad kernel. I think the real goal of this is to eliminate having to plugin in a monitor.

    omv 7.0.4-2 sandworm | 64 bit | 6.5 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.10 | compose 7.1.2 | k8s 7.0-6 | cputemp 7.0 | mergerfs 7.0.3


    omv-extras.org plugins source code and issue tracker - github


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

  • With GRUB, maybe a combination of


    search:

    https://www.gnu.org/software/g…l_node/search.html#search

    probe:

    https://www.gnu.org/software/g…tml_node/probe.html#probe


    in combination with...?


    loopback:

    https://www.gnu.org/software/g…ing.html#Loopback-booting


    The UUID's could be re-rolled on the backup image with a ++i on the last digit, (or whatever).


    Even if it all works out, at that point you'd have your own very specialized loader, yet another thing to update/maintain :-/


    Considering a single dd command does it, this all seems like a lot of work. Without the BIOS supporting some sort of if-else first order logic, I can see no way to prevent out right failure (does UEFI have some sort of if-else...?)

  • I just wanted a simple "setup and leave it" way of backing up my SD Card in case of SD Card Failure. Should the SD Card fail, I assume OMV would crash, lights and sirens would go off and it would be pretty obvious that the SD Card had failed. I can then shutdown OMV, remove failed SD Card and the back up media (USB Stick?) with the back up image/files on it, grab new SD Card, copy back up image/files on to new SD Card using whatever software needed on presumably another computer (Mac, Windows or Linux), plug in new SD Card to OMV, reboot OMV and off to the races again I go.


    Reading this thread I now realise now my naivety. It's a simple feature, but in actual fact is far from simple to implement. I hope a way can be found. For now I will continue to back up manually.

  • Maybe the back up could be stored remotely somewhere locally on a network? Is this an idea? Like for instance I have a Time Machine that does all the back ups for my Mac, could the back up be stored there? removing the need for a USB stick to be left plugged in?


    Just a thought, or maybe a brain fart lol

  • thar is how the ddfull backup works. You have to copy it to a different computer / external drive so you have it at hand, when your root disk stops working.

    If you got help in the forum and want to give something back to the project click here (omv) or here (scroll down) (plugins) and write up your solution for others.

  • So I have upgraded from running OMV off a SDCard to a 256GB SSD I had lying around. Responsiveness seems much better and hopefully, less likely to fail like an SDCard.


    https://thepihut.com/products/…osure-for-argon-one-cases for the case


    https://thepihut.com/products/…-0-cable-for-raspberry-pi for the cable


    Used the dd command on my other raspberry pi to copy the image from the SDCard onto the SSD then raps-config to expand the image on the SSD.

Jetzt mitmachen!

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