Hi there, thanks for responding - we chatted with the etcher pro team and we want to help to determine if this is a problem with the hardware, or a problem with the software, or something not working with the image.
- Could you please try to flash a balena os image for your device type, uncompressed, and report if it works (both the device boots, and no errors from the etcher pro). This will help us determine if there is a hardware problem. Could you try this from the URL, and from a drive.
- Has this etcher pro unit ever successfully flashed your image, to the point that there were no errors reported, and the target device managed to boot from it
- From your original post, I understood that you have tried multiple source drives, both USB and SD, and have always had the same result, is this correct
Hi there, this information is great to know.
As you say, it seems like we potentially have some sort of issue with your
.xz image and the etcher pro. What I recommend next is the following:
- what is the device that you are trying to boot with the sd cards flashed with etcher pro? If its hardware we also have, would it be possible for you to provide us with your
.xz file and we can try to reproduce the problem?
- We can also try to flash a
.xz image and boot it on a device (rpi4) - to see if this might be something common to etcher pro and
- The ubuntu image that you did flash + boot successfully - was it compressed
Thank you for the responses. While we work through them, can you please provide more detail on how you produce the raw drive clone? For example, do you run hardware from the drive before cloning it? Can you describe that process?
Yes, we boot to hardware before cloning. To create our image, we boot on a sample machine, set everything up, then run a wipe script before powering off. This wipe script removes the machine ID, accounts for drive uuids, and clears other data. This image is copied to other SD cards, and then we configure various services when booting a drive for the first time.
Again, this process works great using the standard desktop Balena Etcher software (as well as a direct dd), just not the dedicated Etcher Pro hardware.
Any updates on this issue?
Can we please get an update on the situation? Where are we at, do we need to provide more information, are you looking through this still?
Can you try something please? If you use etcher version 1.5.122 on your desktop, do you get the same error? Release v1.5.122 · balena-io/etcher · GitHub
I used etcher version 1.5.122 on my desktop and I had no issues. All of our issues still relate to the etcher pro.
This is very odd indeed. I just flashed the standard TLS ubuntu image (.img.xz) to a microSD card using EtcherPro, the RPi booted into ubuntu desktop without issues. Would you be able to send us an image that you modified? You can remove any proprietary information, just as long as it’s causing the same issues on your device.
Our image targets an intel x86_64 panel pc. Do you have a comparable system you can test against?
In the mean time I’ll put together an image.
i have an intel nuc that i can test it on, i’ll wait for your image.
Our modified image can be downloaded with the following link: https://dlil75308rlem.cloudfront.net/images/wadsworth-image-stripped-x86_64-20221109.img.xz
A different scenario happened with this modified image. Instead of giving us an error when selecting a source file, this time the etcher pro allowed us to select this file as a source. After I hit flash, it starts up at 0% with an estimated time of 32 min and then freezes. After a short while of being stuck, the screen returns back to the main screen without a source file selected. I have tried this 3 times all with the same results.
We’ve done extensive testing on this image, and found the following: when trying to write from this .img.xz file directly, flashing fails, the diagnostics show that the device runs out of RAM and swap space, since it’s trying to extract the entire file before flashing it. However, flashing from .img works without issues. Notably, if the image is compressed into a .zip or .gz file, EtcherPro can handle it without issues.
I can see that the original image is about 16gb in size, unfortunately that means it would be impossible to flash this image on EtcherPro at this time. It’s related to a known issue in Etcher application. Once the issue in Etcher is addressed, EtcherPro will receive that update. I know this isn’t the answer you hoped for, but rest assured we’re working on it.
What is the timeline for these issues to be fixed and an update to be pushed out?
We are trying to get it solved as soon as possible, but we can’t provide a timeline, since Etcher is an open source project. I understand it’s not ideal, but as I mentioned, there is a workaround (using a different image/archive format) for the time being.
Hello, I am a software engineer that works with B-Le. How do we return our device and receive a refund?
The workarounds you mention – using zip or gzip compression – do not work; the EtcherPro has the exact same problem using these methods.
We have spent three months troubleshooting this issue for you, only to find out it’s something you’ve known about since 2020. Not only was this product expensive, but we have lost significant engineering time trying to make the thing work.
Please provide us with instructions on how we get a refund.