Tag Archives: fedora

Red Hat speakers at FOSDEM 2014

If you’re planning to be at FOSDEM in Belgium this weekend, then do come and see some of the Red Hat folk who are giving talks. The full list is here or use this handy printed guide [PDF].

(Thanks Garrett)

Leave a comment

Filed under Uncategorized

fedpkg recipes

At some point I intend to implement a view source tool, but in the mean time here are some useful recipes.

fedpkg is a great little command line tool for checking out, building and modifying Fedora packages. On this page I’m collecting a few simple recipes, useful for all Fedora users. You will need to yum install fedpkg but apart from that no other preparation is required. All the recipes use binutils as an example, but you can use any package name.

Do you have a recipe using fedpkg? Post it in the comments.

Upgrade to the Rawhide version of a Fedora package

fedpkg clone -a -B binutils
cd binutils/master

master corresponds to Rawhide. There are also directories for each branch, eg. f20 for Fedora 20. At this point you may need to install build dependencies:

sudo yum-builddep binutils.spec

Build the package on your local machine. This builds it against whatever version of Fedora is installed on your machine:

fedpkg local

To install the package:

sudo yum install */*.rpm

Apply a source patch to a Fedora package

Note: One aim of the proposed view-source tool will be to make this almost completely automated.

fedpkg clone -a -B binutils
cd binutils/fXX

(Choose your current Fedora version instead of fXX, or use master for Rawhide)

Apply the patch:

cp /tmp/test.patch .
rpmdev-bumpspec -r binutils.spec
vi binutils.spec

Near the top of the spec file, add:

Patch9999: test.patch

In the %prep section, add:

%patch9999 -p1

Now build and install the patched package as usual:

sudo yum-builddep binutils.spec
fedpkg local
sudo yum localupdate */*.rpm

Examine the source of a package

Sure, you can look at the upstream package sources, but often you want to look at the older / patched source as it applies to your version of Fedora, since that might be different …

fedpkg clone -a -B binutils
cd binutils/fXX
fedpkg prep

Change fXX to your version of Fedora. The prep subcommand will unpack the tarball and apply all the patches.

2 Comments

Filed under Uncategorized

Alignment errors on Fedora ARM

Here’s what you should do if you get a compile error like this on Fedora ARM:

error: cast increases required alignment of target type [-Werror=cast-align]
  1. If it’s an easy fix with little chance of breaking things, then fix it.
  2. If it’s on a performance critical path, especially if it causes a measurable slow down, then fix it.
  3. Otherwise, disable the warning. One way is to add:
    #pragma GCC diagnostic ignored "-Wcast-align"
    

BTW I will delete any comment on this post unless you show you have read the next part:

The background is that on certain architectures (ARM and MIPS are the main ones) the processor cannot load or store values from memory which is not aligned. Say you had a protocol which sent a 1 byte length field followed by a 4 byte data field:

+-------+-------+-------+-------+-------+- - - -
| len   | <---------- data -----------> |
+-------+-------+-------+-------+-------+- - - -

If you loaded this into malloc’d memory and used a C struct like this to access it:

struct {
  uint8_t len;
  int32_t data;
} __attribute__((packed));

then accesses to p->data might trap. The malloc’d memory, hence the struct, is aligned, and so the data field is not aligned.

What happens in Fedora is the kernel gets called. It sees a FAULT_CODE_ALIGNMENT fault, looks at the failed load instruction, emulates it, then returns back to your code. This fixup step is slow.

However it’s not a bug. Fedora only runs on recent ARM chips that can now do some unaligned accesses in hardware and always generate traps for ones they can’t handle.

Your code will still run fine assuming you don’t change the /proc/cpu/alignment setting. But if these fixups are frequent it is plausible that they could cause a performance problem.

Fixing these can be hard, and is more likely to create bugs (as we found out when trying to fix alignment bugs in hivex).

