Fedora

Hans wrote about a different way of preparing a bootable USB stick for a Fedora installation then I did in Installing Fedora 9 from a (small) USB stick.
Unfortunately, his blogpost is set to only accept comments from "friends" and does not even accept the Fedora OpenID url as a "friend". :-( Thus I'll reply as an article:

While my recipe wrote the data directly onto the USB stick without creating any partitions ont it, Hans suggests to format the USB stick similar to a normal hard drive with a Master Boot Record and a single partition holding the data. This is based on the hope that it makes it more likely that the stick is in fact bootable.

Fedora, and in extension Red Hat Linux before it, has always created partition-less diskboot.img files. The commands I listed in my article are taken directly from the sourcecode of the anaconda-runtime scripts, which have in the past generated the shipped diskboot.img file.

I might not remember the exact date but I'm certain I've been booting installation images from USB sticks for more than 5 years now and never had a problem with the partition-less disk-image as found on the installation CDs in the /images-folder.
In fact, I remember some problems with an older EPIA-M board which absolutely refused to boot from an USB stick formatted as either a hard-drive or a ZIP-drive with the data contained on the 4th partition.
But that was in 2003 and I'd really expect current BIOS implementations to correctly boot from whatever disk is plugged in. Yeah, right...

While working with the "new" ASUS Pundit-R350 I found the IO performance of the system severely lacking.

When doing anything IO heavy on the box system load goes up and the system becomes basically unresponsive. I noticed that while preparing an image for an USB stick:

[root@workstation ~]# dd if=/dev/zero of=usbstick.img count=1024 bs=1M
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 300.266 s, 3.6 MB/s
[root@workstation ~]# uptime
 14:51:02 up 7 min,  2 users,  load average: 4.53, 3.63, 1.66
[root@workstation ~]#

3.6 MB/s transfer rate is completely unacceptable. I'm feeling as if 1994 called and asked for the Red Hat Linux 3.0.3 (Picasso) install CDs.
To solve this mystery, why a SATA disk is running that slow a bit of digging is needed.

Usually, such slow IO access means the drive in question is not using DMA transfer but one of the slower PIO modes.
This can be checked with the hdparm utility:

[root@workstation ~]# hdparm -I /dev/sda | grep '[DP][MI][AO]:'
	DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 ∗udma5 udma6 
	PIO: pio0 pio1 pio2 pio3 pio4 
[root@workstation ~]# 

As can be seen, the udma5 entry has an asterisk in front of it, identifying the currently used transfer mode is in fact UDMA/100.
Considering the claimed transfer mode and the actual speed I'd suspect a kernel problem. The tool for viewing the kernel log is dmesg. Using this command in combination with grep allows one to quickly find anything related to ata:

[root@workstation ~]# dmesg | grep ata
 BIOS-e820: 000000003bf40000 - 000000003bf50000 (ACPI data)
Memory: 965836k/982272k available (2233k kernel code, 15736k reserved, 1120k data, 284k init, 64768k highmem)
      .data : 0xc062e7b5 - 0xc0746800   (1120 kB)
Write protecting the kernel read-only data: 908k
libata version 3.00 loaded.
scsi0 : pata_atiixp
scsi1 : pata_atiixp
ata1: PATA max UDMA/100 cmd 0x1f0 ctl 0x3f6 bmdma 0xff00 irq 14
ata2: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0xff08 irq 15
ata1.00: ATAPI: _NEC DVD_RW ND-4550A, 1.06, max UDMA/33
ata1.00: configured for UDMA/33
ata2.00: ATA-7: ST3250823AS, 3.03, max UDMA/133
ata2.00: 488397168 sectors, multi 16: LBA48 NCQ (depth 0/32)
ata2.00: simplex DMA is claimed by other device, disabling DMA
ata2.00: configured for PIO4
EXT3-fs: mounted filesystem with ordered data mode.
[root@workstation ~]#

The line ata2.00: simplex DMA is claimed by other device, disabling DMA and ata2.00: configured for PIO4 explain the problem. The disk was in fact only being accessed by one of the PIO modes. Googling for the first line, gives several results. Of interest are the different hits from the Arch-Linux, the Ubuntu and the Fedora forums. Seems other people have the same problems. The first hit however is from the Ubuntu Wiki suggesting that the problem is caused by the ata_generic module which prevents the pata_atiixp module from correctly driving the interface.

It quickly turns out however, that the wiki entry is incorrect and the forums are completely useless as nobody really looked into the issue at all. Koen, explains this nicely.

A bit of googling for Simplex DMA shows that the kernel driver is simply buggy/the way fedora loads sata drivers is buggy.
Happily, cebbert (one of our kernel wranglers) already applied a patch fixing this problem.

This nicely shows that even though fedora's way of trailing the bleeding edge quite closely may lead to strange hardware problems from time to time, the fix is usually pretty quickly applied.
Considering that the relatively large number of users allows for a larger testing base and therefore improving the software for every user in the long run I find this is an acceptable compromise.

I've recently started to unpack some of the boxes from my last move. In there I found an older Booksize PC, an ASUS Pundid-R350. It's not the nicest system I've ever had, the fan is incredibly noisy and it's constantly switching to full speed when the system is loaded. I guess I should swap the fan for something much quieter, but haven't had the time yet.

It took me some time to figure out the correct settings to have lm_sensors running on the device as there's been no template configuration to be found on google. To rectify this omission, I'm dumping mine on my blog:

# Asus Pundit-R350
chip "it8712-∗"

# Voltage monitors as advised in the It8705 data sheet

    label in0 "VCore 1"
    label in2 "+3.3V"
    label in3 "+5V"
    label in4 "+12V"

    # Seem not to be connected on the Pundit-R
    ignore in1
    ignore in5
    ignore in6
    ignore in7
    ignore in8
    ignore cpu0_vid

    compute in3 ((6.8/10)+1)∗@ ,  @/((6.8/10)+1)
    compute in4 ((30/10) +1)∗@  , @/((30/10) +1)

# Set some upper and lower limits

    set in0_min 1.4 ∗ 0.95
    set in0_max 1.4 ∗ 1.05
    set in2_min 3.3 ∗ 0.95
    set in2_max 3.3 ∗ 1.05
    set in3_min 5.0 ∗ 0.95
    set in3_max 5.0 ∗ 1.05
    set in4_min 12 ∗ 0.95
    set in4_max 12 ∗ 1.05

# Temperature
    label temp1       "CPU Temp"
    set temp1_type 3
    set   temp1_max   75
    set   temp1_min   15
    label temp2       "M/B Temp"
    set temp2_type 2
    set   temp2_max   55
    set   temp2_min   15
    ignore temp3

# Fans
   set fan1_div 2
   set fan1_min 2500
   ignore fan2
   ignore fan3

With this configuration written to /etc/sensors3.conf the freshly installed fedora 9 system correctly shows some sensible sensor readings:

[root@workstation ~]# sensors
it8712-isa-0260
Adapter: ISA adapter
VCore 1:     +1.39 V  (min =  +1.33 V, max =  +1.47 V)
+3.3V:       +3.26 V  (min =  +3.14 V, max =  +3.47 V)
+5V:         +5.00 V  (min =  +4.76 V, max =  +5.24 V)
+12V:       +12.03 V  (min = +11.39 V, max = +12.61 V)
fan1:       3994 RPM  (min = 2657 RPM, div = 2)
CPU Temp:    +65.0°C  (low  = +15.0°C, high = +75.0°C)  sensor = thermal diode
M/B Temp:    +50.0°C  (low  = +15.0°C, high = +55.0°C)  sensor = transistor

[root@workstation ~]# 

My notebook is running on Red Hat Enterprise Linux. 5.2 This is very nice on the one hand, as I do have stable software and it's very unlikely that I'll kill my system with a yum update call right before having a presentation. That happened in the past when running rawhide, but that's perfectly okay. I just have different requirements now.
On the other hand, being on a stable operating system means I'm not having access to the latest and greatest releases of all software. A problem users on Debian stable are well acquainted with.

One of the problems I'm having is with NetworkManager 0.6.4-8.el5. One of the wireless networks I'm using is changing it's keys each quarter. This is actually a good idea. Unfortunately, NetworkManager on some systems seems not to be able to associate to the wireless network after the first keychange.
It's trying again and again to associate, asks for a new password but even though the new password/hex-key is entered, no association is possible.

A quick workaround is possible though requiring removal of the password and the network data from the Gnome keyring as well as the gconf registry. After this has been done, NetworkManager is able to associate with the wireless network:

Make sure that the gnome-keyring-manager as well as the gconftool-2 binaries are installed:

[root@localhost ~]# rpm -q gnome-keyring-manager GConf2
gnome-keyring-manager-2.16.0-3.el5
GConf2-2.14.0-9.el5
[root@localhost ~]#

The next step is to remove the wireless network from the Gnome registry with the help of gconftools-2. Substitute <network-name> accordingly:

[athienem@localhost ~]$ gconftool-2 --recursive-unset /system/networking/wireless/networks/<network-name>
[athienem@localhost ~]$

The next step is to fire up gnome-keyring-manager from the shell or the Applications-menu under "System-Tools". Navigate to the entry named "Passphrase for wireless network <network-name>", select it and click on the "Keyring" entry in the menu and choose "Delete Key".
Close gnome-keyring-manager.

You're done. Now NetworkManager has lost all knowledge about the existing wireless network and the entry can be added again as usual. NM should be able to associate then.

With the release of Fedora 9, anaconda has introduced a new consolidated boot image:

"Consolidated network booting ISO image, replacing old boot.iso, diskboot.img, and rescuecd.iso."

The problem with this approach is, that the 12MB diskboot.img file has disappeared, which could be used to boot a system with a small USB stick. Awesome! Thank you very much. ∗facepalm.jpg∗

But luckily, it is not very hard to recreate this file on the shell and write it onto an USB stick afterwards. This serves as another installment of my small article series announced earlier.

I started with the boot.iso image which I downloaded from http://download.fedoraproject.org/pub/fedora/linux/releases/9/Fedora/i386/os/images/boot.iso and loopback mounted on /mnt:

[root@localhost ~]# wget -q -c
http://download.fedoraproject.org/pub/fedora/linux/releases/9/Fedora/i386/os/images/boot.iso
[root@localhost ~]# mount boot.iso /mnt -o loop,ro
[root@localhost NotBackedUp]# ls /mnt/
images  isolinux
[root@localhost NotBackedUp]# 

Now the steps to create the USB pendrive image are quite simple. A file is created, formatted and made bootable with syslinux and the appropriate files from the boot.iso are copied over:

[root@localhost ~]# cd /tmp/
[root@localhost tmp]# mkdir pendrive
[root@localhost tmp]# cd pendrive/
[root@localhost pendrive]# dd if=/dev/zero of=diskboot.img bs=1M count=12
12+0 records in
12+0 records out
12582912 bytes (13 MB) copied, 0.0433931 seconds, 290 MB/s
[root@localhost pendrive]# mkdosfs diskboot.img 
mkdosfs 2.11 (12 Mar 2005)
[root@localhost pendrive]# syslinux diskboot.img 
[root@localhost pendrive]# mkdir mount
[root@localhost pendrive]# mount diskboot.img mount/ -o loop
[root@localhost pendrive]# cp -r /mnt/isolinux/∗ mount/
[root@localhost pendrive]# grep -v local mount/isolinux.cfg > mount/syslinux.cfg
[root@localhost pendrive]# rm -f mount/isolinux.∗
[root@localhost pendrive]# umount -f mount
[root@localhost pendrive]# rm -rf mount/
[root@localhost pendrive]# cd
[root@localhost ~]# umount -f /mnt
[root@localhost ~]#

After these steps, a diskboot.img file is located in /tmp/pendrive. This file can be written to an USB stick with a command such as dd if=diskboot.img of=/dev/sdb. Special care should be taken to write to the correct device (/dev/sdb in this case)and _not_ overwrite one of your own harddrives.

When working with disk images the admin is often faced with the problem of mounting the contained partitions inside of these images.

Such full-disk images can be the containers of virtual machines for xen as fount in /var/lib/xen/images or disk-images ripped from dying drives with the help of recovery tools such as dd_rescue.

Regardless of the origin, these images do contain everything needed to run a machine, a partition table, a boot sector, at least one, but often several partitions inside of one container.
Mounting these images through a normal loop mount does only result in the first image to be mounted, often not what is wanted.
In the past, suggestions ranged from imaging single partitions to using dd to "cut" the single partitions out of the full-disk image. Crude workarounds as we've had a perfect tool called device mapper for some time now.

Executing fdisk on the my test disk-image shows several partitions, among some ingorable warnings:

[root@workstation ~]# fdisk -l disk.img 
You must set cylinders.
You can do this from the extra functions menu.

Disk disk.img: 0 MB, 0 bytes
4 heads, 32 sectors/track, 0 cylinders
Units = cylinders of 128 ∗ 512 = 65536 bytes
Disk identifier: 0x00000000

   Device Boot      Start         End      Blocks   Id  System
disk.img1   ∗           1          32        2032   83  Linux
disk.img2              33         216       11776   83  Linux
disk.img3             217         705       31296   83  Linux
disk.img4             706         978       17472    5  Extended
disk.img5             706         859        9840   83  Linux
disk.img6             860         978        7600   83  Linux
[root@workstation ~]# 

Thus, we know we do have an image file containing several partitions.

Now, how to handle this?

Mounting this test-image gives an error in my case. Often though the first partition gets sucessfully mounted.

[root@workstation ~]# mount disk.img /mnt/ -t ext2 -o loop,ro
mount: wrong fs type, bad option, bad superblock on /dev/loop1,
       missing codepage or helper program, or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so

[root@workstation ~]# 

The solution to this is called kpartx, a tool to map the partitions contained inside such an image into device-mapper block devices. This tools is contained in the kpartx RPM and can be easily installed by executing yum install kpartx if it is not already installed on your system.

Execution is quite simple. To list the contained partitions and see onto which loop-devices they would be mapped, the following command is needed:

[root@workstation ~]# kpartx -l disk.img 
loop0p1 : 0 4064 /dev/loop0 32
loop0p2 : 0 23552 /dev/loop0 4096
loop0p3 : 0 62592 /dev/loop0 27648
loop0p5 : 0 19680 /dev/loop0 90272
loop0p6 : 0 15200 /dev/loop0 109984
[root@workstation ~]# 

To actually map these partitions onto the loop-devices, call kpartx with the -a instead of the -l parameter:

[root@workstation ~]# kpartx -a -v disk.img 
add map loop0p1 : 0 4064 linear /dev/loop0 32
add map loop0p2 : 0 23552 linear /dev/loop0 4096
add map loop0p3 : 0 62592 linear /dev/loop0 27648
add map loop0p5 : 0 19680 linear /dev/loop0 90272
add map loop0p6 : 0 15200 linear /dev/loop0 109984
[root@workstation ~]# 

The partitions are then available in /dev/mapper/ to be mounted accordingly and the containing files to be accessed:

[root@workstation ~]# ls -all /dev/mapper/
total 0
drwxr-xr-x  2 root root     160 2008-06-11 15:06 .
drwxr-xr-x 13 root root    4180 2008-06-11 15:06 ..
crw-rw----  1 root root  10, 60 2008-06-11 13:28 control
brw-rw----  1 root disk 253,  0 2008-06-11 15:06 loop0p1
brw-rw----  1 root disk 253,  1 2008-06-11 15:06 loop0p2
brw-rw----  1 root disk 253,  2 2008-06-11 15:06 loop0p3
brw-rw----  1 root disk 253,  3 2008-06-11 15:06 loop0p5
brw-rw----  1 root disk 253,  4 2008-06-11 15:06 loop0p6
[root@workstation ~]# 
[root@workstation ~]# mount /dev/mapper/loop0p5 /mnt/ -o loop,ro
[root@workstation ~]# mount | grep '/mnt'
/dev/mapper/loop0p5 on /mnt type ext2 (ro,loop=/dev/loop1)
[root@workstation ~]# ls /mnt/
backup  conf.tar.gz     etc                  manifest.txt  tool
bin     default.list    factory_default.md5  rc.reboot     upgrade.list
cfg     default.tar.gz  lost+found           test
[root@workstation ~]# 

After the partitions have been unmounted, the device-mapper mappings can be removed by calling kpartx with the -d parameter. The image file can then be used again as it is not in use anymore by the device mapper.

[root@workstation ~]# umount /mnt/
[root@workstation ~]# kpartx -d -v disk.img 
del devmap : loop0p1
del devmap : loop0p2
del devmap : loop0p3
del devmap : loop0p5
del devmap : loop0p6
loop deleted : /dev/loop0
[root@workstation ~]# ls -al /dev/mapper/
total 0
drwxr-xr-x  2 root root     60 2008-06-11 15:16 .
drwxr-xr-x 13 root root   4080 2008-06-11 15:16 ..
crw-rw----  1 root root 10, 60 2008-06-11 13:28 control
[root@workstation ~]# 

I finally decided to try to breath some life into my weblog again and write some hopefully useful technical articles.

I'm currently planning on concentrating on stuff I find out fiddling with new toys (usually embedded stuff running Linux) or little hints or tricks I'm using when administrating systems.

The content of these articles might not all be new and many people already know about them, but I found it's mostly "advanced" administration stuff many people do not know about and can profit from these.

If there's anything which should be described in more detail or anything else, I'm available on the usual IRC networks (IRCnet, oftc, freenode etc.) as ixs.

The first article explains kpartx and how to use it to access partitions inside full-disk images.

We've gotten a new document scanner for bawue.net in order to better handle our documents and our snail-mail communication.
The Canon ScanFront 220P is a network scanner which does (among other things) optical character recognition and is able to send the resulting document as a PDF via e-Mail or upload it to a FTP Server or a SMB Network share.

The device itself is running Windows CE in order to accomplish all that which is fine as it therefore needs no computer connected to it as some other scanners do.

A real problem for the Linux user howerver is that Canon seems to have handed the development of the scanner's web interface to some clueless and moronic developers.
There's simply no excuse for designing a web interface which only works with Internet Explorer and doesn't even allow a Firefox user to log into the interface.
I'd expect MUCH better from a global company such as Canon, especially when the scanner in question costs about US$ 2,150.00

If the device would have been running Linux and the sources would have been delivered as requested by the GPL I'd have a working scanner here and Canon's development team would have had a nice unified diff in the mail fixing their problems. That way, all they are getting is an acrid mail.
Another reason to favour open source operating systems for any development work. Some companies seem to clearly get this.

In the meantime tough I need a working scanner. Greasemonkey to the rescue: I've written a small GPL3 licensed Greasemonkey User script fixing the problems in the ScanFront webinterface. Naturally, one has to have greasemonkey installed to use this script.

It currently fixes the login prompt, makes the "New User" button work, fixes an onload-recursion in the address book and makes the job-control window work when selecting the destination address for a scanjob.
Most of these problems stem from the fact that the Internet Explorer XML parser seems to be somewhat sloppy and does not make a difference by getElementById and getElementsByName.
My userscript works around these issues but a real fix can only be delivered by Canon.

Today was my first day as a Red Hat employee.

Even though I'm just working there as an intern for the next six months before starting work on my Diploma thesis, it has been rather uneventful.

Ohh right, today is saturday. Weekends for teh win!
So I'll start on monday then with the "New Hire Orientation" in Munich. According to the guys on irc, it's gonna be fun.

Yeah, right!

Michael linked to an IAT Test which claims to be able to find out your unconscious preference for either Microsoft Software or Open-Source software, ruling out self-presentation or controlled responding.
Wikipedia has somewhat more about the Implicit Association Test.

In this case, the participant is asked to please sort stimulus words (Joy, Evil etc.) and pictures (Tux, Firefox Logo, Microsoft Word Logo and similar). By combining "good" stimuli with "bad" attitudes and measuring response time and comparing the results from the test round where "good" stimuli is paired with "good" attitudes the IAT claims to be able to offer insight into a person, regardless of his self-reports.

I am quite wary of tests such as these as I believe them to be useless against a participant who intends to game the test. Especially if the test claims to be objective.

The first trial I did resulted in being attested to have "a strong automatic preference for Open Source products over Microsoft products".
This sounds about right.

The second trial, I tried gaming the system. As the participant is asked to sort the words and images into two combined groups which change, it was clear that the IAT test is based on reaction measurements. If sorting the words into the "Microsoft + Good" group is being done faster by the participant then sorting the words into the "Microsoft + Bad" group (compared to the "OSS + Good" group vs "OSS + Bad" group), it is assumed that the association between good and Microsoft is closer then the association between bad and Microsoft. Thus the user has a unconscious preference for Microsoft.

This much I gathered by guessing and the result was that I consciously delayed my responses at the appropriate time, thus resulting in a slight preference for Microsoft over OSS.

A short Google-Search later I was reading a paper by Klaus Fiedler and Matthias Blümke from the University of Heidelberg confirming my speculation and resulting in the third test run certifying "a moderate automatic preference of Microsoft over Open Source Software"...

So much for the test. :-)

