Displaying Gluster traffic in Wireshark

As part of my job, I am doing some tests with the Red Hat Storage Software Appliance. The current version of RHSSA is based on Gluster 3.2.5. After some experiments, it seem that Gluster is pretty cool and surprisingly easy to setup.

In order to see what is going happening on the network, I captured some tcpdumps. Reading the files in Wireshark, does not show any Gluster specifics. It seems that Wireshark does not know how to decode (or rather dissect) the Gluster traffic. Very unfortunate, as quite some future troubleshooting and performance analysis may require investigating the network packets.

Luckily the Wireshark Developer's guide contains a chapter on Adding a basic dissector. After writing some code and tests, I now have some Wireshark packages that recognize some Gluster communication. The RPMs are available for testing, feedback over email is appreciated.

With the updated packages, the output of tshark (the terminal version of Wireshark) identifies some Gluster packets:

$ tshark -r gluster-communication.cap 'tcp.len > 0' | head
  7   0.002572 192.168.122.184 -> 192.168.122.137 Gluster Dump V1 DUMP Call
  8   0.002633 192.168.122.184 -> 192.168.122.137 Gluster Dump V1 DUMP Call
 11   0.002909 192.168.122.137 -> 192.168.122.184 Gluster Dump V1 DUMP Reply (Call In 7)
 12   0.002918 192.168.122.137 -> 192.168.122.184 Gluster Dump V1 DUMP Reply (Call In 8)
 15   0.003104 192.168.122.184 -> 192.168.122.137 Gluster Portmap V1 PORTBYBRICK Call
 16   0.003158 192.168.122.184 -> 192.168.122.137 Gluster Portmap V1 PORTBYBRICK Call
 17   0.003298 192.168.122.137 -> 192.168.122.184 Gluster Portmap V1 PORTBYBRICK Reply (Call In 15)
 18   0.003310 192.168.122.137 -> 192.168.122.184 Gluster Portmap V1 PORTBYBRICK Reply (Call In 16)
 31   3.013909 192.168.122.184 -> 192.168.122.137 Gluster Dump V1 DUMP Call
 32   3.013965 192.168.122.184 -> 192.168.122.137 PCEP Unknown Message (0). 

As with several other protocols, Wireshark detects some packets as non-gluster ones. In this tcpdump, there surely is no PCEP traffic (last line in the above output). Each dissector for a protocol should do some sanity checks to see if a packet belongs to its protocol. These checks are not easy to do, and hence quite some protocols detect packets from Gluster as their communication stream.

Luckily it is possible to disable a protocol in the ~/.wireshark/disabled_protos file. Finding the correct names of a protocol isn't always straight forward. Use Wireshark to graphically create the file is the easiest, it also takes care of disabling the protocols that are possibly encapsulated. In Wireshark

1. go to Analyze in the menu
2. click "Enabled Protools"
3. uncheck PCEP (and while you are at it, also uncheck SSL as it gives the same issues)

After these steps, tshark should recognize all traffic to and from port 24007 as belonging to one of the Gluster protocols. I have only tested the Wireshark dissectors on Gluster 3.2.5, later releases use some newer versions of some protocols and these may not be detected yet.

Unexpected requirements for creating a video DVD with Brasero

With the current standard of mobiles and photo cameras that can be used to film things, it would be fun to create a little video. It seems that Brasero is a standard tool for the GNOME desktop, which should work without issues in my preferred XFCE as well. Brasero (and seemingly all of its dependencies) is even included in the Red Hat Enterprise Linux 6.2 Workstation repository/channel.

Unfortunately, after creating a video project in Brasero, a little warning gets displayed:

It is not possible to write with the current set of plugins.

There is the need for a more detailed look into how Brasero does the detection/loading of plugins. In the search for more verbosity from the command-line, I found that the command
brasero --help shows that there is a --help-brasero-burn option. Giving that a try, dumps an immense list of things on the console. This includes the following:

• ffmpeg_mpeg2video is missing
  

  (brasero:19298): BraseroBurn-DEBUG: At burn-plugin-manager.c:452: loading /usr/lib64/brasero/plugins/libbrasero-vob.so
  (brasero:19298): BraseroBurn-DEBUG: At burn-plugin.c:1041: Module encountered an error while registering its capabilities:
  "ffenc_mpeg2video" element could not be created
  (brasero:19298): BraseroBurn-DEBUG: At burn-plugin-manager.c:481: Load failure, no GType was returned "ffenc_mpeg2video" element could not be created

• libdvdcss is missing
  

  (brasero:19298): BraseroBurn-DEBUG: At burn-plugin-manager.c:452: loading /usr/lib64/brasero/plugins/libbrasero-dvdcss.so
  (brasero:19298): BraseroBurn-DEBUG: At burn-plugin.c:1041: Module encountered an error while registering its capabilities:
  Encrypted DVD: please install libdvdcss version 1.2.x
  (brasero:19298): BraseroBurn-DEBUG: At burn-plugin-manager.c:481: Load failure, no GType was returned Encrypted DVD: please install libdvdcss version 1.2.x
  

• dvdauthor is missing
  

  (brasero:19298): BraseroBurn-DEBUG: At burn-plugin-manager.c:452: loading /usr/lib64/brasero/plugins/libbrasero-dvdauthor.so
  (brasero:19298): BraseroBurn-DEBUG: At burn-plugin.c:1041: Module encountered an error while registering its capabilities:
  "dvdauthor" could not be found in the path
  (brasero:19298): BraseroBurn-DEBUG: At burn-plugin-manager.c:481: Load failure, no GType was returned "dvdauthor" could not be found in the path

• vcdimager is missing
  

  (brasero:19298): BraseroBurn-DEBUG: At burn-plugin-manager.c:452: loading /usr/lib64/brasero/plugins/libbrasero-vcdimager.so
  (brasero:19298): BraseroBurn-DEBUG: At burn-plugin.c:1041: Module encountered an error while registering its capabilities:
  "vcdimager" could not be found in the path
  (brasero:19298): BraseroBurn-DEBUG: At burn-plugin-manager.c:481: Load failure, no GType was returned "vcdimager" could not be found in the path

After some googling, it seems that these packages are made available for RHEL6 in Repoforge (previously RPMForge). The additional packages that need to get installed (first pass):

• gstreamer-ffmpeg
• libdvdcss
• dvdauthor
• vcdimager

Getting closer, but not completely there yet, as brasero --brasero-burn-debug still misses something:

(brasero:19508): BraseroBurn-DEBUG: At burn-plugin-manager.c:452: loading /usr/lib64/brasero/plugins/libbrasero-vob.so
(brasero:19508): BraseroBurn-DEBUG: At burn-plugin.c:1041: Module encountered an error while registering its capabilities:
"mplex" element could not be created
(brasero:19508): BraseroBurn-DEBUG: At burn-plugin-manager.c:481: Load failure, no GType was returned "mplex" element could not be created

Knowing that Brasero uses the GStreamer framework, it seems logical to try to install a GStream plugin called mplex. All GStreamer plugins seem to be located in /usr/lib64/gstreamer-0.10, and installing the mplex plugin with yum seems to work:

# yum install /usr/lib64/gstreamer-0.10/libgstmplex.so
Loaded plugins: refresh-packagekit, rhnplugin
Setting up Install Process
...
Resolving Dependencies
--> Running transaction check
---> Package gstreamer-plugins-bad.x86_64 0:0.10.19-3.el6.rf will be installed
--> Processing Dependency: libxvidcore.so.4()(64bit) for package: gstreamer-plugins-bad-0.10.19-3.el6.rf.x86_64
--> Processing Dependency: libmms.so.0()(64bit) for package: gstreamer-plugins-bad-0.10.19-3.el6.rf.x86_64
--> Processing Dependency: libmusicbrainz.so.4()(64bit) for package: gstreamer-plugins-bad-0.10.19-3.el6.rf.x86_64
--> Processing Dependency: libamrwb.so.3()(64bit) for package: gstreamer-plugins-bad-0.10.19-3.el6.rf.x86_64
--> Processing Dependency: libcdaudio.so.1()(64bit) for package: gstreamer-plugins-bad-0.10.19-3.el6.rf.x86_64
--> Running transaction check
---> Package amrwb.x86_64 0:7.0.0.3-1.el6.rf will be installed
---> Package libcdaudio.x86_64 0:0.99.12p2-13.el6 will be installed
---> Package libmms.x86_64 0:0.5-1.el6.rf will be installed
---> Package libmusicbrainz.x86_64 0:2.1.5-11.1.el6 will be installed
---> Package xvidcore.x86_64 0:1.2.2-1.el6.rf will be installed
--> Finished Dependency Resolution

