Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Don't recommend balena etcher (includes spyware/adware) for writing/verify images #66

Closed
rradar opened this issue Mar 20, 2020 · 26 comments
Closed

Don't recommend balena etcher (includes spyware/adware) for writing/verify images #66

rradar opened this issue Mar 20, 2020 · 26 comments

Comments

@rradar
Copy link

rradar commented Mar 20, 2020

As balena etcher is growing fat (>400Mb) and ugly (includes tracking, analytics, ads - or "promotend content" the authors like to call it) these days it would be a good move to suggest the users a proper lightweight alternative which does the work without spying and ads.

Their is various FOSS software out their which does exactly the same etcher does (writing and verify). One of them (available for Windows, MacOSX and Linux) is the less than 300Kb small usbimager

image
https://gitlab.com/bztsrc/usbimager#comparition

Etcher is linked on the website ('SD writing tool', faq-section: How to start) and mentioned in the docs:

It could serve as a good example for others: OpenMediaVault-Plugin-Developers/docs#9
@igorpecovnik
Copy link
Member

I agree with you and I do hate bloat / spy ware ... and support you, but we need common agree on this. SD write verifying is for us a very important part - it has to be enabled by default. Without, there is no way to even think about change. On the other hand, we don't have time to deal with SD write tooling ... which is why Etcher was chosen. Let's see for other opinions.

BTW. I already throw out Etcher from our build system armbian/build#1522

@tido-
Copy link
Contributor

tido- commented Mar 21, 2020 •
edited
Loading

In the begin there was version of Etcher that had problems. So, I didn't upgrade. I am still running Etcher 1.2.1 on my Ubuntu Mate 18.04, works like a charm (80 Mb)

Edit: A must was - standard writing verification. IIRC this was back in the days an option you had to set a 'tick' on Win32 DiskImager. Before we change anything - proper testing and writing down the steps to achieve a great result is a must.
@igorpecovnik , since Etcher the forum is almost empty of SDcard troubles.

@tido-
Copy link
Contributor

tido- commented Mar 21, 2020

I created a topic here: https://forum.armbian.com/topic/13421-need-your-help-what-else-beside-etcher/

@rradar
Copy link
Author

rradar commented Mar 21, 2020

I guess another reason for less SDcard troubles (beside doing the mandatory verify) is also the improved build quality and affordable prices today. A couple of years ago you could buy cheap only with low quality and good cards costed double, tripple or more than the basic ones. Today you just buy cheap and get quality cards rated A-something - no need to pay more for that anymore. But in all verifying should be done anyways. If someone fails repeatingly verifying a written image it's a good thing to try f3 - in the best case it can fix partly broken flash storage.

@igorpecovnik
Copy link
Member

since Etcher the forum is almost empty of SDcard troubles.

Verifying is the essential and also SD cards got much better indeed. But they still do break ... while I am a heavy user.

IMO we can change recommendation, which will anyway not steer people away from Etcher. That takes much longer ... let's just wait for some feedback and if we can push towards that verify is default enabled? I don't want to compile our version because of that.

@rradar
Copy link
Author

rradar commented Mar 21, 2020

we can push towards that verify is default enabled

if more users are asking for this, I'll made "verify" checked by default.
https://gitlab.com/bztsrc/usbimager/-/issues/5

Looks like we can 🎉

@rradar
Copy link
Author

rradar commented Mar 22, 2020 •
edited
Loading

Their is no 7-zip support in usbimager and it's not planned because it's

very very very (very) badly documented

and

totally non-portable

the maintainer of usbimager states here

FYI, I'd recommend against using 7-Zip and xz. They might be smaller than other formats, but they suffer from serious design flaws which makes them inappropriate for long term archiving, and makes them highly vulnerable to transmission errors. One single bit error can render the file uncompressable and you can throw the entire archive out of the window. Read more: https://www.nongnu.org/lzip/xz_inadequate.html

If armbian wants to go with usbimager in the future it looks like the type of archive needs to be changed to support flashing directly from the archive. Supported types are gzip, bzip2, xz, pkzip, zip64

@rradar rradar closed this as completed Mar 22, 2020
@rradar rradar reopened this Mar 22, 2020
@kriston
Copy link
Collaborator

kriston commented Mar 22, 2020 via email

@igorpecovnik
Copy link
Member

How about Raspberry Pi Imager?

Can we build it automatically / when needed?

@kriston
Copy link
Collaborator

kriston commented Mar 22, 2020 via email

@igorpecovnik
Copy link
Member

Yes, I saw this. This only means its opensource :)

We need a maintainer, a person that will setup Jenkins job and rebuild at will / when needed / when upstream will be build ... with our patches.

@rradar
Copy link
Author

rradar commented Mar 23, 2020

I think to stay with something existing and not forking and maintaining a new thing saves valuable time for the core project of armbian.

Is the change of the archive type (to one usbimager already supports) something armbian could agree on or is this out of reach?

That being said I'm not against of supporting 7z in USBImager, just need a good doc or a minimal portable lib. So far I was unable to find any.
Btw, USBImager uses the first file in the archive, so if it's the .img, then armbian 7z will work too.

the maintainer of usbimager

@igorpecovnik
Copy link
Member

Is the change of the archive type (to one usbimager already supports) something armbian could agree on or is this out of reach?

Anything in this regard is a long term change. We had lots of discussion on this in the past.

I think to stay with something existing and not forking and maintaining a new thing saves valuable time for the core project of armbian.

If someone that currently does not do something around armbian, this is not a problem. I will certainly not touch it - I barely find time to read/respond here. It also require not typical skills needed for our main objectives which is also good.

