Actually Writing the Image to Disk

Ok the time has come to actually write this sucker to the disk. If you remember, we are going to do this using dd, and we’re using dd (a) because we’re cool and (b) because the image doesn’t just contain the files but also the MBR, partitions, and filesystems. Because of this we need a way to access the disk at low level.

On Linux, low level access to devices is provided by the /dev directory. Here you will find your hardware represented as files that you can read from and write to (if it makes logical sense to do so). You will also find in here some virtual pieces of hardware that you might want to have a look at. Some of note are /dev/zero, a device that will give you a constant stream of zeros if you try to read data from it (that is, it will give a constant stream of binary 0, the null character, not the character 0 which is represented by the binary number 48, which can be a bit counter intuitive) and /dev/null, a digital oubliette, which makes any data you write to it vanish.

By default, ordinary users can’t access a lot of these files, as this would pose both a security risk, as reading directly from a disk would enable you to bypass system security, and a risk of someone accidentally screwing up your system by deleting something they shouldn’t, so when we write directly to the SD card, we are going to be using the sudo command to give us permission to do so. Now, be careful. If you make a typo, you can destroy all the data on your computer! Who thought copying a file could be so exciting?

So the first thing to do is fire up a terminal. If you haven’t changed any of unity’s default shortcuts, ctrl-alt-t will fire up a terminal. Add it to the launcher permanently whilst your about it by right clicking on it in the launcher and selecting lock to launcher. We’re going to be using the terminal a lot, cause that’s how we roll.

Now you’ve got your terminal up, have a quick look in the /dev directory to get yourself acclimatised by running ls /dev. The first thing you’ll probably notice is that quite a lot of things in there have odd names (not to mention the “ls” command itself and the /dev directory). This is because, when these names were standardised upon, space was at a premium, so they were abbreviated (“ls” is short for “list” and “dev” is short for “devices” in case you were wondering.)

Oh, before we continue, I’d better mention the forward slash, “/”, that comes before “dev”. This is known as a directory separator and is how you tell the computer that one directory is inside another. In the case of “/dev”, it isn’t inside any directory, it is a top level directory, and is therefore preceded only by a forward slash. In the case of the “null” device we talked about earlier, it resides in the “/dev” directory, so when we write it, we separate it from “/dev” with a forward slash: “/dev/null”.

Now, you my well wonder where you’ll find your SD card in amongst the rest of the contents of “/dev”. As its exact location depends somewhat on what other hardware you have in your computer, the best way to find it is to take a quick look at one of the log files. So you don’t have to scroll about trying to find the entry in the log file, if the SD card is already inserted, take it out it, wait a couple of seconds for ubuntu to unmount it, and then push it back in. If it isn’t inserted, just push it in. This will cause Ubuntu to auto-monut the SD card and (unless you have changed the defaults) also open up a new nautilus window to show you what is on it. Now would be a good time to make sure you don’t have anything on the card you want to keep, as all the data will be lost when you copy the raspbian image onto it. The close the nautilus window. Ok, now to see where in the /dev/ directory our SD card ended up.

The log we are going to check is the device driver message log or dmesg for short. This is a handy log that stores the output of the various devices on your computer. It is often a good place to start if something isn’t working as would expect before delving into the more specific logs that are store in “/var/log”. To access the dmesg log you simply type dmesg. Rather a lot of information about everything that has happened since the computer was booted will scroll past you, which you can have look at if you’re interested, but what we specifically want to see is the last few entries that refer to our SD card we just inserted. Here is what I get:

Here we can see that the mmc driver has found a new SD card (in this case a high capacity SD card, a SDHC card), that it has called it mmcblk0 and that it has two partitions (p1 and p2) on it. If you’re using a brand new disk you’ll probably only have one partition, but if you’re repurposing an old one it might have anything on it (but hopefully nothing you want to keep as it is all going to be deleted!)

The first thing to do is to unmount the two partitions that were just auto-mounted, just in case the computer tries to read or write from them whilst we are monkeying about with the disk. So at the command prompt, type umount followed by the name of the partition you want to unmount (no one knows why the umount command isn’t called unmount). If umount completes succesfully, like most commands it will be eeirly silent. It’ll only tell you if something goes wrong.

Right, getting back to the /dev directory, we have seen that my SD card can be found in /dev/mmcblk0 (and that the first partition will /dev/mmcblk0p1 and the second will be /dev/mmcblk0p1). Now, and this is important, just because this is the name of the device on my computer, doesn’t mean it will be the name of the device on yours, especially if you have another removable device plugged in! Make sure you check, or you risk losing all your data. One simple way to check you’ve got the right device is to remove the SD card and check that the device files vanish too.

So, we are almost ready to write this sucker to the SD card. First though, we’d better just check that the device files are there as we expect them to be. Use “ls” again to do this. Above, you can see I used what is called a wildcard in my command, the “*”, to limit the amount of information output by “ls”. This particular wildcard will match any number of any character. That is to say that ls /dev/* would match every file in the /dev directory, whilst ls /dev/a* would match everything in the /dev directory that’s name began with a lower-case “a” and so on. In my case, I used it to macth only those things that began with “mmc”.

Now you’ve done that and are sure of the device file for your SD card, we just need to decompress the image file we downloaded (nb. since starting these posts a new version of the image file has been released so from now on I’m using the 2013-02-09 version). Now the adventurous amongst you might want to decompress the image file on the fly (hint, you want to pipe the output of the unzip program into input of dd), but I think the rest of us have had enough excitement for one day so will just decompress the image file first. To do this you just use the unzip program with the path to the downloaded zipped image file as below (by default, unzip unzips the file into the directory you are currently in), and then it is the moment of truth.

dd takes a few arguments that we are going to use: “if”, which stands for “input file” (the image we downloaded); “of”, which stands for “output file” (the SD card device file); and “bs” which stands for “block size” and represents how big a chunk of the file will write in one go. The “bs” argument isn’t really needed, it just speeds things up a little. The syntax of dd’s options is a little unusual: usually commands have the form –option=value or -option value, but dd uses option=value. It is just one of those things. Anyway substitute the correct values for your system, remember this might take a while to complete and that silence means it is working and not finding any errors, and here we go…

Series Navigation<< File SystemsFinding Your Pi on the Network >>

3 Replies to “Actually Writing the Image to Disk”

  1. Hi Robert, Thanks for the blog! I love your writing. I have installed Raspian a dozen times, but have never thought of reverse SSH into it. I enjoyed your insights into zero and null. Keep up the good work! Edward

Leave a Reply

Your email address will not be published. Required fields are marked *