Flashing with a url did allow us to use the .xz file. It passed flashing and verification of 3 out of 4 SD cards on variable slots but none of them work with our system. They all display mdadm: no arrays found in config file or automatically. Gave up waiting for root file system. On the last failed SD card it displayed a source and destination checksum mismatch. We are not even using mdadm in our software.
Multiple .img files
We have not tried multiple .img files. The errors mainly come after the flashing process when the SD card doesn’t work with out system, but we don’t see any of these issues when flashing through the Etcher on our Windows computers.
Same Error
The same error does not apply to all the scenarios. It only applies when using our main .xz file that works on the computer. The cloning process gives us a bunch of errors on our Linux check process such as error: failure writing sector 0xfed008 to hd0 and putting it into emergency mode. The .img file either ends up being blank or fails during flashing with the warning that isn’t able to access certain drives.
Multiple slots
I don’t know if this helps but the source file can only be selected from the left most inserted drive. Flashing the SD card in the other slots appear to yield the same results, regardless if it is one or multiple flashes at a time.
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
When flashing our uncompressed file from a USB drive, the flash passes without error but doesn’t boot properly. The same happens with the compressed URL. When flashing our uncompressed URL file, the flash takes a considerable amount of time and still returns mdadm: no arrays found in config file or automatically during the boot process.
Note that we have tried flashing a standard Ubuntu image from Get Ubuntu Server | Download | Ubuntu through a USB and the flash passed and boots properly, so now we are thinking there is something weird going on with the Etcher Pro and our image specifically since everything works with the Windows PC.
The etcher pro does flash the image “successfully” in terms that there are no errors but our device doesn’t boot properly. The boot process is always what fails when using the etcher pro with our custom image.
We have used both a USB and SD as a source drive using the same img file but the result is the same in terms of our device doesn’t boot properly after flashing. Using both USB and SD as a source drive using the same .xz file results in the i/o read error from the original post.
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 .xz images
The ubuntu image that you did flash + boot successfully - was it compressed .xz?
We are targeting Intel x86_64 machines. Our image is a modified Ubuntu 20 LTS raw drive clone, compressed with xz. We would prefer to not share our image since it contains some proprietary data. But we could make a modified version to send to you if completely necessary.
Yes, could you please try flashing an rpi with a .img.xz from the etcher pro?
The Ubuntu image we tried is their standard ISO9660 bootloader. We cannot format our image with ISO9660 due to file constraints.
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.
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.
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.
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.