 |
| My pi! |
So, downloaded Raspbian “wheezy” (
link). 493.6 MB.
Check the checksum in an xterm:
shasum ./2013-02-09-wheezy-raspbian.zip
b4375dc9d140e6e48e0406f96dead3601fac6c81 ./2013-02-09-wheezy-raspbian.zip
Which is the same as the published checksum
SHA-1 Checksum: b4375dc9d140e6e48e0406f96dead3601fac6c81
and unpack the file (2013-02-09-wheezy-raspbian.zip), again, from the xterm:
unzip ./2013-02-09-wheezy-raspbian.zip
Archive: ./2013-02-09-wheezy-raspbian.zip
inflating: 2013-02-09-wheezy-raspbian.img
On the Mac I followed elinux.org's instructions for "Copying an image to a 4GB SD card in Mac OS X (command line)". They seemed to be the most accurate and complete (
link).
The following pointers apply to a computer with an external USB SD card reader. I my case I used the Puremedia SD USB Card Reader product.
Inferring the device id for the SD reader:
From 'About this Mac' click on System Report. Select Hardware>USB. One of the USB High-Speed Bus entries will reflect the details of whatever SD card is currently loaded. Eject and reinsert a couple of times, reloading the System Report between each state to verify that you are referring to the correct entry. This is important because you can wipe hard disks with incorrect disk duplication commands.
In my case I had an SD card with the following details:
Volumes:
NO NAME:
Capacity:
78.6 MB (78,643,200 bytes)
Available:
48.3 MB (48,336,896 bytes)
Writable:
Yes
File System:
MS-DOS FAT32
BSD Name:
disk2s1
Mount Point:
/Volumes/NO NAME
Content:
Windows_FAT_32
disk2s2:
Capacity:
1.67 GB (1,667,235,840 bytes)
BSD Name:
disk2s2
Content:
Linux
disk2s3:
Capacity:
200.3 MB (200,278,016 bytes)
BSD Name:
disk2s3
Content:
Linux_Swap
What this means, in MY CASE ONLY, that the device name (and therefore the 'raw device name') is disk2 (or rdisk2 for its raw equivalent). In this particular case the BSD names (e.g. disk2s1, disk2s2, disk2s3) are volumes or partitions on the SD card I was using. They will probably all disappear after following the disk image copying instructions. The reason I had these extra volumes on my SD card is that I was practicing disk imaging/partitioning on it.
I replicated the process from an xterm using the df -h command. Same result.
So starting with the SD card inserted and mounted, unmount it using sudo diskutil unmount /dev/disk2s1 (my case only). The icon will also disappear from the desktop confirming this step was successful.
The last step is to write the raspbian image file to the raw SD card device as identified above, replacing disk2s1 with rdisk2:
sudo dd bs=1m if=./2013-02-09-wheezy-raspbian.img of=/dev/rdisk2
After anywhere from 3 to 5 minutes the disk image write finishes. The xterm looked like this:
1850+0 records in
1850+0 records out
1939865600 bytes transferred in 226.104953 secs (8579492 bytes/sec)
And there's a shiny new disk labelled 'Untitled' on the desktop. At first impression it looks like your 4G sized disk has tragically shrunk to 58.7 MB. The reason is that the SD disk now has a Linux swap partition and a Linux file system partition occupying the available space. The good news is that most of the slack space can be recovered the first time you load this SD card on the Raspberry Pi via one of the Pi configurator (raspi-config) options to reallocate the space from the linux partition to the FAT32 partition.
I plan to duplicate the process on Windows to verify the approach.