Dependencies Resolved

========================================================================================================================================================================
 Package                                     Arch                         Version                                 Repository                                       Size
========================================================================================================================================================================
Installing:
 gstreamer-plugins-bad                       x86_64                       0.10.19-3.el6.rf                        rpmforge                                        1.2 M
Installing for dependencies:
 amrwb                                       x86_64                       7.0.0.3-1.el6.rf                        rpmforge                                        180 k
 libcdaudio                                  x86_64                       0.99.12p2-13.el6                        epel                                             39 k
 libmms                                      x86_64                       0.5-1.el6.rf                            rpmforge                                         60 k
 libmusicbrainz                              x86_64                       2.1.5-11.1.el6                          rhel-x86_64-workstation-6                        88 k
 xvidcore                                    x86_64                       1.2.2-1.el6.rf                          rpmforge                                        555 k

Transaction Summary
========================================================================================================================================================================
Install       6 Package(s)

Total download size: 2.1 M
Installed size: 7.4 M
Is this ok [y/N]: y
Downloading Packages:
...
Running rpm_check_debug
Running Transaction Test
Transaction Test Succeeded
Running Transaction
  Installing : libcdaudio-0.99.12p2-13.el6.x86_64                                                                                                                   1/6 
  Installing : libmms-0.5-1.el6.rf.x86_64                                                                                                                           2/6 
  Installing : amrwb-7.0.0.3-1.el6.rf.x86_64                                                                                                                        3/6 
  Installing : libmusicbrainz-2.1.5-11.1.el6.x86_64                                                                                                                 4/6 
  Installing : xvidcore-1.2.2-1.el6.rf.x86_64                                                                                                                       5/6 
  Installing : gstreamer-plugins-bad-0.10.19-3.el6.rf.x86_64                                                                                                        6/6 

Installed:
  gstreamer-plugins-bad.x86_64 0:0.10.19-3.el6.rf                                                                                                                       

Dependency Installed:
  amrwb.x86_64 0:7.0.0.3-1.el6.rf         libcdaudio.x86_64 0:0.99.12p2-13.el6        libmms.x86_64 0:0.5-1.el6.rf        libmusicbrainz.x86_64 0:2.1.5-11.1.el6       
  xvidcore.x86_64 0:1.2.2-1.el6.rf       

Complete!

This whole troubleshooting took quite a while, and I do not know if all the new packages are really needed, or if a subset is sufficient. Glad it's over, working and documented for a next time too (and possibly others).

Booting a Pogoplug with Fedora ARM

So, this week I received my Pogoplug, and it is currently running Fedora 13 for ARM (Beta-2). The Pogoplug has an ARM/Kirkwood board inside, just like a Sheevaplug and other Plug* computers. Below are some notes on how to get Fedora installed on an external USB-drive (and keeping most of the original Pogoplug software on it, but disabled).

The Fedora ARM Project provides a Beta root-disk for Fedora 13. Downloading the .tar.bz2 and extracting it to the first partition (formatted as ext3) of an USB-disk should make a good start for any Pogoplug related development.

The bootloader (u-boot) has been updated according to the well written instructions (includes a script for automation) from Jeff Doozan. The instructions are mainly targeted for Debian, but are a very useful source of information. Using the script, the bootloader gets replaced and it is possible to boot from an external USB-disk when placing the kernel (uImage) and initrd.img (uInitrd) under /boot on the USB-disk.

