Burn ISO Image to Micro SD Card

[zbinsimen]

Would you please recommend a proper tool to burn ISO and XZ image to Micro SD card? I tried ImgBurn but it doesn't work at all.

[lanefu]

https://docs.armbian.com/User-Guide_Getting-Started/#how-to-prepare-a-sd-card

 

That should get you moving

[jalers]

Why not try the UUkeys ISO Mate , I've tried it , with its help , the iSO Image can be burned to USB drive .

https://www.passmoz.com/burn-iso-image-to-usb-in-3-ways.html

[WarHawk_AVG]

https://www.pendrivelinux.com/

 

It can burn img, and iso

 

[guidol]

for Windows I do like the USB Image Tool (USB-IT) from

https://www.alexpage.de/usb-image-tool/

 

because it will startup much faster than the BIG etcher - and USB-IT is working fine for me since more than 2 years

 

[tkaiser]

On 6/21/2018 at 7:47 AM, jalers said:

UUkeys ISO Mate

 

Does this tool always verify burning results?

 

On 6/27/2018 at 10:42 AM, WarHawk_AVG said:

https://www.pendrivelinux.com/

 

Does this tool always verify burning results?

 

On 6/27/2018 at 10:49 AM, guidol said:

USB Image Tool (USB-IT) from https://www.alexpage.de/usb-image-tool/

 

Does this tool always verify burning results?

 

We had an awful lot of absolutely unnecessary support requests 2 years ago with users failing to burn images correctly (since SD cards were broken or card readers or whatever). When starting to only recommend Etcher this amount of absolutely unnecessary support requests declined drastically.

 

A burning tool that does no verify is a nightmare from a support point of view since unfortunately the average user doesn't get it that a lot of stuff can go wrong when burning SD cards. This problem is the whole reason why resin.io folks developed Etcher in the first place.

 

Recommending any burning tool that does NOT a verify the result by default is a really bad idea.

[guidol]

from my point of view I didnt got an problems because my tools didnt verify the burning of an image.

I did burn many hundred images and when I got problems then because there were other errors or too fresh software.

 

I dont why etcher is 20-50 times bigger than any other burning program?

for verifying it coukd have some MB more....for me its like the "Win10" of the burning programs

 

I got bo problem with twice the time for burning if it does verify, but the startup-time is like starting a VM into Virtualbox - this is my personal opinion.....

[tkaiser]

1 hour ago, guidol said:

I dont why etcher is 20-50 times bigger than any other burning program?

 

Since it's an Electron app (they're platform independent and all somewhat bloated).

 

