Update: Thanks to Peter Robinson, there is now a build of OCaml for aarch64 in the Fedora repository.
Tag Archives: fedora
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 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
/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.
# arch aarch64
/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.
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
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).
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%)
Fedora 20 virtualization test day is this Tuesday. Come and join us on FreeNode IRC in
Ideally you would have one of the following in decreasing order of preference:
- Fedora 20 installed on a physical machine (the best option!)
- Fedora 20 installed in a virtual machine — make sure you give the VM plenty of disk space and RAM.
- Fedora 19 with virt-preview or with updated F20 packages via some other route (eg. compiling from SRPMs).
But we’re also around in case you just want to chat about upcoming Fedora features.
After using OCaml for around 10 years it is still my favourite language, and it’s amazing how far ahead of other programming languages it remains to this day.
OCaml 4.01.0 was released on Thursday and I’m putting it into Fedora Rawhide over this weekend.
Debuginfo is now (partially) enabled. The OCaml code generator has produced good quality DWARF information for a while, and now you are able to debug OCaml programs in gdb under Fedora:
$ sudo debuginfo-install ocaml ocaml-findlib $ gdb /usr/bin/ocamlfind [...] Reading symbols from /usr/bin/ocamlfind... Reading symbols from /usr/lib/debug/usr/bin/ocamlfind.debug...done. done. (gdb) break frontend.ml:469 Breakpoint 1 at 0x432500: file frontend.ml, line 469. (gdb) run query findlib -l Starting program: /usr/bin/ocamlfind query findlib -l Breakpoint 1, camlFrontend__query_package_1199 () at frontend.ml:469 469 let query_package () = (gdb) bt #0 camlFrontend__query_package_1199 () at frontend.ml:469 #1 0x000000000043a4b4 in camlFrontend__main_1670 () at frontend.ml:2231 #2 0x000000000043aa86 in camlFrontend__entry () at frontend.ml:2283 #3 0x000000000042adc9 in caml_program () #4 0x00000000004834be in caml_start_program () #5 0x000000000048365d in __libc_csu_init () #6 0x0000003979821b75 in __libc_start_main (main=0x42aa60 <main>, argc=4, ubp_av=0x7fffffffde38, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffde28) at libc-start.c:258 #7 0x000000000042aaa9 in _start () (gdb) list 464 ;; 465 466 467 (************************** QUERY SUBCOMMAND ***************************) 468 469 let query_package () = 470 471 let long_format = 472 "package: %p\ndescription: %D\nversion: %v\narchive(s): %A\nlinkopts: %O\nlocation: %d\n" in 473 let i_format =
GDB only understands location data at the moment, so you can’t yet query variables (although I understand OCaml generates the correct DWARF info for this, GDB just doesn’t know how to print OCaml expressions).
There will also be some limitations on the debuginfo built at first. At the moment it doesn’t include debuginfo for OCaml libraries called from an OCaml program, because of problems that need to be worked out with the toolchain. Mixed OCaml binary / C library debuginfo does work.
I bought this box about a year ago but I don’t think I wrote about it at the time (at least, I can’t find anything in the archives).
It’s an Apple G5 circa 2005 which cost me £165 (from this eBay seller).
These boxes are sweet — dual socket, 64 bit, 4 GB of RAM, 80 GB of hard disk. It’s surprisingly fast for an 8 year old machine, and beautifully built. Anyone hazard a guess what this would have cost when new?
It runs Fedora perfectly, and has Alex’s “fake KVM” [PDF] support so you can run virtual machines pretty fast too.
$ cat /proc/cpuinfo processor : 0 cpu : PPC970MP, altivec supported clock : 1000.000000MHz revision : 1.1 (pvr 0044 0101) processor : 1 cpu : PPC970MP, altivec supported clock : 1000.000000MHz revision : 1.1 (pvr 0044 0101) timebase : 33333333 platform : PowerMac model : PowerMac11,2 machine : PowerMac11,2 motherboard : PowerMac11,2 MacRISC4 Power Macintosh detected as : 337 (PowerMac G5 Dual Core) pmac flags : 00000000 L2 cache : 1024K unified pmac-generation : NewWorld $ free -m total used free shared buffers cached Mem: 3983 3966 16 0 221 3069 -/+ buffers/cache: 675 3308 Swap: 2911 0 2911 $ sudo lspci 0000:00:0b.0 PCI bridge: Apple Computer Inc. CPC945 PCIe Bridge 0000:0a:00.0 VGA compatible controller: nVidia Corporation NV43 [GeForce 6600 LE] (rev a2) 0001:00:00.0 Host bridge: Apple Computer Inc. U4 HT Bridge 0001:00:01.0 PCI bridge: Broadcom BCM5780 [HT2000] PCI-X bridge (rev a3) 0001:00:02.0 PCI bridge: Broadcom BCM5780 [HT2000] PCI-X bridge (rev a3) 0001:00:03.0 PCI bridge: Broadcom BCM5780 [HT2000] PCI-Express Bridge (rev a3) 0001:00:04.0 PCI bridge: Broadcom BCM5780 [HT2000] PCI-Express Bridge (rev a3) 0001:00:05.0 PCI bridge: Broadcom BCM5780 [HT2000] PCI-Express Bridge (rev a3) 0001:00:06.0 PCI bridge: Broadcom BCM5780 [HT2000] PCI-Express Bridge (rev a3) 0001:00:07.0 PCI bridge: Apple Computer Inc. Shasta PCI Bridge 0001:00:08.0 PCI bridge: Apple Computer Inc. Shasta PCI Bridge 0001:00:09.0 PCI bridge: Apple Computer Inc. Shasta PCI Bridge 0001:01:07.0 Unassigned class [ff00]: Apple Computer Inc. Shasta Mac I/O 0001:01:0b.0 USB Controller: NEC Corporation USB (rev 43) 0001:01:0b.1 USB Controller: NEC Corporation USB (rev 43) 0001:01:0b.2 USB Controller: NEC Corporation USB 2.0 (rev 04) 0001:03:0c.0 IDE interface: Broadcom K2 SATA 0001:03:0d.0 Unassigned class [ff00]: Apple Computer Inc. Shasta IDE 0001:03:0e.0 FireWire (IEEE 1394): Apple Computer Inc. Shasta Firewire 0001:05:04.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5780 Gigabit Ethernet (rev 03) 0001:05:04.1 Ethernet controller: Broadcom Corporation NetXtreme BCM5780 Gigabit Ethernet (rev 03)