Since the most popular development architecture (x86) has always been able to handle unaligned accesses in hardware, developers are going to keep adding unaligned accesses to their programs. In the Intel Haswell chips, there isn’t even a performance penalty (in fact, it’s likely to be faster to squeeze your structs as much as possible, even if it makes them unaligned). ARM has gradually been adding the ability to handle unaligned access too, so eventually one hopes the problem will go away for developers.

5 Comments

Filed under Uncategorized

Fedora 21 has a working OCaml ARM64

Update: Thanks to Peter Robinson, there is now a build of OCaml for aarch64 in the Fedora repository.

I have backported the upstream ARM64 support into Fedora 21’s OCaml, so you can now use it to generate native ARM64/AArch64 binaries. If you don’t have hardware, use qemu to emulate it instead.

6 Comments

Filed under Uncategorized

How to run aarch64 binaries on an x86-64 host using qemu userspace emulation

Note: This is the Fedora version of this Debian document so full credit must go to Debian and SuSE for assembling the bits.

Qemu (not quite upstream) now has ARM 64 bit emulation. It only does the userspace emulation at the moment, although system emulation is being worked on. This is much faster than the ARM “Foundation Model” (basically ARM’s proprietary emulator).

You will need to clone SuSE’s ARM64 qemu git repository and compile it statically linked (configure it with --target-list=arm64-linux-user --static). Static glib2 for Fedora is here.

You will also need to download this Fedora 19 arm64 disk image and convert it into a root filesystem (unfortunately this process requires, just temporarily, 14 GB of free disk space — should have used virt-sparsify!!):

mkdir /tmp/arm64
cd /tmp/arm64
tar zxf F19-aarch64-efi.tar.xz
virt-tar-out -a ./F19-aarch64-efi/aarch64-efi.img / - |
    sudo tar xf -
rm -rf F19-aarch64-efi

So now what you should have is a statically linked qemu-arm64 binary (that’s the userspace arm64 emulator), and a root filesystem containing lots of arm64 binaries. To run them we’ll need to set up a systemd binfmt handler, which will notice when we’re about to try to run an arm64 binary and inject our emulator so it’s possible to run it on our host (which is obviously not arm64 since that hardware is unobtainium for most mortals).

Copy the statically linked qemu-arm64 binary into the chroot, ie:

cp ./arm64-linux-user/qemu-arm64 /tmp/arm64/

Create a binfmt file /etc/binfmt.d/qemu-arm64.conf with the content below. Note that it refers to the absolute path /qemu-arm64 which (will be) correct once we chroot into the arm64 filesystem.

# AArch64 binaries.
:qemu-arm64:M::\x7fELF\x02\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\xb7:\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff:/qemu-arm64:OC
$ sudo service systemd-binfmt restart

Check that /proc/sys/fs/binfmt_misc/qemu-arm64 has been created with the expected contents.

Now you’re ready to go!

$ cd /tmp/arm64
$ sudo mount -o bind /dev ./dev
$ sudo mount -o bind /dev/pts ./dev/pts
$ sudo mount -o bind /proc ./proc
$ sudo mount -o bind /sys ./sys
$ sudo chroot .
# file bin/ls
bin/ls: ELF 64-bit LSB executable, version 1 (SYSV),
dynamically linked (uses shared libs), for GNU/Linux
3.7.0,
BuildID[sha1]=0x31bcaf7de1bb3c6a4400983ac31f0dff1bbfc394, stripped
# /bin/ls
bin   dev  home  lib64	     media  opt   qemu-arm64  run   srv  tmp  var
boot  etc  lib	 lost+found  mnt    proc  root	      sbin  sys  usr
# uname -a
Linux choo.home.annexia.org 3.8.0 #1 SMP Thu Oct 10
14:11:18 UTC 2013 aarch64 aarch64 aarch64 GNU/Linux

And somehow convince yourself you really are running arm64 binaries!

One problem I had is the supplied chroot is quite minimal and I’m not exactly sure how to install more. But it’s fun to play and a lot faster than the Foundation Model.