Warren wondered whether it would make any sense including a version of scp or ssh which do not encrypt their traffic on the network.

As far as I can see, such a tool would indeed be useful for many tasks. "brokensh" might not be that useful, but "brokencp" is certainly useful.
Consider the roadwarrior with his notebook who is transferring some data from the server to his notebook. He is already encrypting the data-traffic by using openvpn or ipsec. The network between his tunnel-terminator and the server can be considered secure. He would save CPU-time by not having to encrypt the traffic twice.
Or the system-administrator who has to copy a whole tree of files, including permissions from one machine to another. He could just call tar c /dir | ssh root@server tar xv to achieve this. If the machines are directly connected the transfer is probably faster, as the data does not need to be encrypted. Generally, I do help myself in this case by using netcat, but still.

I for one do like the idea of selectivly disabling encryption for scp as long as the authentication against the remote system is secure, that is no cleartext password crosses the wire. I do not care if the attacker sniffing my line is able to reconstruct the latest Fedora ISO image which I'm copying, I do care that he is not able to sniff my password.

I tried the free as in beer vmware-server on our new quad opteron and probably got exactly what I deserved when using tainted modules. :-)

general protection fault: e040 [1] SMP
<Jan/04 01:48 am>last sysfs file: /class/scsi_host/host0/stats
<Jan/04 01:48 am>CPU 0
<Jan/04 01:48 am>Modules linked in: ipmi_devintf ipmi_si ipmi_msghandler vmnet(U) vmmon(U) ipv6 
ip_conntrack_netbios_ns ipt_REJECT xt_state ip_conntrack nfnetlink xt_tcpudp iptable_filter ip_tables
x_tables video sbs i2c_ec i2c_core button battery asus_acpi ac parport_pc lp parport st sg e100
serio_raw pcspkr ide_cd k8_edac mii cdrom edac_mc floppy tg3 shpchp dm_snapshot dm_zero dm_mirror
dm_mod sym53c8xx scsi_transport_spi 3w_9xxx sd_mod scsi_mod ext3 jbd ehci_hcd ohci_hcd uhci_hcd
<Jan/04 01:48 am>Pid: 2317, comm: vmware-vmx Tainted: P      2.6.18-1.2747.el5xen #1
<Jan/04 01:48 am>RIP: e030:[<ffffffff88395db1>]  [<ffffffff88395db1>] :vmmon:Task_Switch_S1B1+0x183/0x976
<Jan/04 01:48 am>RSP: e02b:ffff8801e79c7bb8  EFLAGS: 00010282
<Jan/04 01:48 am>RAX: ffff820000000000 RBX: ffffc2000003d000 RCX: 000000000000e040
<Jan/04 01:48 am>RDX: ffff82000000e040 RSI: 0000000000000000 RDI: ffff8801e9bf6000
<Jan/04 01:48 am>RBP: 00002aaaada80a80 R08: 7fffffff00000001 R09: 0000000000000000
<Jan/04 01:48 am>R10: ffff8801e79c7e98 R11: 0000000000000048 R12: ffffffff8058e000
<Jan/04 01:48 am>R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000660
<Jan/04 01:48 am>FS:  00002aaaada80a80(0000) GS:ffffffff8058e000(0063) knlGS:0000000000000000
<Jan/04 01:48 am>CS:  e033 DS: 002b ES: 002b
<Jan/04 01:48 am>Process vmware-vmx (pid: 2317, threadinfo ffff8801e79c6000, task ffff8801ee6fd040)
<Jan/04 01:48 am>Stack:  736282f99c4145dc  000000009d53f5e8  ffff8801e9bf6000  0000000000000246
<Jan/04 01:48 am> 000000008005003b  00002aaaabb65290  00000000b41c1cc3  0000006300005eaf
<Jan/04 01:48 am> 820000000000efff  ef980ea576c5ffff
<Jan/04 01:48 am>Call Trace:
<Jan/04 01:48 am> [<ffffffff883994eb>] :vmmon:Vmx86_RunVM_S1B1+0x3f/0x1a8
<Jan/04 01:48 am> [<ffffffff8838c21e>] :vmmon:__LinuxDriver_Ioctl+0x387/0xd35
<Jan/04 01:48 am> [<ffffffff8027f6f0>] __wake_up_common+0x3e/0x68
<Jan/04 01:48 am> [<ffffffff8022e141>] __wake_up+0x38/0x4f
<Jan/04 01:48 am> [<ffffffff80260729>] _spin_lock_irqsave+0x9/0x14
<Jan/04 01:48 am> [<ffffffff802976dd>] futex_wake+0xc6/0xd5
<Jan/04 01:48 am> [<ffffffff803045f9>] avc_has_perm+0x43/0x55
<Jan/04 01:48 am> [<ffffffff8838daf7>] :vmmon:LinuxDriver_Ioctl+0x529/0x583
<Jan/04 01:48 am> [<ffffffff8030512d>] inode_has_perm+0x56/0x63
<Jan/04 01:48 am> [<ffffffff803045f9>] avc_has_perm+0x43/0x55
<Jan/04 01:48 am> [<ffffffff8026a78d>] monotonic_clock+0x35/0x7b
<Jan/04 01:48 am> [<ffffffff803051ce>] file_has_perm+0x94/0xa3
<Jan/04 01:48 am> [<ffffffff8838db74>] :vmmon:LinuxDriver_CompatIoctl+0x23/0x36
<Jan/04 01:48 am> [<ffffffff802d7230>] compat_sys_ioctl+0xc5/0x2b1
<Jan/04 01:48 am> [<ffffffff8025d54d>] ia32_sysret+0x0/0xa
<Jan/04 01:48 am> [<ffffffff8025d4e2>] ia32_syscall+0x1e/0x6b


