Now that we have the base image downloaded, we need to write it onto an SD card and try to boot the Raspberry Pi. Again, if you're not using Linux, you'll have to figure out an equivalent method to write the image to the SD card.
Writing the image to the card is fairly straightforward. We'll uncompress the image and write it to the SD card on the fly. This is where we'll start benchmarking. We'll want to know how well these SD cards can perform later when we start testing file systems. The SD cards I'm using are SDHC C10 (Class 10) cards that are supposed to have a minimum sequential write speed on 10MB/s. You can buy faster cards, but the C10 cards are reasonably priced and should be fast enough for our needs. If we reuse them in other devices, they should be plenty fast enough for just about everything. Before you spend extra money on fast SD cards, ask yourself if your devices can really write at the higher speeds, and if they really need to write that fast.
Plug your SD card into your system, using whatever means is available (built-in SD card slot, USB card reader, etc.). Finding the exact device can sometimes be a bit of a challenge. You should get a notification in the kernel message buffer that shows the device inserted. You can check the kernel messages with the dmesg command. You should pipe this command to tail to get just the most recent messages. Here's what the messages look like on my laptop that has a built-in card reader:
shikoku::gpike> dmesg | tail -3 [1680298.508557] mmc0: new ultra high speed SDR104 SDHC card at address aaaa [1680298.509190] mmcblk0: mmc0:aaaa SL32G 29.7 GiB [1680298.512418] mmcblk0: p1 p2 p3 shikoku::gpike>
In this case, I've limited the output to just the last three lines because the preceding lines aren't relevant. From the output, it appears that the SD card is device mmcblk0 and it already has three partitions on it. This is likely a previous Linux installation, since I've used these cards before. Just to make sure we're not going to destroy a system disk, let's check the size of the device. It should be around 32GB in size. There are a few ways to get the size. The following examples show using the lsblk command and the parted command to check the device size:
shikoku::gpike> lsblk /dev/mmcblk0 NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT mmcblk0 179:0 0 29.7G 0 disk ├─mmcblk0p1 179:1 0 200M 0 part ├─mmcblk0p2 179:2 0 29G 0 part └─mmcblk0p3 179:3 0 493.7M 0 part shikoku::gpike> sudo /usr/sbin/parted /dev/mmcblk0 print Model: SD SL32G (sd/mmc) Disk /dev/mmcblk0: 31.9GB Sector size (logical/physical): 512B/512B Partition Table: msdos Disk Flags: Number Start End Size Type File system Flags 1 1049kB 211MB 210MB primary fat16 lba, type=0c 2 212MB 31.4GB 31.2GB primary ext4 type=83 3 31.4GB 31.9GB 518MB primary linux-swap(v1) type=82 shikoku::gpike>
Both commands agree that the device size is around 32GB in size. There's some variance in the reported sizes because of different ways of reporting (GB vs. GiB vs. blocks), but this appears to be the device we want. If you think there's any information on the device that you may want to save, mount the partitions now and copy any important data off. Writing a new image onto the disk will destroy any existing data, including the partition table.
We'll use the dd command to write the image, and use a block size of 4M which will give us a little better throughput while writing the image. The image is also compressed, so we'll have to uncompress it before writing, but we can uncompress on the fly and pipe the output to the dd command, as follows:
shikoku::gpike> xzcat openSUSE-Leap15.0-ARM-JeOS-raspberrypi3.aarch64-2018.07.02-Buildlp150.1.1.raw.xz | sudo dd of=/dev/mmcblk0 bs=4M status=progress 1914331136 bytes (1.9 GB, 1.8 GiB) copied, 76.0053 s, 25.2 MB/s 0+195764 records in 0+195764 records out 1918894080 bytes (1.9 GB, 1.8 GiB) copied, 102.001 s, 18.8 MB/s shikoku::gpike>
According to the dd command, we got 18.8MB/s of throughput, which is pretty good considering our card only guarantees 10MB/s. The earlier number of 25.2MB/s is the rate from the progress monitor, which will vary during the write. The final number is the aggregate throughput. Can we do better? What if we uncompress the file first, or use a larger blocksize?
Now that we have the image written to the card, let's plug it in to the Raspberry Pi and see if we can boot the image. The SD card fits into the bottom side of the Pi. Plug it in, along with a keykoard, monitor, and power supply, and you should see your Pi begin booting. The first time it boots, it will resize the disk partitions to use the entire card, so as long as it seems to be doing something, let it run. It should eventually come back and give you a login prompt.
If your Pi doesn't seem to be doing anything after a few minutes, remove the power, pull the SD card, and try writing the image again. Unfortunately, there are very limited facilities available for debugging boot problems, and it's usually just easier to rewrite the card. The Pi images are much more reliable than they used to be, but sometimes things still fail for no obvious reason.
If everything goes well, you'll be rewarded with the login screen. At this point, there's only one user account, so log in as user root with password linux and let's get started.
Welcome to openSUSE Leap 15.0 - Kernel 4.12.14-lp150.11-default (tty1) localhost login: root Password: Have a lot of fun... localhost:~ #