Update #1

# arch
aarch64

Update #2

The /etc/yum.repos.d/stage4.repo file in the disk image above is broken. Peter Robinson notes that you can use http://arm.koji.fedoraproject.org/aarch64/stage4/ as a yum repo for installing more packages.

Update #3

Outside the chroot — when you’re running commands in the chroot — you’ll see qemu interpreting the arm64 binaries in ps output:

$ ps ax | grep qemu
26051 pts/14   S      0:03 /qemu-arm64 /bin/bash -i
28170 pts/14   S      0:00 /qemu-arm64 /bin/su rjones
28171 pts/14   S      0:01 /qemu-arm64 /bin/bash
28226 pts/14   Sl+    0:03 /qemu-arm64 /bin/git clone git://libvirt.org/libvirt.git
28228 pts/14   S+     0:12 /qemu-arm64 /usr/libexec/git-core/git index-pack --stdin -v --fix-thin --keep=fetch-pack 28226 on choo.home.annexia.org

7 Comments

Filed under Uncategorized

Install Fedora 20 with virt-builder

Fedora 20 has been released. You can now install it in a VM using virt-builder:

$ virt-builder fedora-20

This creates a file fedora-20.img. You can import this into libvirt by using the command here.

3 Comments

Filed under Uncategorized

Virt-builder making VMs in around 3̶0̶ 16 seconds

The newest upstream virt-builder can now build simple VMs in around 30 seconds (this is on a machine with a hard drive, it’s faster if you have SSDs):

$ virt-builder ubuntu-12.04
[   0.0] Downloading: file:///home/rjones/d/libguestfs/builder/website/ubuntu-12.04.xz
[   1.0] Creating disk image: ubuntu-12.04.img
[   1.0] Uncompressing: file:///home/rjones/d/libguestfs/builder/website/ubuntu-12.04.xz
[   9.0] Opening the new disk
[  33.0] Setting a random seed
[  33.0] Random root password: z6T5zQiqIIy0yZfA [did you mean to use --root-password?]
[  33.0] Finishing off
Output: ubuntu-12.04.img
Total usable space: 2.9G
Free space: 2.1G (73%)

Even installing packages in the VM, it’s still taking under 1 minute:

$ virt-builder ubuntu-12.04 --install nmap
[   0.0] Downloading: file:///home/rjones/d/libguestfs/builder/website/ubuntu-12.04.xz
[   1.0] Creating disk image: ubuntu-12.04.img
[   1.0] Uncompressing: file:///home/rjones/d/libguestfs/builder/website/ubuntu-12.04.xz
[  10.0] Opening the new disk
[  34.0] Setting a random seed
[  34.0] Random root password: Mt3kxbEsBqumG6bR [did you mean to use --root-password?]
[  34.0] Installing packages: nmap
[  53.0] Finishing off
Output: ubuntu-12.04.img
Total usable space: 2.9G
Free space: 2.0G (70%)

The major changes are: It will use pxzcat (parallel xzcat) if available, and it will bypass the virt-resize step if you don’t specify the --size option (or if you make sure the templates are the right size to start with).

Update:

On a machine with an Intel SSD and parallel xzcat installed:

$ virt-builder ubuntu-12.04
[   0.0] Downloading: file:///home/rjones/d/libguestfs/builder/website/ubuntu-12.04.xz
[   1.0] Creating disk image: ubuntu-12.04.img
[   1.0] Uncompressing: file:///home/rjones/d/libguestfs/builder/website/ubuntu-12.04.xz
[  12.0] Opening the new disk
[  16.0] Setting a random seed
[  16.0] Random root password: JdIsqD5QB64yImYL [did you mean to use --root-password?]
[  16.0] Finishing off
Output: ubuntu-12.04.img
Total usable space: 2.9G
Free space: 2.1G (73%)

Leave a comment

Filed under Uncategorized