There is a kernel with initrd.img and modules available for ARM/Kirkwood boards. Unfortunately this kernel does not seem to fully boot on the Pogoplug. As there is no monitor or serial port connector on the outside of the pink box (who knows whats hidden inside), troubleshooting a boot issue is quite challenging. The updated u-boot supports netconsole. The output over netconsole shows that the kernel and initrd.img are loaded correctly and can be started. After which the kernel is supposed to take over the communication with any human being (or machine for that matters). Unfortunately the installation does not seem to get to a point where logs are written (checking the removable USB-storage after trying to boot). There is also no networking happening, eventhough the rootfs has been configured for DHCP.

Luckily there is an other kernel available for a GuruPlug (which is also a similar ARM board) which should function on any ARM/Kirkwoood. This specific kernel does not use an initrd/initramfs, so when trying to boot it, make sure to have only a /boot/uImage and no /boot/uInitrd. Booting a Pogoplug with the GuruPlug kernel-2.6.36.1 seems to work well:

Linux version 2.6.36.1 (root@Xion) (gcc version 4.4.1 (Sourcery G++ Lite 2010q1-202) ) #1 PREEMPT Mon Nov 29 06:21:49 EST 2010
CPU: Feroceon 88FR131 [56251311] revision 1 (ARMv5TE), cr=00053977
CPU: VIVT data cache, VIVT instruction cache
Machine: Marvell SheevaPlug Reference Board
Memory policy: ECC disabled, Data cache writeback
On node 0 totalpages: 65536
free_area_init_node: node 0, pgdat c058a5f4, node_mem_map c065e000
  Normal zone: 512 pages used for memmap
  Normal zone: 0 pages reserved
  Normal zone: 65024 pages, LIFO batch:15
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 65024
Kernel command line: console=ttyS0,115200 root=/dev/sda1 rootwait rootfstype=ext2 mtdparts=orion_nand:1M(u-boot),4M(uImage),32M(rootfs),-(data)
PID hash table entries: 1024 (order: 0, 4096 bytes)
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
Memory: 256MB = 256MB total
Memory: 253380k/253380k available, 8764k reserved, 0K highmem
...

Configuring the BeagleBoard to have network over usb0

After some experimenting, I have a kernel .config based on the kernel from the Angstrom BeagleBoard Demo. The original provided kernel with gether did not boot on my (loaned) BeagleBoard Rev B5. Only after disabling USB completely (kernel parameter nousb). As gether is the part I am most interested in, booting without USB is pretty pointless. Fortunately the kernel provides /proc/config.gz. Using this configuration, some little tuning (i.e. turning off the staging-modules because they do not compile), a kernel and suitable modules could be built.

Fedora almost expects using a initramfs for booting, and well, it surely makes troubleshooting easier! Getting dracut to run on a system where no network is available takes quite a lot of reboots (the BeagleBoard has one SD-slot for the filesystem, one mini-USB for power, a serial port for the console and nothing else that makes transport of files easy). Installing all the dependencies and disabling some dracut-modules /etc/dracut.conf (crypt dmraid mdraid multipath plymouth) in /etc/dracut.conf allows creating an initramfs.img. Before u-boot can use the initramfs.img, it needs to be converted with a command like:

# mkimage -A arm -O linux -T ramdisk -C none -e 0 -a 0 -n initramfs-2.6.38 -d /boot/initramfs-2.6.38.img /boot/uinitramfs-2.6.38.img

Currently, the generated files are on a VFAT-partition on an SD-card. This BeagleBoard boots from this card and uses the following settings to start the Fedora 13 ARM system:

OMAP3 beagleboard.org # printenv bootargs
bootargs=console=ttyO2,115200n8 root=/dev/mmcblk0p2 ro

OMAP3 beagleboard.org # printenv bootcmd
bootcmd=mmcinit ; fatload mmc 0:1 0x80000000 uimage-2.6.38 ; fatload mmc 0:1 0x81600000 uinitramfs-2.6.38.img ; bootm 0x80000000 0x81600000

OMAP3 beagleboard.org # boot

During boot, there are some messages that indicate that Ethernet-over-USB will be available:

[    0.334960] musb-hdrc: version 6.0, musb-dma, otg (peripheral+host), debug=0
[    0.335571] musb-hdrc musb-hdrc: USB OTG mode controller at fa0ab000 using DMA, IRQ 92
...
[    4.824340] g_ether gadget: using random self ethernet address
[    4.830505] g_ether gadget: using random host ethernet address
[    4.837341] usb0: MAC ba:98:d2:e3:60:36
[    4.841430] usb0: HOST MAC 4a:49:17:92:63:df
[    4.846008] g_ether gadget: Ethernet Gadget, version: Memorial Day 2008
[    4.853027] g_ether gadget: g_ether ready
[    4.857269] musb-hdrc musb-hdrc: MUSB HDRC host driver
[    4.863220] musb-hdrc musb-hdrc: new USB bus registered, assigned bus number 2
[    4.885742] usb usb2: New USB device found, idVendor=1d6b, idProduct=0002
[    4.892913] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    4.900543] usb usb2: Product: MUSB HDRC host driver
[    4.905792] usb usb2: Manufacturer: Linux 2.6.38 musb-hcd
[    4.911499] usb usb2: SerialNumber: musb-hdrc
...
[    5.383911] g_ether gadget: full speed config #1: CDC Ethernet (ECM)

The musb-hdrc is the controller-chip and the g_ether is the implementation of the USB-client side of the USB-over-Ethernet gadget. On my laptop the BeagleBoard gets detected as a "RNDIS/Ethernet Gadget" product from vendor "Linux 2.6.38 with musb-hdrc":

usb 1-1: new high speed USB device using ehci_hcd and address 66
usb 3-1: new full speed USB device using uhci_hcd and address 45
usb 3-1: not running at top speed; connect to a high speed hub
usb 3-1: New USB device found, idVendor=0525, idProduct=a4a2
usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 3-1: Product: RNDIS/Ethernet Gadget
usb 3-1: Manufacturer: Linux 2.6.38 with musb-hdrc
cdc_ether 3-1:1.0: usb0: register 'cdc_ether' at usb-0000:00:1a.0-1, CDC Ethernet Device, 4a:49:17:92:63:df
usb0: no IPv6 routers present
device usb0 entered promiscuous mode
virbr0: topology change detected, propagating
virbr0: port 1(usb0) entering forwarding state

The last lines are automatically triggered by my ifplugd-configuration which checks for usb0 devices and on a link, the usb0 is added to the virbr0 from libvirt so that BeagleBoard immediately gets access to the network.

On the side of the BeagleBoard, /etc/sysconfig/network-scripts/ifcfg-usb0 is configured to request an IP-address over DHCP:

DEVICE="usb0"
BOOTPROTO="dhcp"
ONBOOT="yes"
MACADDR="ba:98:d2:e3:60:36"

I prefer to give the BeagleBoard the same MAC-address on every boot, by default it is a random one. Setting MACADDR in ifcfg-usb0 makes this happen. The g_ether kernel-module accepts a MAC-address as parameter, but as the module is builtin, this is not convenient (pass g_ether.dev_addr as kernel parameter, or echo it to /sys/module/g_ether/parameters/dev_addr).

Enabling the network on boot and activating usb0 was the only thing left todo:

# chkconfig network on
# ifup usb0

The compiled kernel, initramfs and modules are available for download and re-use. Please report any issues or success if you try them out.

Now this is all written down, it seems really easy and quick. Keep in mind that compiling a very minimal kernel takes at least 120 minutes on the BeagleBoard, the kernel and modules from the Angstom distribution took much more... The BeagleBoard has since gained the elevated status of a mock-builder and rebuild java-1.5.0-gcj-1.5.0.0-32.fc13.bootstrap.src.rpm in "138 minutes 22 seconds", yay!

Archivemount is now in EPEL6

The only (for now) package I maintain, archivemount is now available in EPEL6 too. It has been in Fedora 14 for a while now, EPEL5 is following when libarchive is ready.

For those who have no idea what archivemount is:
Archivemount is a piece of glue code between libarchive and FUSE. It can be used to mount a (possibly compressed) archive (as in .tar.gz or .tar.bz2) and use it like an ordinary filesystem.

Serial ports with a BeagleBoard and a (newer) Linux 2.6.36 kernel

