chwe Posted July 6, 2018 Posted July 6, 2018 should we move this to one to: https://forum.armbian.com/forum/31-sd-card-and-power-supply/ as a pinned thread? Actually I think it should be 'saved' somewhere due to it explains the reasons and opinions why Armbian recommends to use Etcher and I think it would fit best there. It might be good to have this somewhere where it doesn't get lost due to new threads showing up. 2 hours ago, tkaiser said: That's why it's so important to ONLY RECOMMEND ETCHER all the time. only recommend a tool which validates the Image after burning.. And at the moment, only etcher seems to do this.
Tido Posted July 6, 2018 Posted July 6, 2018 5 hours ago, chwe said: etcher also provides a CLI tool, etcher-cli-1.4.4-linux-x64.tar.gz 20MB ? a compressed CLI tool, really?
tkaiser Posted July 7, 2018 Posted July 7, 2018 10 hours ago, chwe said: should we move this to one to: https://forum.armbian.com/forum/31-sd-card-and-power-supply/ as a pinned thread? Yes, please. And if you're at it deleting all three posts from 2nd page since off-topic (we really should focus on stuff that's important)
Tido Posted July 7, 2018 Posted July 7, 2018 1 hour ago, tkaiser said: deleting all three posts from 2nd page since off-topi censorship in the Name of a Kaiser is okay. I see!! 1
guidol Posted July 7, 2018 Posted July 7, 2018 13 hours ago, chwe said: only recommend a tool which validates the Image after burning.. And at the moment, only etcher seems to do this. how about the verify-function of the newest win32 disk imager?https://forum.odroid.com/viewtopic.php?f=53&t=947http://dn.odroid.com/DiskImager_ODROID/Win32DiskImager-odroid-v1.3.zip orhttps://sourceforge.net/projects/win32diskimager/files/https://sourceforge.net/projects/win32diskimager/files/latest/download?source=files Image Writer for Microsoft Windows Release 1.0.0 - The "Holy cow, we made a 1.0 Release" release. ============= New Features: ============= Verify Image - Now you can verify an image file with a device. This compares the image file to the device, not the device to the image file (i.e. if you write a 2G image file to an 8G device, it will only read 2G of the device for comparison). Additional checksums - Added SHA1 and SHA256 checksums. 1
Igor Posted July 7, 2018 Posted July 7, 2018 5 hours ago, Tido said: censorship in the Name of a Kaiser is okay. I see!! 7 hours ago, tkaiser said: Yes, please. And if you're at it deleting all three posts from 2nd page since off-topic (we really should focus on stuff that's important) I found another solution
chwe Posted July 7, 2018 Author Posted July 7, 2018 2 minutes ago, Igor said: I found another solution creative solution for boring problems... But due to: 5 hours ago, guidol said: how about the verify-function of the newest win32 disk imager? I'll reopen it, I think it makes more sense to discuss it here, otherwise it's just spread anywhere... and back to topic: No idea how well the new version of win32disk imager works, but I support programs which care about their users.. After a short look into the issue tracker it seems that they do it well. I don't see a reason I should move from it. 17 hours ago, Tido said: 20MB ? a compressed CLI tool, really? what's wrong with 20MB size?
TonyMac32 Posted July 9, 2018 Posted July 9, 2018 On 7/7/2018 at 10:38 AM, chwe said: what's wrong with 20MB size? *rabble rabble* I wrote utilities whose lengths were measured in bytes *rabble rabble* But to be fair, 20 MB seems about 18 MB too big at least.
tkaiser Posted July 9, 2018 Posted July 9, 2018 29 minutes ago, TonyMac32 said: But to be fair, 20 MB seems about 18 MB too big at least. Etcher has been developed to be platform independent (so not only Windows users can benefit from it but also users of other common operating systems). No one right in his mind will code the CLI variant in a different way than the UI application. Both UI and CLI variant therefore rely on the same code base and libs/modules: https://github.com/resin-io-modules And as a logical result even the CLI tool becomes somewhat bloated since that's the price you pay when using Electron apps. On the bright side: Etcher folks are aware of the problem and at least more recent versions are not that fat as older ones: bash-3.2# find /opt -name etcher | while read ; do du -sh "${REPLY}"; done 74M /opt/etcher-cli-v131/etcher 64M /opt/etcher-cli-v141/etcher 63M /opt/etcher-cli-v143/etcher On 7/7/2018 at 11:14 AM, guidol said: how about the verify-function of the newest win32 disk imager? Why do you ask these questions instead of giving some answers for people not using Windows? Do all Win32DiskImager installations on this planet got already (auto)updated to this 1.0 version or do users have to manually download the new version and replace the binary? Does verify happen automatically or is this an additional step that has to be chosen manually after burning?
guidol Posted July 9, 2018 Posted July 9, 2018 3 hours ago, tkaiser said: Why do you ask these questions instead of giving some answers for people not using Windows? Do all Win32DiskImager installations on this planet got already (auto)updated to this 1.0 version or do users have to manually download the new version and replace the binary? Does verify happen automatically or is this an additional step that has to be chosen manually after burning? The question was a hint, because some did wrote that only etcher could do a verfify. Sure, not all Win32 DiskImager installations on this planet get autoupdated, so I did wrote about the NEWEST version with links for Windows-download! The verify doesnt start automatically, but its only one click after write without selecting drive or image (auto-verify could be a request for the next version). I often do search informations via google an do help many people here in the forum - so I am not only do write questions, I also try to give answers. 1
chwe Posted July 9, 2018 Author Posted July 9, 2018 3 hours ago, tkaiser said: Etcher folks are aware of the problem and at least more recent versions are not that fat as older ones: IMO they see problems where there aren't.. Could it be smaller, indeed but is it really something the users care (I don't think so)? If we look at the newest version of win32diskimager: Win32DiskImager-1.0.0-binary.zip 2017-03-08 17.0 MB so somehow on the same size (clear, the win32DisImager has a gui). blockquote widget 7 minutes ago, guidol said: Sure, not all Win32 DiskImager installations on this planet get autoupdated, so I did wrote about the NEWEST version with links for Windows-download! nothing wrong with it. It's good to see that other writetools start to care about what they write to media. I wont change to the diskImager due to obvious reasons (I need a tool which works on windows & linux).
tkaiser Posted July 9, 2018 Posted July 9, 2018 37 minutes ago, guidol said: some did wrote that only etcher could do a verfify Ok, one last time: it's about the AVERAGE USER and THEIR AND OUR TIME. Not about what some 'experts' use and some anecdotes like Etcher always generating kernel panics while Win32DiskImager working flawlessly (haha). Does this Win32 tool provide an auto update mechanism so it's ensured each and every user who downloadded this tool in the past is already using the latest version? If not then recommending this tool is a great way to sabotage Armbian development Does this tool always verify the burning result by default ('by default' is important since average users don't change default settings)? If not then recommending this tool is a great way to sabotage Armbian development Is this tool Windows only or available on other platforms? If only Windows why should we even mention it? I don't get it why it's so hard to get that a MANDATORY VERIFY after burning is important (unfortunately Etcher users can change the defaults and skip verify -- but fortunately users almost always stay with defaults). Again in big letters since: VERIFY IS IMPORTANT! Personally you can use whatever tool you want. But please stop the attempts to recommend anything else than Etcher. It's kicking us developers into the face since we can not spend our time on improving Armbian but have to deal with reports of 'Armbian fails this or that way' that are in reality just the result of 'burning went wrong'. This thread contains a bunch of examples why burning can fail. The 'average user' reality out there is that they are not aware that burning often fails. They use SD cards that are lying around, they buy counterfeit cards on eBay and Aliexpress, they use crappy card readers and have not the slightest idea why VERIFY is important. So please stop recommending tools that allow them to skip verify. Nice to see that this Win32 tool now allows for an optional verify (optional --> useless since people will skip it and then open up 'bug reports' here as they did in the past prior to the 'Use only Etcher' recommendation). Once they implement this as mandatory and every Windows user uses at least this latest version then this tool could be recommended. But not today. Again: it's not about what people do who consider themselves experienced users or even experts. It's about average users and it's about allowing us to focus on development and not wasting our time trying to hunt bugs down that do not exist since just the result of the 'burning SD cards' sh*t show prior to Etcher.
guidol Posted July 9, 2018 Posted July 9, 2018 5 minutes ago, tkaiser said: Ok, one last time: it's about the AVERAGE USER and THEIR AND OUR TIME. Not about what some 'experts' use and some anecdotes like Etcher always generating kernel panics while Win32DiskImager working flawlessly (haha). Personally you can use whatever tool you want. But please stop the attempts to recommend anything else than Etcher. It's kicking us developers into the face since we can not spend our time on improving Armbian but have to deal with reports of 'Armbian fails this or that way' that are in reality just the result of 'burning went wrong'. OK - in the future I wouldnt recommend something other than etcher to other users, because I didnt want to kick developers into the face (I also didnt want this before) Personally I would call me a 'experienced user" more than a expert or developer - I am mostly a technical admin I think my problem is to estimate a "AVERAGE USER" because many people like you are more advanced than me an only some new users show they are real beginners/noobs. So a "AVERAGE USER" (durschschnittlich) could also be an 'experienced user' like me. Whats for you the representation of a a "AVERAGE USER" ? The time - being here in the forum - I couldnt remember much threads about failed flashes, but more about wrong power supplys and cables (or MicroUSB Ports which you didnt like - and I know why) PS: I never had a kernel-panic with etcher (used it in debian/ubuntu x64 and Windows)
tkaiser Posted July 9, 2018 Posted July 9, 2018 39 minutes ago, guidol said: The time - being here in the forum - I couldnt remember much threads about failed flashes Web search for authentication token manipulation error site:armbian.com shows threads were users failed to burn correctly and the rootfs on the SD card was in such a corrupted state that it has been set to read-only at booting. None of these users was aware that burning went wrong (hardware trouble). They all reported an 'Armbian problem'. The less obvious cases of 'burning went wrong' NEVER talk about failed flashes but about 'Armbian bugs' or even 'Armbian sucks'. Since people are not aware of burning SD cards being such a sh*t show. Often users feel offended when told to use SD cards that are not utter crap (too slow) or told to use another burning tool (that verifies what's going on), then they try Etcher, Etcher reports failure and users think the tool would fail but not their crappy SD card (or reader or whatever). See here, here or here. The symptoms of such soft failures differ depending on whether the SD card is crappy itself or only something went wrong when burning. In the first case users might spot mmc errors in their logs but if only the burning process was faulty then they just have an OS install containing various bit flips which lead to all sorts of strange problems that all just look like software malfunctions (I myself ran into this issue over 2 years ago since back at that time Etcher-CLI didn't exist and I wanted to burn on my Linux build host. Did this with dd, no error messages when burning but weird software behaviour. I waste more than one day on this since I was developing at the same time and was hunting for bugs that did not exist -- since crappy card reader was the culprit creating data corruption while burning -- moving the card reader to the back of the PC to USB ports that were directly connected to the mainboard solved the issue. That day I learned to never ever skip verify) In Armbian we started 2 years ago promoting Etcher and trying to educate our users to only use this software. That helped somewhat and in the meantime Etcher is fortunately the standard recommendation almost everywhere. You should keep in mind that Pine64 folks forked an early Etcher 2.0 beta to provide all OS images only through this tool (called Pine64 Installer) since IIRC 60% or even 70% of all support requests and 'DOA reports' were simply related to users failing to burn an image to SD card.
chwe Posted July 9, 2018 Author Posted July 9, 2018 1 hour ago, guidol said: The time - being here in the forum - I couldnt remember much threads about failed flashes, but more about wrong power supplys and cables (or MicroUSB Ports which you didnt like - and I know why) Crappy power supply is often a way easier to determine.. Does it work better/reliable since you changed to a decent one? Well, there that was probably a crappy PSU related one.. e.g. this one here: could most likely be solved with etcher by reburn the image... I had once the DOGAFU experiment (I'have to search for this crappy SD-Card and make DOGAFU great again with this card). and this one: might be also worth a look, even without following armbians recommendations (testing the SD-Card with h2testw/F3 before), etcher got it that this card is shitty (as you see, the image booted and even survived an update, could be fun to see when it fu*cks up)... This doesn't mean that you shouldn't test your cards anymore! The point is that etcher is one puzzle for setting up a reliable system. 1 hour ago, guidol said: I think my problem is to estimate a "AVERAGE USER" because many people like you are more advanced than me an only some new users show they are real beginners/noobs. doesn't matter, every user should use etcher... Assuming you check an image with 20MB/s, checking around 1.2GB of data 'costs' you one minute. Opening a new thread here with your error needs at least one minute... then you can think about the time you and the one who helps you wastes to debug the issue just to figure out that A: you use a crappy PSU, B: you use a crappy SD-Card C: you didn't gave a fuck about recommendations (e.g. check your card first and use etcher) D: all of them combined I'm a big fan of saving time whenever possible, that's why I use 'crappy' cards during development (at least they're checked, but they're slow). Having 5-6 cards allows me to test multiple images and compare them in case I mess something up... I can also develop for two SBCs in parallel. But those cards are 'known working', they aren't counterfeit they're only slow (at least every of those cards reaches around 500kb/s in 4k blocks). As soon as such a board gets productive, it gets a known good one. In those days this means for me a 32GB SanDisk A1 card cause they are widely available here - saves me once again time, if the card is counterfeit refund is a way easier than with a unknown onlinestore and I can have a look at the packaging to see if it looks fishy.
Recommended Posts