<Jan/04 01:48 am>Code: 0f b6 42 05 83 e0 0f 83 f8 0b 75 0c 8a 42 05 83 e0 f0 83 c8
<Jan/04 01:48 am>RIP  [<ffffffff88395db1>] :vmmon:Task_Switch_S1B1+0x183/0x976
<Jan/04 01:48 am> RSP <ffff8801e79c7bb8>
<Jan/04 01:48 am> <0>Kernel panic - not syncing: Fatal exception
<Jan/04 01:48 am> (XEN) Domain 0 crashed: rebooting machine in 5 seconds.

I fear I'll have to look into xen a bit more and use that in the meantime.

UPDATE: Turns out, it's currently impossible to do what I want:

• Xen and VMware are impossible to run at the same time
• Running ia32 guest inside of a x86_64 Xen instance does not work. It seems to be a planned feature though.
• qemu is slow and the binary kernel accelerator does not work on x86_64

I guess I'll just have to disable Xen for now and go with vmware until I have new hardware for the soon to be virtualized host. :(

At this last year's Chaos Communication Congress in Berlin there was a short presentation about the One Laptop Per Child system.

I couldn't make the talk itself but managed to take a closer look at the OLPC later on when it was on display at the Wikipedia booth.
My opinion of the device so far is mixed.
The software collection looks nice but still a bit rough about the edges.
The hardware in general definitely looks good. Small, portable and low-power. The display especially is really good looking and offers an enjoyable sharp display. I expected something a bit more low quality after following the swizzle mode blog post by Manu but was positivly surprised.
The keyboard however sucked!