Today a Fedora 13 ARM Beta was released. This makes it obviously time for me to blog about my Fedora adventures from last weekend on my loaned BeagleBoard.

I managed to get kernel 2.6.38-rc3 compiled on a virtualized Qemu ARM system. Compiling the kernel really takes some time. A stripped down version, without compiling loadable modules took just over 880 minutes. An other test with make omap2plus_defconfig uImage took around 1400 minutes. I now believe the people that mentioned that the performance of a virtual system (on x86_64) is not very spectacular.

Booting the kernel, made my serial console unusable. A bug and patch has been filed for initscripts in Fedora 14 and below. Fedora 15 uses systemd and is likely not affected with the same. This kernel (well, actually from 2.6.36 an onwards) have a optimized serial-port implementation for OMAP-boards. This unfortunately does not use ttyS* for serial-ports, but ttyO*. Any application (including initscripts) expecting that serial-ports are starting with ttyS or other familiar identifiers, will need an update for the OMAP serial-port driver.

With the new beta release, I would need to rebuild initscripts with the patch that makes ttyO work as main console (giving console=ttyO2,115200n8 on the kernel command line). When all works fine, the boot process will be displayed on the serial-console and logging in works again.

Furthermore I found out how to boot the board in a more useful state than before. Passing the initramfs via u-boot does not seem to be very common, most sites advise to compile the initramfs into the kernel. I'd prefer to keep the standard Fedora way, and that means keeping kernel and initramfs seperate. It seems that u-boot needs a special kind of initramfs/initrd (possibly just a header added). This format can be created like the following:

mkimage -A arm -O linux -T ramdisk -C none -a 0x00000000 -e 0x00000000 -n initramfs -d initramfs-2.6.38-rc3.img uinitramfs-2.6.38-rc3.img

With this image, my Fedora 12 boots perfectly when setting the bootcmd to load both kernle + initramfs and passing both addresses via bootm

OMAP3 beagleboard.org # printenv 
stdin=serial
stdout=serial
stderr=serial
serial=3a5c00020000000004013ef109010017
bootargs=console=ttyO2,115200n8 root=/dev/mmcblk0p2 ro
bootcmd=mmcinit ; fatload mmc 0:1 0x80000000 uimage-2.6.38-rc3.beagleboard_201102131201 ; fatload mmc 0:1 0x81600000 uinitramfs-2.6.38-rc3.img ; bootm 0x80000000 0x81600000

Environment size: 309/131068 bytes

Some of these steps took quite a bit to figure out, but it looks like it's going to work a little bit more everytime.

More details on Fedora on a Beagleboard

It seems to be advised to build your own kernel for an ARM board. I have no idea yet if some kind of default kernel would (suboptimal) work, so I built a more fine-tuned kernel for the beagleboard. Luckily there was a default configuration for a beagleboard (make beagleboard_defconfig), sadly that default is not available in current kernels anymore. taking an old config and updating it a little, got me a recent kernel (2.6.38-rc3) that seems to work on the beagleboard.