TL;DR;
If we have verify default on, next problem is how to provide pgp signatures and SHA checks? .gz is a single file compressor.

https://armbian.atlassian.net/browse/AR-185

@rradar
Copy link
Author

rradar commented Mar 23, 2020 •
edited
Loading

If we have verify default on

USBImager in Version 1.0.1 was just released and includes verify on by default 🎉

next problem is how to provide pgp signatures and SHA checks? .gz is a single file compressor.

Did etcher included such a functionality to check the signatures/checksums of the archive or image file? Maybe such feature could be included to usbimager also...

@shoka555
Copy link
Contributor

I've built and installed rpi-imager on my Linux Mint laptop.
It builds painlessly and creates an output .deb file.
Installing that deb adds a new application to the Mint menu structure nicely.

That side of the project is excellent.

However it seems to be focused on fetching images from the net, rather than allowing selection of image files on the local system. The git page suggests parameters to feed the binary to use a local repository, but that does not seem to allow a simple directory search for image files.

As a test I selected the Raspbian lite link it offered, and put an SDcard in the Mint system.

I have no idea where that image came from, presumably the RPi Foundation download site...

Disconcertingly the select SD card button opens a selection dialog, but having made the selection the button gives no indication that an SD card has been selected.

Triggering the write behaves as expected, with a progress bar that changes colour when the operation goes from writing to verifying the image.

When verification completes, it provides a message saying the SDcard can be removed, and when that is acknowledged, exits.

I will continue with etcher, at least for the moment.

The lack of choice of download method is one limitation, I usually use torrent downloads, in consideration of upstream's bandwidth.

The opaqueness of the source of the images offered is disconcerting.

The lack of facility to verify the image shasum after download but before writing is limiting.

The inefficiency of downloading images every time you write one is also a limitation, I usually verify that my copy of the upstream image is still current, and only download again if its not.

Also the inability to write more copies of the image in one pass, I often use the facility in etcher to burn more images in one set up.

Not sure where it is aimed, presumably at absolute beginners with a shiny new Pi and no familiarity with general tools.

Harry

@tido-
Copy link
Contributor

tido- commented Mar 23, 2020

TL;DR;
If we have verify default on, next problem is how to provide pgp signatures and SHA checks? .gz is a single file compressor.

Did etcher included such a functionality to check the signatures/checksums of the archive or image file?

Not that I am aware of and it is NOT necessary. If people download with .torrent, it does this check auto-magic-ally. This is one of the reason, apart for spreading the load, that I always prefer .torrent.

I will soon write the Kubuntu 20.04beta on my memory-stick, but before I do so I will update to the latest .deb from bzt :)

@igorpecovnik
Copy link
Member

Thank you @shoka555 for this write up!

Maybe such feature could be included to usbimager also...

If we stay on .gz, which is acceptable, we would need a custom option within USBimager ... if ARMBIAN image is loaded then download file SHA from Armbian server (+ note/link to how you can verify manually if you don't trust usbimager) and run check on a file. If server is unreachable = warning, if sha fails error otherwise burn the image?

@kriston
Copy link
Collaborator

kriston commented Mar 24, 2020 via email

@shoka555
Copy link
Contributor

shoka555 commented Mar 24, 2020 via email

@shoka555
Copy link
Contributor

shoka555 commented Mar 24, 2020 •
edited
Loading

In my defence the comment on the website

If the application is started with "--repo [your own URL]" it will use a custom image repository. So can simply create another 'start menu shortcut' to the application with that parameter to use the application with your own images.

led me down a false path, as using that option did not find any image files, for me.

however


shoka@ShokaLaptop:~$ rpi-imager --help
qt5ct: using qt5ct plugin
rpi-imager [--debug] [--version] [--repo <repository URL>] [<image file to write>]

also looks promising.

H

@shoka555
Copy link
Contributor

Testing again, the other "foible" that misled me, is that the drop down menu initially shows no scroll bar, only a selection hand. Click dragging the entries with that selection hand, scrolls the list, and displays a scroll bar thereafter. Not sure if this is a QT feature, a Cinnamon feature, or deliberate by the developers.

H

@kriston
Copy link
Collaborator

kriston commented Mar 24, 2020 via email

@igorpecovnik
Copy link
Member

An opportunity to heat this up: https://forum.armbian.com/topic/13141-armbian-v2005-kagu-planning-thread

@igorpecovnik
Copy link
Member

igorpecovnik commented Apr 4, 2020 •
edited
Loading

.xz format was implemented and next images will be done with it. Links are unchanged, only sha and gpg files were added: https://dl.armbian.com/melea1000/

@lanefu
Copy link
Member

lanefu commented May 22, 2020

Documentation now recommends usb-imager first, provides additional description that etcher may contain spyware.

Are we good to close this issue?

@tido-
Copy link
Contributor

tido- commented May 22, 2020

Documentation now recommends usb-imager first, provides additional description that etcher may contain spyware.

Are we good to close this issue?

I guess you didn't read that in the forum
@Orangepee , in regard to you PR, there are two sections to address, if you don't mind:
https://docs.armbian.com/User-Guide_Getting-Started/#how-to-prepare-a-sd-card
https://docs.armbian.com/User-Guide_Basic-Troubleshooting/#writing-images-to-the-sd-card

@lanefu lanefu closed this as completed Jun 1, 2020
@igorpecovnik igorpecovnik mentioned this issue Jun 1, 2020
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@kriston @lanefu @igorpecovnik @shoka555 @tido- @rradar