I might be spoiled keyboardwise as I'm nearly exclusivly using IBM Model M Keyboards which feature distinct tactile feedback and I really detest the soft keyboards which are generally available today.

The OLPC keyboard however is something else. I haven't yet seen such a mushy keyboard in a notebook. The keys are quite flat with a very small keydrop of said 1mm. This would be acceptable if there would be some more resistance when depressing the keys. The BTest-1 System I tried however was so squashy I had to keep looking at the screen to check if the key I pressed actually was pressed.
In general the keyboard feels rotten which is a pity as the system would otherwise be very neat.

I'll be in Ireland from the 11th of September (cheap flights, *nudge* *nudge*) to the 25th on vacation together with Mara.
As this year's aKademy, the kde developer conference, is going to take place in Dublin from the 23rd on, I'm wondering if I should plan on being the last two days in Dublin. After all, aKademy is fun. At least that was the opinion after being part of the team who made aKademy 2004 a huge success.

So, who else from fedora/redhat is going to be there and who knows a good karaoke bar? And is it going to be better than Linuxtag 2005 in Karlsruhe?

I've finally gotten myself a SIP hardware phone after testdriving several softphones and finding each lacking. Even ekiga (formerly known as gnomemeeting) doesn't really satisfy:
Nearly no debugging output, meaning I have to whip up ethereal all the time, and many crashes when shutting down the app are not really strong points.