After some more research through the kernel logs, it seems that the beagleboard_defconfig was renamed several times, currently it is available as omap2plus_defconfig. I probably need to build a new kernel now... Unfortunately it takes quite a while to build a new kernel on an emulated ARM board (I'm not into crosscompiling with a recent gcc version yet). The SD card I have is a little small, putting both the root filesystem and the kernel-sources on it seems difficult, an exercise I'll experiment with later.

The beagleboard uses u-boot as bootlader, and I have not found out how to use a initial RAM disk. This has not been an issue yet, as I did not feel like creating an initial RAM disk by hand. Fedora comes with dracut that can generate one for me, so why bother?

The current kernel has all requirements built-in. There is no need for an initial RAM disk. Well, actually there is... init seems to require the /proc fileystem mounted, if it is not mounted, init decides to reboot the system as there are some process-communication issues. Starting with an emergency shell (pass init=/bin/dash on the commandline) allows me to manually mount /proc (even if it claims to be mounted already).

Compared to an older version of the kernel, this kernel offers options to enable optimized OMAP-serial ports:

CONFIG_SERIAL_OMAP=y
CONFIG_SERIAL_OMAP_CONSOLE=y

With these options enabled, the standard /dev/ttyS2 does not seem to provide any output. Instead it seems to be required to use the OMAP-specific /dev/ttyO2 (that's an 'O' for Oscar, not a '0' as zero).

My final u-boot defaults (saved with saveenv) looks like this:

OMAP3 beagleboard.org # printenv
stdin=serial
stdout=serial
stderr=serial
serial=3a5c00020000000004013ef109010017
bootargs=console=ttyO2,115200n8 root=/dev/mmcblk0p2 ro rootwait init=/bin/dash
bootcmd=mmcinit ; fatload mmc 0:1 0x80000000 uimage-2.6.38-rc3.beagleboard_201102131201 ; bootm 0x80000000

Environment size: 267/131068 bytes

Booting the system and starting dash as directed by the init parameter can be done as follows:

OMAP3 beagleboard.org # boot
## Booting kernel from Legacy Image at 80000000 ...
   Image Name:   Linux-2.6.38-rc3.beagleboard
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    1751256 Bytes =  1.7 MB
   Load Address: 80008000
   Entry Point:  80008000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.
Linux version 2.6.38-rc3.beagleboard (root@fedora-arm) (gcc version 4.4.2 20091019 (Red Hat 4.4.2-5) (GCC) ) #2 Sun Feb 13 22:26:07 EST 2011
CPU: ARMv7 Processor [411fc082] revision 2 (ARMv7), cr=10c53c7f
CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
Machine: OMAP3 Beagle Board
Memory policy: ECC disabled, Data cache writeback
OMAP3430/3530 ES2.1 (l2cache iva sgx neon isp )
SRAM: Mapped pa 0x40200000 to va 0xfe400000 size: 0x10000
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 32512
Kernel command line: console=ttyO2,115200n8 root=/dev/mmcblk0p2 ro rootwait init=/bin/dash
PID hash table entries: 512 (order: -1, 2048 bytes)
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Memory: 128MB = 128MB total
Memory: 126296k/126296k available, 4776k reserved, 0K highmem
Virtual kernel memory layout:
    vector  : 0xffff0000 - 0xffff1000   (   4 kB)
    fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
    DMA     : 0xffc00000 - 0xffe00000   (   2 MB)
    vmalloc : 0xc8800000 - 0xf8000000   ( 760 MB)
    lowmem  : 0xc0000000 - 0xc8000000   ( 128 MB)
    modules : 0xbf000000 - 0xc0000000   (  16 MB)
      .init : 0xc0008000 - 0xc002b000   ( 140 kB)
      .text : 0xc002b000 - 0xc033d000   (3144 kB)
      .data : 0xc033e000 - 0xc0369480   ( 174 kB)
NR_IRQS:402
Clocking rate (Crystal/Core/MPU): 26.0/332/500 MHz
Reprogramming SDRC clock to 332000000 Hz
GPMC revision 5.0
IRQ: Found an INTC at 0xfa200000 (revision 4.0) with 96 interrupts
Total of 96 interrupts on 1 active controller
OMAP clockevent source: GPTIMER12 at 32768 Hz
sched_clock: 32 bits at 32kHz, resolution 30517ns, wraps every 131071999ms
Console: colour dummy device 80x30
Calibrating delay loop... 471.61 BogoMIPS (lpj=1843200)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok
print_constraints: dummy: 
NET: Registered protocol family 16
omap_device: omap_gpio.0: new worst case activate latency 0: 30517
OMAP GPIO hardware version 2.5
OMAP GPIO hardware version 2.5
OMAP GPIO hardware version 2.5
OMAP GPIO hardware version 2.5
OMAP GPIO hardware version 2.5
OMAP GPIO hardware version 2.5
omap_mux_init: Add partition: #1: core, flags: 0
OMAP3 Beagle Rev: unknown 3
omap_device: omap_uart.0: new worst case activate latency 0: 30517
omap_device: omap_uart.0: new worst case deactivate latency 0: 30517
Found NAND on CS0
Registering NAND on CS0
Unable to get DVI reset GPIO
OMAP DMA hardware revision 4.0
bio: create slab  at 0
SCSI subsystem initialized
omap_device: omap_i2c.1: new worst case activate latency 0: 30517
omap_i2c omap_i2c.1: bus 1 rev3.12 at 2600 kHz
twl4030: PIH (irq 7) chaining IRQs 368..375
twl4030: power (irq 373) chaining IRQs 376..383
twl4030: gpio (irq 368) chaining IRQs 384..401
print_constraints: VUSB1V5: 1500 mV normal standby
print_constraints: VUSB1V8: 1800 mV normal standby
print_constraints: VUSB3V1: 3100 mV normal standby
twl4030_usb twl4030_usb: Initialized TWL4030 USB module
print_constraints: VMMC1: 1850 <--> 3150 mV at 3000 mV normal standby
print_constraints: VDAC: 1800 mV normal standby
print_constraints: VDVI: 1800 mV normal standby
print_constraints: VSIM: 1800 <--> 3000 mV at 1800 mV normal standby
omap_i2c omap_i2c.3: bus 3 rev3.12 at 100 kHz
Switching to clocksource 32k_counter
Switched to NOHz mode on CPU #0
musb-hdrc: version 6.0, tusb-omap-dma, peripheral, debug=0
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 4096 (order: 3, 32768 bytes)
TCP bind hash table entries: 4096 (order: 2, 16384 bytes)
TCP: Hash tables configured (established 4096 bind 4096)
TCP reno registered
UDP hash table entries: 256 (order: 0, 4096 bytes)
UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
NET: Registered protocol family 1
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
NetWinder Floating Point Emulator V0.97 (double precision)
JFFS2 version 2.2. (NAND) © 2001-2006 Red Hat, Inc.
msgmni has been set to 246
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
omap_uart.0: ttyO0 at MMIO 0x4806a000 (irq = 72) is a OMAP UART0
omap_uart.1: ttyO1 at MMIO 0x4806c000 (irq = 73) is a OMAP UART1
omap_uart.2: ttyO2 at MMIO 0x49020000 (irq = 74) is a OMAP UART2
console [ttyO2] enabled
brd: module loaded
loop: module loaded
twl_rtc twl_rtc: rtc core: registered twl_rtc as rtc0
omap_device: omap_i2c.1: new worst case deactivate latency 0: 30517
i2c /dev entries driver
sdhci: Secure Digital Host Controller Interface driver
sdhci: Copyright(c) Pierre Ossman
TCP cubic registered
NET: Registered protocol family 17
NET: Registered protocol family 15
VFP support v0.3: implementor 41 architecture 3 part 30 variant c rev 1
omap_voltage_late_init: Unable to create voltage debugfs main dir
vdd_debugfs_init: Unable to create debugfs directory for vdd_mpu
vdd_debugfs_init: Unable to create debugfs directory for vdd_core
Power Management for TI OMAP3.
regulator_init_complete: VDVI: incomplete constraints, leaving on
regulator_init_complete: VDAC: incomplete constraints, leaving on
twl_rtc twl_rtc: setting system clock to 2000-01-01 00:03:14 UTC (946684994)
Waiting for root device /dev/mmcblk0p2...
mmc0: new SD card at address 9ced
mmcblk0: mmc0:9ced SD02G 1.89 GiB 
 mmcblk0: p1 p2
EXT3-fs: barriers not enabled
kjournald starting.  Commit interval 5 seconds
EXT3-fs (mmcblk0p2): mounted filesystem with writeback data mode
VFS: Mounted root (ext3 filesystem) readonly on device 179:2.
Freeing init memory: 140K
/bin/dash: can't access tty; job control turned off
# 

The way to boot into a multi-user system (or change the runlevel so something else) was the following:

# mount /proc
# mount /sys
# exec init

Unfortunately it looks as if upstart or udev from Fedora 12 does not recognise the /dev/ttyO* as serial console. Of course I do not have the possibility (hte beagleboard has, just I do not) to connect a monitor over HDMI or S-video and serial-console is the only working output available. Yet another thing to look into some other day.