ixs' Vodkamelone

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.

Die Tatsache, dass Mailinglisten inzwischen nicht mehr das Mittel der Wahl zur Kommunikation sind, hat sich mittlerweile auch bei Internet Provider meiner Wahl herumgesprochen.

Die hohe Anzahl von unerwünschten Werbemails verleitet nicht nur mich dazu, einerseits extrem rigeros zu filtern, andererseits dennoch nur noch höchst widerwärtig in meinen E-Mail Client zu schauen.

Was liegt also näher, zur Kommunikation mit den Vereinsmitgliedern - aber auch mit den normalen Benutzern - ein Blog zu verwenden?

Die Wahl fiel auf Serendipity da es sowohl bereits bekannt ist, als auch einen Mehrbenutzermodus anbietet, bei dem verschiedene Personen Einträge bloggen können.

Zu finden ist das ganze unter http://blog.bawue.net. Ein paar Inhalte habe ich auch schon hinzugefügt, warten wir mal ab, ob das Konzept denn auch angenommen wird.

Als Bonus der ganzen Aktion habe ich mittlerweile herausbekommen, wie man ein Serendipity Template schreibt und habe auch wieder Einblick in den Code mancher Plugins gewonnen... Eine lohnenswerte Aktion also...