Anyway, I chose a Snom 360 SIP-phone after finding out, that the device is running an embedded Linux. Unfortunately, the company is turning from completely open firmware versions to gpl source and lots and lots of binary-only userspace daemons. However, there is a project trying to write a replacement firmware for the Snom 360.

After connecting the phone the the local network and seting up some external sip providers, one quickly notices the problems NAT is posing for SIP. When not configuring a STUN Server and a RTP Proxy the signalling of your call succeeds, but you will not be able to hear anything.
Bummer.

Luckily there exists a nat-helper module for iptables, allowing your router to track and modify the SIP packets and thus letting the audio packets through the nat and the firewall.
Unfortunately this module is not yet included in the main kernel but only available in the Netfilter Patch-O-Matic.

However, with the help of the new kmodhelper building external modules for your Fedora kernel is no big deal anymore. Simply download sip-conntrack-nat-kmod-0-1.20060717svn.2.6.17_1.2157_FC5.src.rpm and rebuild the module for your kernel version:

[andreas@bofh ~]$ rpmbuild --rebuild sip-conntrack-nat-kmod-0-1.20060717svn.2.6.17_1.2157_FC5.src.rpm \
        --target=$(uname -m) --define "kversion $(uname -r)"
Installing sip-conntrack-nat-kmod-0-1.20060717svn.2.6.17_1.2157_FC5.src.rpm
Building target platforms: i686
Building for target i686
...
Wrote: /home/andreas/fedora/redhat/RPMS/i686/kmod-sip-conntrack-nat-0-1.20060717svn
       2.6.17_1.2157_FC5.i686.rpm
Executing(%clean): /bin/sh -e /var/tmp/rpm-tmp.23234
+ umask 022
+ cd /home/andreas/fedora/redhat/BUILD
+ cd smixer
+ rm -rf /var/tmp/smixer-1.0.4-1-root-andreas
+ exit 0
[andreas@bofh ~]$

Next, you can install the just built module with "rpm -ivh your_rpms_pathkmod-sip-conntrack-nat-0-1.20060717svn.2.6.17_1.2157_FC5.i686.rpm".

All that is left to do is edit /etc/sysconfig/iptables-config to load your newly installed module.

# Load additional iptables modules (nat helpers)
#   Default: -none-
# Space separated list of nat helpers (e.g. 'ip_nat_ftp ip_nat_irc'), which
# are loaded after the firewall rules are applied. Options for the helpers are
# stored in /etc/modprobe.conf.
IPTABLES_MODULES="ip_nat_sip ip_nat_ftp ip_nat_h323 ip_nat_irc"
...

After calling "service iptables start" your SIP phone will suddenly start working and you can hear the person at the other end. And all that without having to fiddle with specific port-forwardings over a huge number of ports.
Yay! \o/