Etcher has been a Steel Pillar as far as writing images to removable media is concerned. There are a few hiccups, and the speed-bump or two, but it is my go-to tool for doing just about everything that has to do with writing raw images.
The feature I most appreciate is it’s ability to verify that the image was written correctly - which has saved my bacon on more than several occasions where the image wrote like a charm, but failed verify miserably.
I’m doing robotics research with the GoPiGo, and am working on modifying the base image into something more useful for certain segments of the user population. This entails making an image of my SD/microSD card, and then flashing it to the target cards. And no, I don’t just happen to have an Etcher Pro or two laying around gathering dust. (wink!)
What I would like to do is a “reverse-Etch” (I called it an un-etch), where I use Etcher to take a physical device, copy it to an image file, and then verify that the image is correctly copied.
Other tools like dd, or even ddrescue, will copy wonderfully, but you have no bloody idea if your image is worth a snowflake in Hell or not.
I would love to be able to use an Etcher-like tool to reverse the process.
It’s possibly a bit heavyweight for what you’re wanting to do, but CloneZilla allows you to boot a device with it, then creates a disk image for a given device (such as an SSD, etc). This should work (though I’ve not tried it) for example on any balenaOS device that allows booting from USB/SD for the x64 architecture (you’d have to rebuild it for any other, I’m not sure if alternative arch packages exist), as well.
Yep, you’re right. Clonezilla is like trying to use a Polaris missile to crack a nut. Quite frankly, I’m not all that happy using it as a Linux backup tool either - it’s too fussy and I just don’t get a good feeling about the quality/accuracy of the images it makes. Maybe I’m wrong, but if the hair on the back of my neck ain’t happy, I ain’t happy! (grin!)
I’m hoping for something as simple to use as Etcher to make the image that Etcher will ultimately use. (And then I use Etcher to make the media, and then un-etcher to make the image and then Etcher to flash the media, as I slowly get sucked into a swirling mass of recursion. Fractals anyone?)
So unfortunately the only thing I can really suggest at this point is dd, which you’re already using. I don’t believe we have any plans to have Etcher carry out image creation, but I’ll contact the relevant team members to see if they’ve anything to add!
With all due respect to everyone at Balena, I’m surprised that this hasn’t come up before.
Part of the basic drive behind Etcher was the fact that flashing an image to any type of media is a tangled-up and knotted ball of yarn, requiring non-trivial amounts of both skill and patience.
So now we have Etcher and the masses have spoken: Etcher ROCKS! It takes a knotty and complex process and makes it as simple as sitting down in your chair.
But the reverse is also true.
In order to successfully flash an image and have accurate media, you need to start with an accurate image. When it comes to distributing an image for people to flash, nothing less than absolute and unwavering perfection will do.
And you need to be able to - unequivocally - know that your image is as good as the original media you created it from.
Balena has produced the Gold Standard for etching images. Now is the time to “close the loop” and make distributable image creation as simple and foolproof as creating the media copy from that image.
Ideally, the image creator should be able to:
Given a source media object, (like a flash drive or a SD/microSD card), allow the user to make an exact binary image as easily as it is to use Etcher now.
It should allow the image to be the size of the data, not necessarily the size of the media. (i.e. 4 gigs worth of data on 256 gig media should be 4 gigs in size, and able to flash to any media large enough to hold the 4 gig image.)
It should be able to verify the image is correct and complete.
It should be able to generate and save a checksum file for the image. This will allow the user to test the downloaded image for accuracy, prior to burning the image to the target media.
Possible option: Allow the user to select the hash strength, with SHA-1 being the default. Absent that option, the default hash strength should be no weaker than SHA-1, and possibly even SHA-256.
Given the existence of a checksum file like this, it would be useful to have Etcher read this file and verify the accuracy of the image before creating the media copy.
Whilst I don’t disagree that this is a useful mechanism, the ability to clone physical media to an image or ISO file is a far rarer use-case than that of flashing an image or ISO. People install an OS far more than they try and take snapshots of an already present OS on a physical drive. I appreciate that there is a need for copying and cloning media, but usually this is carried out by administrators of systems to make backups or custom installation media, and there are a number of professional packages out there that do this as well as free packages such as Clonezilla.
Many OS distributors have their own OS generation tooling that does not actually involve the cloning of physical media, but generates filing system partitions directly into an image or ISO file. At balena, this is exactly what we do, taking a built image from an OpenEmbedded build and injecting application specific configuration into a user specified version of an image for a particular device that the user then downloads.
Etcher was designed specifically to allow a user to efficiently and simply flash an image to a range of media, and this is useful to balena as it allows the images generated by balenaCloud to be flashed onto media to provision a device.
I’ve pinged the Etcher team, as mentioned in the last email, in case we have looked into doing the reverse, but I haven’t heard of any plans on this front.
I can’t dispute that. However I would counter that day-trips of over a hundred miles, each way, were a rare use-case prior to the invention of efficient transportation.
Before optical media burners were perfected, burning your own “image” on a CD was relatively rare, as you could get numerous “coasters” before you got a working image. Even then, the software had to catch-up and develop the skill to verify the burned image - simply because it “worked” didn’t mean it was “correct”.
Even now, various groups, both amateur and professional, are more willing to distribute flashable image files now that a tool like Etcher exists.
Hi, I asked around internally about this feature, and it’s on our roadmap as “backup drive” functionality. For now it’s future plans but we are thinking about how a feature like this might work. Good to hear that there is already some interesting in this.
