Burn ISO Image to Micro SD Card

[bamksever]

On 7/6/2018 at 10:11 AM, Terblanche said:

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

https://rufus.akeo.ie/

https://www.recoverywindowspassword.com/burn-iso-image-to-usb-drive.html

 

It's worth a try!

I tested Rufus before , the Rufus program is complicated , and i don't think it works for people who don't have the experience .

 

Edited August 22, 2018 by bamksever

[sfx2000]

On 7/6/2018 at 9:58 AM, tkaiser said:

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.

 

Completely agree...

 

Etcher does a great job - and the verification ensures that one has a good write to the card...

 

When in doubt - one can use the SDCard Formatter Util (Win/Mac) to "refresh" the card prior to writing...

 

https://www.sdcard.org/downloads/formatter_4/

 

If it fails, then check either the card, or the reader...

[Emailleray]

On 8/22/2018 at 2:55 PM, bamksever said:

I tested Rufus before , the Rufus program is complicated , and i don't think it works for people who don't have the experience .

 

As i tried , the Rufus is very unstable ,sometime it works on Windows 7 computer , but sometime it doesn't work on Windows 10 computer .

I prefer this one : https://www.iseepassword.com/how-to-burn-iso-to-usb-drive.html

[guidol]

4 hours ago, Emailleray said:

As i tried , the Rufus is very unstable ,sometime it works on Windows 7 computer , but sometime it doesn't work on Windows 10 computer .

Did you use the newest version?: 

Version 3.3 (2018.09.17) [BUGFIX RELEASE]

 

I used the portable version without problems under Windows 10:
https://github.com/pbatard/rufus/releases/download/v3.3/rufus-3.3p.exe

[chwe]

On 11/23/2018 at 7:49 AM, Emailleray said:

I prefer this one : https://www.iseepassword.com/how-to-burn-iso-to-usb-drive.html

you mean Method 2: How to Burn ISO Image to USB Drive Using RMPrepUSB

Quote

Files are often corrupted or not burned properly many times.

 

sounds exactly what people want...

 

or Method 1: Burn ISO Image to USB Drive with WizISO?

which doesn't mention disk verification anywhere? Doesn't make sense too.

[Tido]

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

a Transcend TS-RDF5 (and is working fine for me)

A little update on that topic, in c't Magazin I read about two others which are low in price and fast:

Kingston MobileLite G4 UHS-I

Hama USB 3.0 UHS-II

 

[Tido]

because it is an electron programm.

 

[haajee]

I used for a longer time not Samsung ProEndurance SD cards and the quality looks a lot higher. Not even 1 Samsung card is broken instead of a few Sandisk cards... I read on another Raspi forum that Samsung cards functions the best. So it looks it does! Maybe a tip when you doubt to choose a SD brand.

[Igor]

16 hours ago, haajee said:

instead of a few Sandisk cards

 

I have mainly Samsung EVO and Sandisks Extreme A1 around. Due to the nature of our work I am doing nasty stuff to them and they also (Samsung) eventually break

Until you don't go out with extensive testing with few hundred pcs and you are 100% sure they are not fake, its hard to say anything. Fakes come in the same package sold by renown sellers ... this whole SD card saga is more related to the luck then anything. In last few years I already throw away a pile of them.

[LdB]

The issue with burning images and getting the panic throw out from Raspberry Pi images is because the SD-CARD used and the image size do not match they differ by a small amount usually just a few megabytes on an 4, 8 or 16GB SDcard.  Does not matter which image software you use  and if you verify it or not unless they software fixes the partition up to match the card size it will throw a panic.

 

The latest version of Win32DiskImager will warn you the image size is different to the card size and allows you to continue but the produced image will panic.

 

The only way around the issue is using a partitioning tool to shorten the last partition back by say 500Mb so that the image size is guaranteed to be smaller than any card of the supposed size. Then image that card and it will work on any card of the supposed GB size.

[haajee]

On 8/5/2019 at 8:28 AM, Igor said:

 

I have mainly Samsung EVO and Sandisks Extreme A1 around. Due to the nature of our work I am doing nasty stuff to them and they also (Samsung) eventually break

Until you don't go out with extensive testing with few hundred pcs and you are 100% sure they are not fake, its hard to say anything. Fakes come in the same package sold by renown sellers ... this whole SD card saga is more related to the luck then anything. In last few years I already throw away a pile of them.

 

Oh i think you use the SD cards indeed al little bit (mean a lot!!) more intensive then i should do. Otherwise is in the dashcam's my idea also that the Samsung's has a longer lifetime than the Sandisk.

 

But i agree with you: the only correct way to check it is to buy a lot and do all the same things and see how long the SD cards live. Offcourse with originals. But even then could there be a bad batch of a brand... 'SD cards are consumable items' do i read somewhere on the internet. And i think we should agree.

 

