Install Fedora onto Raspberry_Pi 2

This blog post is a referral to this comment from the raspberry pi stackexchange website on the subject of installing Fedora onto an SD card for use with a Raspberry_Pi. I would like to go over the steps myself, and add comments to the instructions.

To begin, first download and install NOOBs onto the SD card you wish to install Fedora on. Once NOOBs is loaded onto the card, place the card into the raspberry_pi and install Raspbian normally. By doing this, the card will gain the file structure and partitions it needs to operate normally. Once it's finished, the card should have a boot partition, a swap partition, and root partition created. The boot and swap partitions will remain untouched, though we will modify the root partition a bit.

Once the installation is finished and you see the blue setup screen, the card is ready to get Fedora loaded onto it. Unplug the pi and take out the SD, and insert it into your computer again. From this point forward a Linux or Mac is recommended.

NOTE: For Windows users, install VirtualBox and setup a guest machine to access the SD card. Refer to this blog post for directions on accessing an SD card through VirtualBox.

In the machine where we will be installing Fedora onto the card, check the /mnt directory. We will be mounting two devices which we will use as a source of files for Fedora and as a destination for those files. It is recommended you create two directories in your /mnt folder for this purpose. As a suggestion, run the following two commands.

1. mkdir /mnt/source
2. mkdir /mnt/destin

You can name the directories whatever you wish but these names are suggested since they more clearly denote what each directory will have mounted to them.

Once the SD is in the machine, figure out which device in /dev it is mapped to. For instance, the main disk drive may be /dev/sda while the SD card may be /dev/sdb. Due to the installation process of Raspbian, the SD card will have multiple partitions on it. The root partition may be the 6th partition, so the actual device you need may be /dev/sdb6. We'll mount this partition to the /mnt/destin directory.

That partition is currently holding the root file system of Raspbian. As it stands, the system is fully bootable, but we want to run Fedora. In the boot partition, all the files required to boot the OS properly already exists now, since we did a standard install. If we remove that partition, and recreate one where we drop the Fedora root system into it we'll be able to run the OS of our choice. Before we do that though there are two things we will need to make a copy of.

1. The current /etc/fstab file of Raspbian
2. A modules folder under /libs/modules
1. This folder will have '-v7+' at the end of the folder name

The fstab file holds the mounting information Fedora will need to properly mount the partition structure and the folder inside /libs/modules holds files that allow Fedora to have access to and be able to use the hardware of the Raspberry_Pi. You'll want to make copies of both.

Now that we have those copies, the rest of the root filesystem is uneeded, so go ahead and use your favorite partition manager (e.g. fdisk, gparted, etc...) and delete the root filesystem partition and create a new one with a format of ext4.

Now comes the part where we load Fedora onto the SD card. You'll need to download a version of Fedora from their ARM project page. As of this writing, Fedora-Minimal-armhfp-22-3-sda.raw.xz was used to install the operating system. Whichever version you download they will be compressed with xz. To uncompress it, the simplest way is to issue a command with the following format

1. xzcat Fedora-Minimal-armhfp-22-3-sda.raw.xz >> Fedora.raw

The above command uncompresses the file, but without the pipe into file 'Fedora.raw' then the uncompressed version of the file will simply print to the console, which is a useless place to have all that data. The name doesn't need to be 'Fedora.raw' but this documentation will refer to the output of the xzcat command with that name.

The 'Fedora.raw' file will contain multiple partitions as it is a file backup of an installed system. At this point it is recommended you install 'gdisk'  as 'fdisk' will not always give the correct numbers needed, as will be explained in a bit. If you issue the command "gdisk -l Fedora.raw" you will receive output like the following

  

This displays the  partitioning layout the .raw file is preserving. Right now, the important one we want is the third line listing. That partition holds the root filesystem that we will put on the SD card to run Fedora. But in order to access the data we will have to mount that partition as if it was a physical disk. Since it's a file though, we'll have to get a little crafty.

You'll notice two of the column headings are 'Start (sector)' and 'End (sector)'. We're looking at what is stored in the 'Start' column. Those numbers represent how many sectors into the hard disk the partition is 'physically' located. To mount it to gain access it, we will have to give a offset number so it knows to begin the mount at a certain point, otherwise it won't be able to work correctly. Before we can mount it though, we need to do a little math. 

On a harddrive, there are a certain amount of sectors which can actually hold data, and in the file system each sector is 512 bytes apart. So in order to get the correct offset number, we have to multiple the starting sector number by 512 to find where the mount will have to 'begin' to find the data we're looking for. In this case:

1. 1087488 * 512 = 556793856

