Line 11: | Line 11: | ||
Anaconda and Lorax have been modified to recognize some common ARM systems and select the appropriate kernel for installation. The livemedia-creator tool can be run on an F17 ARM build host to create a disk image. The installation is controlled by a kickstart configuration file. The image created can be copied directly to an SDCard and used to boot the system, for systems so equipped. | Anaconda and Lorax have been modified to recognize some common ARM systems and select the appropriate kernel for installation. The livemedia-creator tool can be run on an F17 ARM build host to create a disk image. The installation is controlled by a kickstart configuration file. The image created can be copied directly to an SDCard and used to boot the system, for systems so equipped. | ||
The modified versions of Anaconda, Lorax, and grubby are not available from the Fedora-ARM mirrors (changes not committed to F17), so they must be installed from the F17 xpfa repo. | The modified versions of Anaconda, Lorax, and grubby are not available from the F17 Fedora-ARM mirrors (changes not committed to F17), so they must be installed from the F17 xpfa repo. | ||
Revision as of 03:15, 12 October 2012
Creating a Fedora Install Image for ARM Systems
This will track the work to add ARM support to the standard Fedora installation tools (Anaconda/Lorax).
The plan is to use livemedia-creator to create disk images that can be stored directly on an SDCard to boot a device (e.g., Trim Slice), or booted via an ARM emulator like QEMU. Since most of these devices do not boot from standard media (CD/DVD), and lack the resources to perform standard Anaconda installs, these images can be used for testing, or copied to other storage (i.e., hard drive) for installations.
Creating a Disk Image
Anaconda and Lorax have been modified to recognize some common ARM systems and select the appropriate kernel for installation. The livemedia-creator tool can be run on an F17 ARM build host to create a disk image. The installation is controlled by a kickstart configuration file. The image created can be copied directly to an SDCard and used to boot the system, for systems so equipped.
The modified versions of Anaconda, Lorax, and grubby are not available from the F17 Fedora-ARM mirrors (changes not committed to F17), so they must be installed from the F17 xpfa repo.
Set Up the Repository
From an F17 ARM system, install the xpfa repo package:
- get the eXtra Packages for Fedora ARM (xpfa) yum repository definition:
sudo yum --nogpgcheck install http://dmarlin.fedorapeople.org/packages/FedoraArm/RPMS/noarch/xpfa-17-1.1.noarch.rpm
- install Anaconda and Lorax
sudo yum --enablerepo=xpfa install anaconda lorax
Building the Image
On the target build host, log in as 'root', and perform the following steps.
- set up a kickstart file
I recommend first using the one of the example kickstart files as a test to make sure everything is set up and working as expected. Then use it as a base for creating other kickstart configuration files.
- run livemedia-creator
livemedia-creator \ --make-disk --no-virt --image-only --keep-image \ --ks=/root/F17-trimslice.ks
By default livemedia-creator creates an image for the build host platform, for example, if run on a Trim Slice, use a Trim Slice kickstart file, and the target image will be for a Trim Slice. The default platform can be overridden using the --armplatform
option, for example, to create an image for Panda:
livemedia-creator \ --make-disk --no-virt --image-only --keep-image \ --armplatform=omap --ks=/root/F17-panda.ks
To create an image for Versatile Express use --armplatform=None
. Be sure to use the appropriate kickstart file for the selected target platform.
The disk image is created in /tmp/disk<TempString>.img
. When the process completes, the contents of the disk image may be examined by loop-mounting the image file.
The trimslice.ks defines three partitions:
/boot swap /
These will be mapped in order, for example:
# kpartx -av <PathToDiskImage> add map loop0p1 (253:0): 0 522240 linear /dev/loop0 2048 add map loop0p2 (253:1): 0 2621440 linear /dev/loop0 524288 add map loop0p3 (253:2): 0 1046528 linear /dev/loop0 3145728 # ls -l /dev/mapper total 0 crw------- 1 root root 10, 236 Feb 11 00:46 control lrwxrwxrwx 1 root root 7 Apr 25 18:49 loop0p1 -> ../dm-0 lrwxrwxrwx 1 root root 7 Apr 25 18:49 loop0p2 -> ../dm-1 lrwxrwxrwx 1 root root 7 Apr 25 18:49 loop0p3 -> ../dm-2 # mkdir -p /mnt/rootfs # mount -o loop /dev/dm-2 /mnt/rootfs [108293.766690] EXT4-fs (loop1): mounted filesystem with ordered data mode. Opts: (null) # mount -o loop /dev/dm-0 /mnt/rootfs/boot [108293.906412] kjournald starting. Commit interval 5 seconds [108293.906531] EXT3-fs (loop2): using internal journal [108293.906545] EXT3-fs (loop2): mounted filesystem with ordered data mode # pushd /mnt/rootfs/ /mnt/rootfs ~ # ls -l total 54 lrwxrwxrwx. 1 root root 7 Sep 13 15:47 bin -> usr/bin dr-xr-xr-x. 4 root root 1024 Sep 13 15:53 boot drwxr-xr-x. 15 root root 2900 Dec 31 1969 dev drwxr-xr-x. 83 root root 4096 Oct 11 18:36 etc drwxr-xr-x. 2 root root 4096 Jul 23 07:53 home lrwxrwxrwx. 1 root root 7 Sep 13 15:47 lib -> usr/lib drwx------. 2 root root 16384 Sep 13 15:46 lost+found drwxr-xr-x. 2 root root 4096 Jul 23 07:53 media drwxr-xr-x. 2 root root 4096 Jul 23 07:53 mnt drwxr-xr-x. 2 root root 4096 Jul 23 07:53 opt dr-xr-xr-x. 91 root root 0 Dec 31 1969 proc dr-xr-x---. 3 root root 4096 Oct 11 17:40 root drwxr-xr-x. 20 root root 680 Oct 11 18:37 run lrwxrwxrwx. 1 root root 8 Sep 13 15:47 sbin -> usr/sbin drwxr-xr-x. 2 root root 4096 Jul 23 07:53 srv dr-xr-xr-x. 12 root root 0 Dec 31 1969 sys drwxrwxrwt. 7 root root 140 Oct 11 18:36 tmp drwxr-xr-x. 12 root root 4096 Sep 13 15:47 usr drwxr-xr-x. 18 root root 4096 Sep 13 15:52 var # ls -l boot/ total 53471 -rw-r--r--. 1 root root 254 Sep 13 15:53 boot.cmd.mmc -rw-r--r--. 1 root root 254 Sep 13 15:53 boot.cmd.usb -rw-r--r--. 1 root root 326 Sep 13 15:53 boot.scr -rw-r--r--. 1 root root 326 Sep 13 15:53 boot.scr.mmc -rw-r--r--. 1 root root 326 Sep 13 15:53 boot.scr.usb -rw-r--r--. 1 root root 117913 Oct 5 10:57 config-3.6.0-3.fc18.armv7hl.tegra drwxr-xr-x. 3 root root 1024 Sep 13 15:49 grub2 -rw-r--r--. 1 root root 13835773 Sep 13 15:53 initramfs-3.6.0-3.fc18.armv7hl.tegra.img -rw-r--r--. 1 root root 230391 Sep 13 15:52 initrd-plymouth.img -rw-r--r--. 1 root root 27 Sep 13 15:53 klist.txt drwx------. 2 root root 12288 Sep 13 15:46 lost+found -rw-------. 1 root root 1578075 Oct 5 10:57 System.map-3.6.0-3.fc18.armv7hl.tegra -rw-r--r--. 1 root root 3684840 Sep 13 15:53 uImage -rw-r--r--. 1 root root 3684840 Sep 13 15:53 uImage-3.6.0-3.fc18.armv7hl.tegra -rw-r--r--. 1 root root 13835837 Sep 13 15:53 uInitrd -rw-r--r--. 1 root root 13835837 Sep 13 15:53 uInitrd-3.6.0-3.fc18.armv7hl.tegra -rwxr-xr-x. 1 root root 3684776 Oct 5 10:57 vmlinuz-3.6.0-3.fc18.armv7hl.tegra # cat /etc/system-release Fedora release 18 (Spherical Cow) # cat /etc/RELEASE F18-20121011-test # popd ~ # umount /mnt/rootfs/boot # umount /mnt/rootfs # kpartx -dv <PathToDiskImage> del devmap : loop0p3 del devmap : loop0p2 del devmap : loop0p1 loop deleted : /dev/loop0
If you build a Versatile Express image for QEMU there is an additional step. You need to extract the kernel and initramfs from the image in order to provide them to QEMU to boot. Fortunately there is a script available (livemedia-modifier), which does this for you, and creates a compressed tarball that includes all you need to run the image from QEMU.
livemedia-modifier --image=<PathToDiskImage> --platform=vexpress
For other platforms, the disk image may be compressed for storage or transferring to other systems using xz
, for example:
xz -z -9 <PathToDiskImage>
The disk image file will be replaced by a compressed image (.xz extension added).
Installing the Image
This disk image is suitable to be copied directly to an SDCard. The disk image could similarly be copied to other media, but is configured by default to boot from the SDCard.
To copy this to an SDCard from a workstation, plug the SDCard into a USB adapter, inserted the adapter to an open USB slot, and checked /proc/partitions
to see where it is located. For this example, assume it is located on /dev/sdb
.
# cat /proc/partitions major minor #blocks name 8 0 78150744 sda 8 1 512000 sda1 8 2 77637632 sda2 8 16 7879680 sdb 8 17 7875584 sdb1
To transfer the image to the device, make sure none of the partitions on that device are mounted, for example:
# umount /dev/sdb1
Then copy the disk image to the raw device.
# xzcat <PathToCompressedDiskImage> | dd of=/dev/sdb
Once the transfer completes, the partition table will need to be rescanned and updated.
# partprobe /dev/sdb
The device partitions may then be mounted and the contents examined, or the device may be ejected and moved to test booting on the target system.
Running the Image from QEMU
The Versatile Express tarball includes all that is needed to boot the system, including the root filesystem image, and the pre-extracted kernel and initramfs. Also, included for your convenience are two scripts to boot your image. To extract the files use:
# tar Jxvf <PathToCompressedTarball>
You can make use of the scripts provided in the boot
directory to launch your image using QEMU:
# cd ./<VExpressDirectory>/boot/ # ./boot-vexpress \ vmlinuz-<Version-Release> \ initramfs-<Version-Release>.img \ ../<VExpressImageName>.img
This boots to a command line login prompt.