Anyway: recommending burning tools other than those that do a verify (to my knowledge only Etcher and Hardkernel's Win32DiskImager) is horrible! Inexperienced and first time users suffer from crappy SD cards and card readers and by telling them to use something different than Etcher is wasting their time and ours (since we get complaints about 'Armbian not booting' that are in reality just 'burning went wrong').

[guidol]

1 hour ago, tkaiser said:

first time users suffer from crappy SD cards and card readers and by telling them to use something different than Etcher is wasting their time and ours (since we get complaints about 'Armbian not booting' that are in reality just 'burning went wrong').

OK  here I am at your side! First time users and beginners should use etcher to test their sdcards and reader/writers with etcher to get know their hardware is good and working just fine.

 

My USB 3.0-reader/writer (on USB 2.0)  is a Transcend TS-RDF5 (and is working fine for me) with SanDisk Ultra SDCards

[WarHawk_AVG]

Yeah....almost 80-90% of my issues were due to inadequate/crappy power and cables, and old/crappy SDcards...who woulda thunk

 

Seriously...I owe tkaiser and Igor (and many others) an apology...I thought armbian was the problem (booting issues, locking up, corrupt cards)...it wasn't

[Terblanche]

I have used the following free USB creator tools for years:

https://rufus.akeo.ie/

https://www.top-password.com/iso2disc.html

 

It's worth a try!

[gounthar]

I faced tons of problems last week with Etcher burning Armbian and Raspbian images.
I had a kernel panic each and every time afterwards. With a heavy heart, I switched back to Win32DiskImager and it worked perfectly.
I guess none of these softs is always doing perfect in each and every situation.

[tkaiser]

3 hours ago, Terblanche said:

https://rufus.akeo.ie/

 

Does this tool always verify burning results?

 

3 hours ago, Terblanche said:

https://www.top-password.com/iso2disc.html

 

Does this tool always verify burning results?

 

26 minutes ago, gounthar said:

Win32DiskImager

 

Does this tool always verify burning results?

[Tido]

On 6/27/2018 at 7:18 PM, guidol said:

a Transcend TS-RDF5w

Hoi Guido,

Vielen Dank für den Tipp, sehr preiswert.

 

Since when do you have this device in use?

Did you update the Firmware ?  https://www.transcend-info.com/Support/No-396

 

[gounthar]

2 hours ago, tkaiser said:

 

Does this tool always verify burning results?

 

 

Does this tool always verify burning results?

 

 

Does this tool always verify burning results?

Etcher verified my burns, and they failed. Please get out of this loop.

[tkaiser]

1 hour ago, gounthar said:

Etcher verified my burns, and they failed.

 

Great. Etcher reported something went wrong when burning (already checked your card and card reader?) and the result was as expected:

 

3 hours ago, gounthar said:

I faced tons of problems last week with Etcher burning Armbian and Raspbian images.
I had a kernel panic each and every time afterwards.

 

What's wrong with this?

[guidol]

2 hours ago, Tido said:

Since when do you have this device in use?

Did you update the Firmware ?  https://www.transcend-info.com/Support/No-396

I use them since 2 to 2.5 years without problems
Thanks for the firmware-link, I never thought about a update to a card-reader/writer

Now my 2 reader/writers are up to date!

[tkaiser]

On 7/6/2018 at 12:00 PM, guidol said:

Thanks for the firmware-link, I never thought about a update to a card-reader/writer

 

Why? These things are complex, they have an SDIO interface to access the flash media and an USB controller to present the storage as mass storage device. And of course there's a controller running a software that can be buggy. So why shouldn't be there firmware updates?

 

Since I fear a lot of people still do not get that every burning tool that does not verify burning results is CRAP I just did an experiment. We recently replaced a bunch of crappy Intenso TF cards with SanDisk Ultra A1 at a customer so now I have something crappy to play with. Also involved: a crappy USB SD card reader/writer:

 

 

I put the TF card into the SD card adapter, then the adapter into the USB reader and attach the reader to an USB3 port of my laptop. Try to burn an Armbian image and Etcher reports an error already while burning. This is repeatable with 4 of those crappy 4 GB TF cards (I stopped then testing).

 

Is Etcher the problem? Of course NOT! Trying it also with ddrescue and same situation: ddrescue also already reports an error while burning:

bash-3.2# ddrescue --force /Users/tk/OMV_4_Renegade.img /dev/rdisk2 
GNU ddrescue 1.20
Press Ctrl-C to interrupt
rescued:   434765 kB,   errsize:         0 B,    current rate:   2228 kB/s
   ipos:   434765 kB,    errors:         0,      average rate:  10351 kB/s
   opos:   434765 kB,  run time:         42s,  remaining time:          5m
time since last successful read:          0s
Copying non-tried blocks... Pass 1 (forwards)
ddrescue: Write error: Input/output error

 

So do I have 4 failing SD cards? NOPE! Since when I use my laptop's internal SD card reader (also USB attached BTW) it works with all 4 crappy TF cards:

 

 

Etcher happily reports that burning now succeeded successfully and the same with ddrescue:

bash-3.2# ddrescue --force /Users/tk/OMV_4_Renegade.img /dev/rdisk2 
GNU ddrescue 1.20
Press Ctrl-C to interrupt
rescued:     3904 MB,   errsize:         0 B,    current rate:   8192 kB/s
   ipos:     3904 MB,    errors:         0,      average rate:  10357 kB/s
   opos:     3904 MB,  run time:      6m 17s,  remaining time:         n/a
time since last successful read:          0s
Finished                                     

 

The above external USB card reader/writer does not fail with good SD cards (Samsung EVO/EVO+ or SanDisk Ultra/Extreme/Plus A1) so for whatever reasons it's the combination of crappy SD card and crappy reader.

 

What can we learn from this? Stop using and recommending crappy burning tools that do NOT VERIFY. Win32DiskImager most probably would've written simply garbage with the above combination since it doesn't implement VERIFY (only latest 1.0 version implements an optional AKA useless verify step). And then the user is in trouble since usually minor corruption issues look like software faults later on (that are considered 'Armbian bugs' then, reported as such and wasting our developer time and the user's time too)

 

I ran into this issue 2 years ago with the internal SD card reader/writer of my build PC back then. Images written with dd becoming slightly corrupted over time which resulted in weird software failures and kernel panics. I wasted a day to get the clue that it's related to the card reader being the culprit. I then used the external USB reader/writer shown above which also started to corrupt images weeks later. But only when attached to the USB front ports. When attaching the same reader to the back ports of the PC everything went fine. So it was obviously a simple cabling issue between mainboard and the front USB ports/devices (the internal card reader at the front is also USB attached).

 

Seriously: VERIFY is important. Please don't be stupid and skip this step. Don't be even more stupid and use tools that do not allow to verify burning results.

[gounthar]

2 hours ago, tkaiser said:

 

Great. Etcher reported something went wrong when burning (already checked your card and card reader?) and the result was as expected:

 

 

What's wrong with this?

You got me wrong (my fault). Etcher told me my burns were OK, but they were wrong. They gave me a kernel panic on each card I wrote with Etcher (Raspbian on some devices, Armbian on others). These images were known to work, and not give a kernel panic. I burned the same images on the same cards for the same devices on the same machine with Win32DiskImager, and my SBCs worked like a charm.

Etcher can validate faulty burns.

If you want to speak the latest on that very subject, that's your choice, but to me, you're wrong, deal with it.

[Tido]

1 hour ago, tkaiser said:

I put the TF card into the SD card adapter, then the adapter into the USB reader and attach the reader to an USB3 port of my laptop

Just out of curiosity, if you plug in the Reader first, so it can 'boot'. Then you put in the SDcard.  Same error ?

 

[Igor]

20 minutes ago, gounthar said:

These images were known to work, and not give a kernel panic. I burned the same images on the same cards for the same devices

We always seek for scientific explanation. You will need to add a lot more to support such heretical claims  You can run into a kernel panic even SD card was written properly and some boards are picky about SD card brand/speed. That's nothing unusual. Inadequate powering, on the other hand, can and do cause weird troubles ... which are sometimes hard to explain.

[guidol]

1 hour ago, tkaiser said:

Why? These things are complex, they have an SDIO interface to access the flash media and an USB controller to present the storage as mass storage device. And of course there's a controller running a software that can be buggy. So why shouldn't be there firmware updates?

 

Since I fear a lot of people still do not get that every burning tool that does not verify burning results is CRAP I just did an experiment. We recently replaced a bunch of crappy Intenso TF cards with SanDisk Ultra A1 at a customer so now I have something crappy to play with. Also involved: a crappy USB SD card reader/writer:

 

Seriously: VERIFY is important. Please don't be stupid and skip this step. Don't be even more stupid and use tools that do not allow to verify burning results.

Because of that I didnt use CRAPPY Hardware.
I do buy Hardware (SD-Cards and Reader/Writer) from as good known brands like SanDisk MicroSD-Cards and the Reader/Writer from Transcend (which do build very good Hardware in Cards/Memory-Sticks and Reader/Writers since years) - but this is the first reader/writer with firmware-update.... but thats for me a sign of quality from product/manufacturer

 

I check new cards with the known tools to test that they are fully useable and without errors or capacity problems.

 

I do use Cards Reader/Writers with ARM-Mini-computers since 2010 where I did use it for the GlobaleScale Sheevaplug or the Linksys NSLU2.
https://www.heise.de/newsticker/meldung/Steckdosen-Computer-jetzt-auch-in-Deutschland-erhaeltlich-Update-929742.html
http://www.linux-magazin.de/ausgaben/2010/06/nette-linux-schnecke/

Since then I didnt got problems with verify on my hardware which was a little more expensive then the CRAPPY cheap hardware.

I also did try some cheap reader/writers and with some used OrangePi One I did some NoName SD-Cards.....but I didnt use them because I could see and feel the problems while flashing images..... and my feeling seems to confirm the reality

 

Intenso-Card are CRAP like their Drives, because they only put their name on it -  you never know what you did get - and never the same.
Transcend is like SanDisk and they will produce their own products.

 

I would suggest to use etcher and verify with cheap hardware (or beginners to be sure their hardware hasnt any fault) - or if you getting problem with good hardware (old SanDisk Cards).

 

 

 

 

[guidol]

56 minutes ago, gounthar said:

Etcher can validate faulty burns.

Are you sure validate was checked in the settings?

Is validate as default checked in etcher?

No-One should think oneself safe while using etcher - and maybe validate isnt checked

[tkaiser]

On 7/6/2018 at 2:49 PM, guidol said:

I also did try some cheap reader/writers and with some used OrangePi One I did some NoName SD-Cards.....but I didnt use them because I could see and feel the problems while flashing images...

 

Feelings and beliefs? Seriously?

 

A burning tool's job is to flash an image without any modifications to an SD card or eMMC. As not only I outlined there exist a couple of reasons why this can fail. It's not just related to crappy SD cards or crappy card readers/writers but as I explained above even the USB port you plug the thing into can make a difference (for example USB front ports suffering from interference problems when cables between mainboard and ports are not properly shielded).

 

A basic IT fundamental is to not stupidly trust into data traveling from source to destination unaltered. Almost every protocol we use nowadays implements on the fly checking for data integrity. For the simple reason that trusting into sending data from A to B and assuming that everything is fine at the destination is PLAIN STUPID. For example when transfering data between an SDIO, SATA or SAS host controller and flash/disk controller Cyclic Redundancy Check (CRC) is used to immediately verify data integrity and if data has been altered on its way the destination asks for a retransmit. Same is implemented in networking protocols (see TCP/IP) and almost everywhere else a verify happens on the fly. Since it's PLAIN STUPID to believe data corruption wouldn't occur. It occurs all the time and that's why engineers put CRC or stronger data integrity verify mechanisms into almost every protocol used today.

 

Unfortunately sometimes the CRC mechanism is rather weak (so that data corruption when happenend generates a correct CRC and as such gets undetected) and unfortunately it's not implemented everywhere. Especially when it's about cheap consumer crap (SD cards and USB card readers) we can't trust into the results.

 

So what do we need when we can't get 'on the fly' verify when burning SD cards? We need verify as an additional step. Why? Since it's PLAIN STUPID to trust into data integrity especially with such a mess like cheap card readers/writers and cheap and/or fake SD cards.

 

The only reason Etcher has been developed in the first place was due to this: an insame amount of undetected data corruption when burning SD cards or thumb drives due to shitty tools that do not verify (Etcher has been developed by resin.io folks who make their money with helping their customers rolling out and updating software on fleets of IoT devices. Their main problem years ago was unsatisfied customers since they failed to burn the resin.io software to SD cards. Since all available tools were crap due to skipping the necessary verify step which is PLAIN STUPID. Etcher changed this!)

 

For anyone recommending anything else than Etcher: Thank you a lot! You ensure that developers like us here at Armbian can not focus on improving Armbian but have to deal with 'bug reports' due to people failing to burn SD cards. Instead of spending time on development we have to waste our time on 'bugs' that aren't bugs but just the result of users been encouraged to use crappy tools. Thank you for wasting our and our users' time! Well done!

 

[gounthar]

1 hour ago, guidol said:

Are you sure validate was checked in the settings?

Is validate as default checked in etcher?

No-One should think oneself safe while using etcher - and maybe validate isnt checked

Yes, "Validate" was checked, as always when I use Etcher.

[chwe]

1 hour ago, tkaiser said:

For anyone recommending anything else than Etcher: Thank you a lot! You ensure that developers like us here at Armbian can not focus on improving Armbian but have to deal with 'bug reports' due to people failing to burn SD cards. Instead of spending time on development we have to waste our time on 'bugs' that aren't bugs but just the result of users been encouraged to use crappy tools. Thank you for wasting our and our users' time! Well done!

 

That's why the four (five) questions:

• Did you test the SD-Card with h2testw/f3?
• Did you use etcher?
• Describe us the powering situation?
• please report 'sudo armbianmonitor -u'?
• (show us the serial output during boot)

come up on more or less every question which sounds a bit fishy. 

1 hour ago, tkaiser said:

Feelings and beliefs? Seriously?

 

Feelings and beliefs is the way people solve ~90% of their problems (90% was randomly chosen by feelings )... Similar to 'works for me' and 'I do *random thing* since 20 years so don't say that my approach is outdated since 19 years!!!' 

 

2 hours ago, guidol said:

I would suggest to use etcher and verify with cheap hardware (or beginners to be sure their hardware hasnt any fault) - or if you getting problem with good hardware (old SanDisk Cards).

 

I would suggest it with every hardware. It's just a question of time. Do you figure out immediately that your problem is related to 'faulty SD-Card' when it happens? When not, what needs more time? The few seconds each time to start up etcher for burning an image or the time to figure out that your card was corrupted since beginning (including the time you wasted to set up your system on top of an error you could avoid by using an appropriate tool)? If yes, fine do it. But don't expect that others are willing to look into problems you have when you don't follow the recommendations. 

My SD-Cards for development aren't perfect (e.g. I use some old slow 4GB cards during testing). Mostly cause my best SD-Cards (SanDisk A1, known fast EVOs) are in the SBCs which run productive. My 'feelings' say that the BPi-R2 isn't that picky when it comes to SD-Cards. It 'seems' that the board works fine with them. Obviously, this can go wrong and then I have to blame my self for wasting my time. But cause this is during development and it would mostly waste my time and not others I'm fine with. During development, I burn a bunch of images but even then it's IMO not worth to switch to an alternative writer than Etcher (even when it uses more time due to crappy old SD-Cards), simply cause my development is also driven by 'feelings'. So, when a test-image doesn't work due to 'burn image went wrong' I may come to the wrong conclusion. This might drive my development in the wrong direction only cause I saved 2-3mins by burning an Image. Armbian shrinks the image to an appropriate size, you don't have those 8GB garbage Images as other 'distributions' have. So burning and validating took anyway less time. Is it worth to save some minutes more by use a 'dumb' image writer? IMO no. 

I've a dumb bash script which checks my SD-Cards on a OPi Zero connected via a USB card reader. What it does is simple: It mounts my card, formates it, tests it with F3 and when it succeeds the GPIO with the green LED is toggled if it fails, the GPIO with the red LED is toggled. So I don't even need 'a real computer' during development to check my SD cards regularly to 'ensure' they're still okay... 

 

2 hours ago, guidol said:

Because of that I didnt use CRAPPY Hardware.

'Everybody' believes that he doesn't use crappy hardware...   Read through this one: https://forum.armbian.com/forum/31-sd-card-and-power-supply/

Most of them thought in the beginning their hardware was appropriate.. Sometimes hours of nailing down the problem showed that they were wrong. 

 

3 hours ago, gounthar said:

You got me wrong (my fault). Etcher told me my burns were OK, but they were wrong. They gave me a kernel panic on each card I wrote with Etcher (Raspbian on some devices, Armbian on others). These images were known to work, and not give a kernel panic. I burned the same images on the same cards for the same devices on the same machine with Win32DiskImager, and my SBCs worked like a charm.

Etcher can validate faulty burns.

That's what bug reports are for.  I don't know how the etcher.io team reacts (simply cause I never had a reason to report a bug in their repo). But if you can show them that the same setup (e.g. same Image, same SD-Card, same card writer etc.) writes a working Image with win32DiskImager but not with etcher, they may be interested in knowing that.

 

BTW @tkaiser etcher also provides a CLI tool, at the moment marked as experimental (https://etcher.io/cli/). Do you have any experience with it? Is it worth a try? I've some automated buildstuff in mind (e.g. that my freshly compiled image gets written to an SD-Card automatically after build and I can go for a coffee and everything is prepared to test when I come back). 

[Tido]

12 hours ago, gounthar said:

Etcher verified my burns, and they failed.

by the way, a couple months ago - a version of Etcher had some problems (cannot find the thread right now). So I didn't update - use still an old version (1.2.1) on my Ubuntu Mate 17.10 - works great.

The only Electron App I use - because of that feature to verify the write process.

 

[tkaiser]

1 hour ago, chwe said:

BTW @tkaiser etcher also provides a CLI tool, at the moment marked as experimental (https://etcher.io/cli/). Do you have any experience with it? Is it worth a try?

 

Sure, works like a charm (though they introduced a bug on macOS with 1.4.x version which seems easy to fix):

bash-3.2# /opt/etcher-cli-v131/etcher -y -d /dev/disk3 /Users/tk/OMV_4_Renegade.img
Flashing [==                      ] 6% eta 5m46s 

And then

bash-3.2# /opt/etcher-cli-v131/etcher -y -d /dev/disk3 /Users/tk/OMV_4_Renegade.img
Flashing [========================] 100% eta 0s  
Validating [==                      ] 6% eta 2m11s

You would check the exit code when running unattended:

Exit codes:
  0 - Success
  1 - General Error
  2 - Validation Error
  3 - Cancelled

 

1 hour ago, chwe said:

That's what bug reports are for.  I don't know how the etcher.io team reacts (simply cause I never had a reason to report a bug in their repo)

 

They get tons of stupid 'bug reports' but always try to be polite and support the submitters and other participants even it's just coaching clueless Windows users who think Etcher has destroyed their SD card just due to their stupid Windows installations not able to deal with anything else than Microsoft developed filesystems (they burn Raspbian and complain later that their 16 GB card shrinked to 128 MB since Raspberry Pis need this small FAT partition to load the primary OS called ThreadX from it and Explorer and other Windows tools only display the FAT partition since not able to cope with ext4 or more than the first partition on removable media anyway)

[chwe]

21 hours ago, tkaiser said:

You would check the exit code when running unattended:

Exit codes:
  0 - Success
  1 - General Error
  2 - Validation Error
  3 - Cancelled

 

might be an interesting feature for my buildsystem/script.. Something like burnToSD="yes"  Hmm I'll have a look if I'm able to implement it in a proper way... Do you think this might be an useful feature? 

 

21 hours ago, tkaiser said:

Explorer and other Windows tools only display the FAT partition since not able to cope with ext4 or more than the first partition on removable media anyway

There are some drivers so that windows is able to deal with ext4. It doesn't show up as removable media after its and it has the potential do give you a nice bluescreen when you remove it (I somehow fail to remove this driver from my windows notebook, that's why it might be a little bit corrupted due to multiple bluescreens when I stick in an armbian SD-Card before remove everything on it before).. 

 

21 hours ago, tkaiser said:

They get tons of stupid 'bug reports' but always try to be polite and support the submitters and other participants even it's just coaching clueless Windows users

 nice to see when a github issue tracker is actively maintained and when they stayed calmed even when they're floated with stuff which isn't related to their product. 

 

Edit: sorry @Igor we both messed around with the thread at the same time... 

[tkaiser]

On 7/6/2018 at 6:43 PM, chwe said:

There are some drivers so that windows is able to deal with ext4.

 

This is 100% irrelevant just like some people reporting they never had trouble with Win32DiskImager or dd!

 

It's about the average user and expectations. And the average user runs Windows for whatever reasons and has no clue about Windows being crippled by design when it's about handling removable media and 'foreign' filesystems.

 

And the average user also has the naive assumption that burning to SD cards always works, that crappy/counterfeit SD cards do not exist and that 'transmission problems' caused by card readers or USB ports also do not exist. That's why it's so important to ONLY RECOMMEND ETCHER all the time.