cloning / ghosting

clevesqueclevesque Posts: 11New Member
Hello,

Once your board is prepared, what solution do you propose to copy it to your other boards? Building a ghost image?

Thanks!

Comments

  • Robert SheltonRobert Shelton Posts: 109New Member
    Hi Clevesque,

    Looks like we are seeking the same solution - all of a few seconds apart! B) I'll update my post to refer to yours and we can continue the discussion here.

    Thanks,
    Robert
  • clevesqueclevesque Posts: 11New Member
    hehe cool!

    Let me know if you find anything. Because this is a new product is it still hard to find any documentation but I guess the up board dev team must have already think of something for this.
  • Robert SheltonRobert Shelton Posts: 109New Member
    edited August 2016
    I found this reference for Ubuntu: https://en.wikipedia.org/wiki/Clonezilla

    I am trying to avoid the dd low-level copy process bc that takes far too much time based on experience using it with SSDs for RPi systems. Have been using a product named Apple Pi Baker on my iMac to create SSD images, which is much faster than dd. If I could get the image "out" of the eMMC and onto a usb thumb drive, APB could import that to use as a master image. The problem, however, is that APB also prepares the SSD card format... which would not work with non-removable eMMC.
  • Robert SheltonRobert Shelton Posts: 109New Member
    Another candidate: Ghost for Linux (G4L)
    https://sourceforge.net/projects/g4l/
  • Elie De BrauwerElie De Brauwer Posts: 35New Member
    Well this all depends on your usecase. Cloning images is one things, keeping a fleet of devices up and running and foreseeing a stable upgrade path is a different thing. For me personally the 'clonezilla' approach is a manual approach which could be great for initial/manual bootstrapping. And tools range from a simple dd to a more intelligent clonezilla, but one should always be aware that one often does not want a 100% exact copy, since an exact copy would also mean: a) all use the same ssh private key b) possible disk UUID conflicts c) udev issues with cached parameters such as mac addresses, ....

    What I am doing in my case is splitting the eMMC in three, a bootloader partition and two firmware partitions and I'm playing 'ping-pong' between both firmware partitions using grubs. An 'upgrade' consists out of replacing the entire rootfs (and kernel) which my build processes (based around debootstrap) delivers are a checksummed tarball. In case op upgrade failure a rollback to the previous partition is foreseen.

    When you plan to run these in a datacenter fashion and thus typically for a single goal/purpose it could be interesting to consider tools like docker, where each node pulls a container from a central docker repo, and have all your upgradeable logic there.

    The only massive drawback on the upboard is that there's not out of the box PXE boot support so you wouldn't be able to do bulk installation of blank board over the network.
  • MarcelloMarcello Posts: 155New Member
    Is there a pxe option in the pipeline?
  • ccaldeccalde Posts: 187New Member, Emutex mod

    Hi all,

    Here you have a first PXE boot tutorial for Linux on UP platforms:

    https://wiki.up-community.org/Enable_PXE_boot

Sign In or Register to comment.