Btw: is the lifetime of a onboard eMMC better than a SD card?

[CK Gan]

Hi all,

 

newbee to Armbian here.

 

Have anyone burned img on MacOS and boot OPI4 LTS successfully?

 

My situation is when I burned the img on MacOS (tried using dd, elenaecther, or RPI4 imager), once the write and verify is completed, the sdcard cannot be read by MacOS. When it is used to boot OPI4, nothing came up.

 

I have a few sdcards lying around which works fine for RPI4. I can basically read the sdcard when it is imaged with RPI img file but not the same case after burning the Armbian or OPI4 stocked img files. Could this be specific to these img files on macOS? I do not have windows to try out. The img sha and asc verified.

 

This is what is shown on the diskutil command eventhough macOS cannot read it:

 

/dev/disk3 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:     FDisk_partition_scheme                        *15.9 GB    disk3
   1:                      Linux ⁨⁩                        1.6 GB     disk3s1
                    (free space)                         14.3 GB    -

 

I tried a serial connection to OPI4 but what I seen is garbage output ... tried many different baud rate also same. So basically I have no clue what could be wrong.

 

This is what I see from the CoolTerm output.

 

..ˇk.Ÿ®Û¡™ˇüùˇœ¯Úˇˇ˘flüü∫Ú˛ÂüˇÈ±
ºˇˇ˛ˇˇÙÛˇˇí˝œˇ¸ˇˇ\ˇx„˘¸ˇn√.˚z∑∞˛≠ˇˇı˙Óˇ8fløÔøˇ=ʘo]”˛ıˇˇˇ˛Òˇ˛ˇ˛¸ˇÙ_^ν3˙ˇ˛ôˇÓ˚ˇ˝ˇ~øØÙˇˇ£·˚–≤Îtˇˇ˛¸ˇˇ˛˛ˇˇfl..Sˇùdˇˇg®ˇˇƒÙˆ¸~ø˛è˛˛ˇˇ‘ˇ¬ê∂˝ˇ¸ˇ¸ˇ˛ˇˆ˛¬o‘üΩÂÆ˛ˇø˛Ëˇyzøˇœ~ˆ˝˛Ê˙˚œ˛∫>ˇˇˇ˛˛ÒˇÁ˛˛Û˛˛¸Á˛˝ˇc¯⁄.¯Ùˇ7}¶∫€?˛Ωˇˇˇ¸˚˙ˡúøflæˇ≥Ú¸˛IÁÛÎÔÇ\˛˛¸ˆˇˇÛa¸ˇŒˇ˛¸ˇ¸Ì˚ˆ¸„ˇˇÌ¸ÿβ≈6˛ºˇ¸˙ı¸ˇ˛~flˇfi˙ˇˇ.Ú˛Àß¡8ˇ˛˛˛¸ˇ˛ˇ¸¸fl˙ˇˇ˛˛¸˝¸ˇÜ¯Ú¸¸¸˜flv~ˇ∑ˇÓæ!˝‹˙ˇˇÁ˛œø˛ˇ¸˛ƒ˘fiˇ˚Ùˇˇ˛ÛˇÚ˛˛ˇ$ˇˇÔ˛ˇ˝ˇ‚¿.˘ˇ¯˛¥ˆˆ«.Îø˛ÎͲ˛˘¸ˇæûøˇñ˛ˇˇä¯˘¿.z˛ˇ˙¯ı˛¸˚.˙˛ˇÛˇ˛¸¸¥˘.˘ˇˇ˛ˇß‹{Õflˇ§ˇ˝ˇ‰Œœû˛.€ˇ˛ˇ&˜˝√õà˝ˇˇˇ˛ˇˇˇ˛˚¸]˛ˇˇˇˇ¸˜˛.éˆˇˇˇ˜˚fl≠ù.œÀ˛Ù˙˙ˇ˝wfl˛flˇΩ˛x˚ÛrflÛu˛ˇ¯¯ˇ˛ˇ˛ˆ\˚ˇ„ˇˇ¸˛¸.˛v‰Ò˚ˇˇˇ?.ªÙ«q∫ˆˇˆflˇˇ˛ı˘ˇ˝˛üœfl+˛Ï˙ü§ó˝ˇ¸˛ˇ¯ˇˇˇ˛˘¸é˛˛˛¸ˇ-¯A‰˛¸ˇ

Baudrate: 1500000
Data bits: 8
Parity: none
Stop Bits: 1
Flow Control: off 

 

I also try to mount the img file in macOS but seems got problem. This same situation happens to focal version.

 

sudo hdiutil mount Armbian_22.02.1_Orangepi4_bullseye_current_5.15.25.img
hdiutil: mount failed - no mountable file systems

 