So that huge number is where the mount will start looking for a filesystem format so we can read data from it. Now we just need to issue the mount command

1. mount -o ro,loop,offset=556793856 Fedora.raw /mnt/source

 By doing that the root partition should be mounted in /mnt/source and we can read from it freely. I will give a brief explanation what each of those options after '-o' mean if you are curious.

1. ro
1. Read-Only. Makes it so we can only read from the source. Using 'rw' instead would allow us to write changes, but we don't need that for our purposes.
2. loop
1. mounts the file as a 'loop' device, otherwise the system would sequentially read through all the data and not know how to return to the beginning so we can read additional data out.
2. Wikipedia Loop Device
3. offset
1. This is where we tell the machine where to begin looking for a file system inside the file.

With both devices mounted we simply need to copy the files we need to where we need them. To put the Fedora root system where we want it, issue this command

1. cp -R /mnt/source/* /mnt/destin

That will copy all files and recursively go through folders to ensure all files are copied to the destination. Then all you have to do is put the -v7+ folder inside /mnt/destin/libs/modules and take the fstab file we saved and overwrite the one at /mnt/destin/etc/fstab. Once you do that, issue the next two commands

1. umount /mnt/source
2. umount /mnt/destin

That will unmount the SD card and Fedora.raw file. Then you just need to place the SD back in the raspberry_pi, let it boot, and enjoy your new OS! There will be slight configuration needed during the boot, but it's just things like timezone, root password, and user creation.

Access SD card in OnBoard reader through VirtualBox Guest (Windows only)

NOTE: Instructions for use only on a Windows system. The second half of instructions may be translatable to a Mac or Linux machine, but I am unsure of that.

Recently went through the process of being able to read and write to an SD card for the purpose of putting Fedora 22 on to use for a Raspberry Pi 2. Wanted to jot down a few quick notes and tips to make the process a little easier. As a note, this was done on a 32 GB SDHC micro card. Shouldn't play too much of a factor if your card is different then that, but wanted to make a note of it anyway.

1. To begin, insert card into the onboard reader
2. If not a new card, format it.
3. Open command prompt (right click to run as admin) and issue the following command
1. wmic diskdrive list brief

That command will give a listing of all physical drives available on the system, and their DeviceID to access them. Find the line item for your SD card reader, and make a note of its ID name (e.g. \\.\PHYSICALDRIVE0)

That will give you the name to access it, but next in order to use it through VirtualBox we will have to make use of the VBoxManage feature of VirtualBox.

1. Open a command prompt (make sure to run as administrator)
2. If you do not have the VirtualBox install directory saved in your PATH, then I would recommend you set your working directory to there
1. (e.g. C:\Program Files\Oracle\VirtualBox)

Here is where you will run the command to create a raw disk VMDK file to access the SD card. The command will be of this format:

VBoxManage internalcommands createrawvmdk -filename <.vmdk location> -rawdisk <Physical Disk ID>

The 'filename' flag is the location where the .vmdk file will be created and the 'rawdisk' flag is the physical drive ID name of the disk to be used. The final command will look something like this:

VBoxManage internalcommands createrawvmdk -filename C:\Users\Doe\Documents\name.vmdk -rawdisk \\.\PHYSICALDRIVE0

Issuing that command will create the file 'name.vmdk' that has direct disk access to whatever is \\.\PHYSICALDRIVE0.

When using this file in VirtualBox, make sure to run VirtualBox as 'Administrator'. 

I do want to make a VERY important note here: with that above command, any VirtualBox guest with access to that file has raw access to it, meaning that guest can modify the filesystem as it pleases. With the wrong command, the entire disk format can be destroyed and all data lost. It is highly recommended you read the official documentation of this command to get a better understanding of it.

Another important note I wish to make here is that the SD card may not always have the physical drive ID that you originally found. One thing that was run into during this process is that a USB drive was inserted into the system before the VirtualBox guest was started up. Windows detected the new drive and bumped it up in the physical drive list. So though the file was pointing to \\.\PHYSICALDRIVE2, the SD card was now \\.\PHYSICALDRIVE3. If it had not been noticed then all data on the USB drive could have been lost.

Final note you might wish to be aware of, is that file I/O is a bit odd with this. When the drive is mounted in the guest machine, you can read any data stored on it very easily. But for whatever reason, whatever the very first partition is, you cannot reliably write to it. For some reason, Windows retains dedicated full control over the very first partition of the disk so the guest cannot write to it. If there is a second partition, you can still write to that one though. Also, despite this, any and all writing to the direct filesystem is still capable. So though you can not write to the very first partition of the disk, you can still delete that partition and create a new one. Does not always work, but very often works.