Any idea?

 

please help and thank you very much.

[MacBreaker]

For writing on MacOS, is use usbimager

 

But read carefully these hints:

 

Quote

MacOSX: 10.14 an up: go to "System Preferences", "Security & Privacy" and "Privacy". Add USBImager to the list of "Full Disk Access". Alternatively run from a Terminal as sudo /Applications/USBImager.app/Contents/MacOS/usbimager (this latter is the only way under 10.13).

 

and it works..

 

Markus

[alidaf]

I have the same problem but usbimager doesn't work either. I've tried Etcher, Raspberry Pi Imager and usbimager and they all result in the card being unreadable by MacOS. I can flash Raspbian, the BTT version from their site (outdated) but not Armbian, specifically 24.2.3 Bookworm Minimal.

[SteeMan]

@alidaf what build are you trying to image?  Why do you expect a Linux image to be readable on macros?  Does the SD card work on the target sbc?

[alidaf]

@SteeMan I'm trying to image the BTT version for Klipper. All linux images I have flashed using RPI imager since it has been available (Debian, Raspbian, TinyCoreLinux, Ubuntu and a number of smaller distros) have all been readable after burning. The SD card does work but I had to connect it to a TV, LAN and keyboard to configure the wifi settings. This is problematic due to TV overscan making the edges of the display not visible and some of the menu selection numbers not being visible. RPi imager handles some settings such as user, wifi & ssh automatically for some distros but in other cases the config files can be edited by hand after burning, which is why I would have preferred the card to be readable.

[SteeMan]

I'm assuming the image is using an ext4 filesystem, and macos isn't able to read a Linux ext4 filesystem.  I'f you were to use the SD card on any Linux box it should be readable.  Or install ext4 support on your Mac.

[bedna]

On 3/11/2024 at 4:32 PM, alidaf said:

RPI imager

 

Necro thread, but wanted to clarify since not mentioned.

The raspberry pi imager does way more than just "write the img to the sd card". It is aimed for use with rpiOS not "any img file".

 

Quote

Firstly, Raspberry Pi Imager downloads a .JSON file from our website with a list of all current download options, ensuring you are always installing the most up-to-date version.

Once you’ve selected an operating system from the available options, the utility reads the relevant file directly from our website and writes it straight to the SD card.

Use something other than that.

Edited May 9 by bedna

[Dantes]

Hi fella's

 

Well I think this is worth updating the #how-to-prepare-a-sd-card page with an extra bullet point pointing to: https://www.grc.com/validrive.htm.

This freeware tool detects fraudulent USB mass storage devices. The page explains it in more detail.

 

 

[Dantes]

Hello,

 

Another point I would like to make is that all recommended tools to write sdcards are not in Armbian. So I would hereby formally  request "usbimager" as an Armbian  package since it was the only one I saw with source code available.

 

That being said, I found myself being locked out as an arm64 only user. All packages are either for MAC or WIN, and if they are for Linux they are x86/x64. So what can you do ?

 

Step 1. Install packages:

$ apt install pv xz-utils

 

Step 2. Verify checksum

$ sha256sum -c armbian.img.xz.sha
amrbian.img.xz: OK

 

Step 3. Unmount sdcard: (very important! to avoid corruption)

$ umount /dev/sdcard*
umount: /dev/sdcard: not mounted.

 

Step 4.  Write image to sdcard

$ pv armbian.img.xz | xzcat | sudo dd bs=10M oflag=sync of=/dev/sdcard
[sudo] password for test:
1,31GiB 0:01:54 [11,6MiB/s] [===========================================>] 100%            
0+867065 records in
0+867065 records out
7256145920 bytes (7,3 GB, 6,8 GiB) copied, 113,024 s, 64,2 MB/s

 

Step 5. Verify image from sdcard (--size=bytes copied from step 4.)

$ pv --stop-at-size --size=7256145920 /dev/sdcard | sha256sum
1,31GiB 0:01:43 [11,9MiB/s] [===========================================>] 100%
05ea4603da3c5f5517f6e3f83b8bc456d31e299ac97f564e77a49487f93e5f1b  -

 

Step 6. Check if the hash matches

$ cat armbian.img.sha
05ea4603da3c5f5517f6e3f83b8bc456d31e299ac97f564e77a49487f93e5f1b *armbian.img.xz

 

My 2 cents

Edited August 29 by Dantes
forgot step to unmount sdcard

[Dantes]

Step 6. is incorrect, this must be:

$ xzcat armbian.img.xz | sha256sum
05ea4603da3c5f5517f6e3f83b8bc456d31e299ac97f564e77a49487f93e5f1b *-

(the checksum from armbian.img.sha is still in its compressed form while the sdcard is obviously written uncompressed)