“Drive-by-bugfixing” and why I might not bother anymore

April 13th, 2014

I like to call this “drive-by-bugfixing” and this is how it usually happens:

  • I have a problem with e.g. xfce4-power-manager, which I’m unable to fix right now
  • I check out some random other package (let’s call it “yerba-power-manager”) to check if it can replace xfpm for me
  • I find it has a bug. Or two. Actually caused by broken openSUSE patches trying to implement new APIs
  • Because it is “an interesting problem”, I fix it them just for fun
  • Later I find that I have no use for this package as (for unreated reasons), it does not fix any of my original problems

So far so good. Now I have a fixed package lying around in my home:seife buildservice repository. Trying to be a good cititzen, I submit it back to the original YERBA desktop project.
Can you imagine what happens next?
Correct! It gets rejected. Why? Because I did not mention all my patches in the changelog.

Come on guys. Policies etc. are all fine, but if you want people helping maintain your broken packages, then don’t bullshit them with policy crap, period.
I had done the heavy lifting last sunday and fixed the bugs, now all that the desktop maintainer would have needed to do would have been to amend the changelog.

Well, I am not that interested in that particular desktop and its problems, so I just revoked the submitrequest and am done with it. I fixed XFPM instead :-)

And yes, I understand very well that such policies are a good thing to have, and necessary, and if I’m contributing to some subproject on a regular basis, then I of course make sure that I’m following these rules. On the other hand, it’s really easy to discourage the occasional one-time contributor from helping out.

(Names changed to protect the guilty)

FreeDNS update mit FRITZ!Box

April 11th, 2014

(This post is in german, since the router is commonly used in german-speaking countries)

Ich benutze seit längerem FreeDNS anstelle von Dyn.com oder ähnlichen Diensten, hauptsächlich weil das Update so einfach ist: einfach einen personalisierte URL per “wget” oder “curl” aufrufen und schon ist die eigene IP geändert, es wird keine spezielle Software benötigt. Dieser URL enthält eine Zeichenkette die den eigenen Account identifiziert, sie enthält aber nicht den Usernamen oder das Passwort. Somit ist es relativ ungefährlich, diesen URL in z.B. einem cronjob einzutragen: sollte jemand diesen String mitlesen, so kann er im schlimmsten Fall die IP falsch updaten, was zwar lästig aber relativ harmlos ist.

Nachdem Dyn.com küzlich die kostenlosen Accounts gekündigt hat, war das Thema FreeDNS für einige Bekannte auch aktuell, die größten Bedenken kamen allerdings daher, daß der in die FRITZ!Box eingebaute Dynamic DNS Unsterstützung FreeDNS nicht unterstützen würde. Das ist so nicht richtig:

Im Webfrontend, unter “Dynamic DNS” einfach “Benutzerdefiniert” auswählen, als “Update-URL” dann den URL einsetzen, die man in der Accountverwaltung auf http://freedns.afraid.org/dynamic/ als “Direct URL” bekommt.
Als “Domainname” wird der angemeldete Domainname eingetragen. Die FRITZ!Box prüft nach ob sich dieser auflösen lässt und meldet einen Fehler, wenn das nicht funktioniert.
Leere “Username” und “Passwort” akzeptiert die FRITZ!Box nicht, also habe ich in die Felder einfach “x” eingetragen. Fertig.

Getestet hier auf einer FRITZ!Box 7390 mit FRITZ!OS 06.03.

(Update 13.4.2014: “Domainname” ergänzt)

VDR updated to 2.0.x

April 9th, 2014

I finally got around to update VDR to version 2.0.x
I’m using this version since some time and it is working fine for me. However, I’m quite sure that there are some kinks to be ironed out.
I’m not sure if updating from an old openSUSE VDR installation is a good idea or if it would be better to start from scratch. Personally, I’d do the latter and only keep my channels.conf.

The recommended way for starting VDR from systemd is now the runvdr-extreme-systemd package, the old runvdr init script is still available from the vdr-runvdr package, but is completely untested.

Configuration now happens in /etc/runvdr.conf, the old /etc/sysconfig/vdr is no longer read at all.

Normally, only the used plugins need to be added to runvdr.conf like

AddPlugin streamdev-server
AddPlugin epgsearch --logfile=/var/log/epgsearch/log --verbose=3
AddPlugin xineliboutput --local=none --remote=37890

This should be the equivalent of old sysconfig values

VDR_PLUGINS="streamdev-server epgsearch xineliboutput"
VDR_PLUGIN_ARGS_streamdev_server=""
VDR_PLUGIN_ARGS_epgsearch="--logfile=/var/log/epgsearch/log --verbose=3"
VDR_PLUGIN_ARGS_xineliboutput="--local=none --remote=37890"

The settings in runvdr.conf are commented, so the config file should be easy to understand.

If you are using vdradmin-am and are importing the old vdradmin.conf (I’d actually advise to start from scratch there, too) then you need to change the SVDR port setting to the new default of 6419 (or change the SVDRPORT variable for VDR to the old value).

The “supported” plugins are maintained in the “vdr” repository of the openSUSE Buildservice. I’m collection “unsupported” additional plugins in “vdr:plugins”. The definition of “supported” right now is “the stuff that I use”, simply because I cannot really test stuff that I don’t use on a daily basis. Of course if someone wants to help maintain these things, I’m more than willing to move things into the main “vdr” repository.
Stuff that is in the supported repository will most likely end up in Factory and thus in openSUSE 13.2.

Bugreports via bugzilla or the opensuse-factory mailinlist, please ;-)

Nice kdump hack: get dmesg only

March 18th, 2014

Last week during a kernel debugging trainig, I was asked by a participant if it would be possible to get only the dmesg of the crashed kernel, without capturing the whole crash dump.
The possibility is clear, since both current RHEL/CentOS versions as well as SLES11SP3 already put a “dmesg.txt” next to the vmcore in the crash dump directory.
But how would you achieve to get only the dmesg?
And why would one want that?
Well, the second question is easily answered: in order to deploy crash dump capturing in a large hardware pool, quite some preparation needs to be done. In my daily work, servers most of the time have more RAM than they have local disk storage, so you need to store the dumps on the network. Then you need to make sure that a large amount of crashing servers (a famous example was the leap second bug) does not fill up the storage and leads to further problems like machines not coming up again due to full storage etc. All solvable, but to be considered before deployment. If you just capture the dmesg, you can almost certainly store that locally without creating problems. Another reason would be to get the servers up again as soon as possible, while still capturing some useful information (dumping a few hundreds of gigabytes of RAM can take quite some time).

So how to do it?
SUSE’s kdump infrastructure (tested on SLES11SP3) has a configuration option KDUMP_PRESCRIPT which allows to give a custom script which will be run before the crash dump is captured. This script now needs to call vmcore-dmesg and save the output somewhere for later inspection, then unmount the rootfs and issue reboot -f. Since this script never returns, the regular core-collector will not run. Problem solved.

The script is actually pretty trivial, so that it can be pasted here:

#!/bin/sh
# small script which can be used as KDUMP_PRESCRIPT in SLES
# it *only* saves the dmesg of the crashed kernel and then
# reboots immediately, *no* crash dump is saved.
# benefits:
# * get the machine up ASAP, while still collecting
#   some useful information.
# * can be always enabled without worrying about storage etc
#
# License: WTFPL v2
NOW=`date +%Y-%m-%d-%H%M`
OUT=/root/var/crash/vmcore-dmesg-${NOW}.txt
# in SUSE kdump initrd, real rootfs is mounted to /root
PRG=/root/usr/sbin/vmcore-dmesg                 # SLES12
test -x $PRG || PRG=/root/sbin/vmcore-dmesg     # SLES11SP3
$PRG /proc/vmcore > $OUT
umount /root
reboot -f       # do not continue the kdump initrd

It is slightly more complicated than absolutely necessary, but it should work in newer releases which now put the tools in /usr/sbin, too.
In my case, I saved it to /usr/local/sbin/vmcore-dmesg.sh and then changed the following in /etc/sysconfig/kdump:

KDUMP_REQUIRED_PROGRAMS="/usr/local/sbin/vmcore-dmesg.sh"
KDUMP_PRESCRIPT="/usr/local/sbin/vmcore-dmesg.sh"

After restarting kdump, the next crash gave me a nice:

sles11sp3:~ # ls -l /var/crash/
total 36
-rw-r--r-- 1 root root 33383 Mar 18 09:33 vmcore-dmesg-2014-03-18-0911.txt

and no crash dump, mission accomplished.

systemd makes boot slower

January 19th, 2014

Why am I not surprised? Boot time going up from 1 minute to 4 minutes due to journald. Maybe journald is a secret plot by the SSD vendors to sell more units? :-P

Fix coolstream neo tuner voltage problem

January 1st, 2014

After trying to use the EN50494 feature of neutrino-mp, I found that as soon as I attached the coolstream neo to my coax-”bus”, all other receivers on the same bus could no longer tune any frequency. After quite some investigation, I found out, that the tuner does not lower the voltage to 13V if there is less than about 10mA of current load on the “LNB in” coax output.
I tried to work around the problem in software. However, that did not work too well, because if the neo was the only active receiver on the bus, then the SCR matrix would shut down if there was no voltage applied. So I checked if there is a way to simply fix the broken hardware.
There is. Next to the tuner “tin box” there is a transistor that has the 14/19V at one of its terminals. Just adding a 1.1kOhm resistor from there to ground made the voltage switch correctly even without any coax cable attached.

1.1kOhm resistor fixes tuner voltage problem

1.1kOhm resistor fixes tuner voltage problem


The picture is not very good but it shows where the LNB power can be tapped.
Note: use this at your own risk, soldering the resistor to the wrong terminal or shortening the wrong solder points might very well kill your box. You have been warned.
It is also very well possible that better soldering points exist, however this solution can be implemented without disassembling the box completely by just soldering on the top side of the PCB.

It would be interesting if this modification also solves the huge amount of DiSEqC switching problems that were reported last spring after some software update, it surely solved my EN50494 (aka unicable) bus blocking problem. After all the vendor has issued no statement until today, even though this clearly looks like broken (by design) hardware…

“rdmsr” implemented in perl

December 23rd, 2013

Today I needed the “rdmsr” tool to determine if machines are configured correctly for Hypervisor usage (VT-X enabled). Just after learning how to detect this (by looking at the cpu-checker ubuntu package), I found out that msr-tools is not available on SLES11. Instead of building the package, I just implemented a minimal version in perl (it will be integrated into a perl tool checking other aspects of the system anyway):

#!/usr/bin/perl
# License: WTFPLv2
# minimal "rdmsr" implementation
$msr = shift
        or die "need msr as parameter";
$msr = hex($msr) if ($msr =~ m/^0x/i);
open(FD, "/dev/cpu/0/msr")
        or die "open /dev/cpu/0/msr: $!";
sysseek(FD, $msr, SEEK_SET)
        or die "sysseek: $!";
sysread(FD, $reg, 8 ) == 8
        or die "sysread: $!";
$reg = reverse($reg);
$hex = unpack('H*', $reg);
$hex =~s/^0*//;
print "$hex\n";

Yes, i know, my perl is horrible :-) but maybe this is useful for someone else anyway.

Raspberry Pi: Another platform for Neutrino-MP

October 10th, 2013

Last night I got video decoding via libilcore working on Raspberry Pi, so now the port of Neutrino-MP is starting to look like it will get usable some time in the future.

Most stuff is encapsulated inside libstb-hal, which means that only a small change in Neutrino-MP (just adding the proper LDFLAGS) was necessary. Later, with proper implementation / packaging of libstb-hal, this might also be unnecessary.

For those who dare to try it, I’d suggest to start with current raspbian, then use the Makefile for native building (after tweaking it to your needs) to build it directly on the Raspi — this is how I did it :-) ). The stuff is not yet ready for cross compilation (too many hard-coded /opt/vc/lib etc).
You’ll first need to build libdvbsi++ — there’s a target in the Makefile for that — and install all missing devel packages — hopefully, configure will compain. Otherwise the missing includes will be obvious, I guess.

The next step will be implementation of the audio decoder, which should be not too hard, then the thing will be truly useful :-) .

openSUSE Kernel debuginfo weirdness

August 16th, 2013

Just because I fell into the same trap twice, once when trying kdump a year ago, now when working on systemtap, a short reminder for everyone:

If you want to do something that needs kernel-default-debuginfo installed (like, say, “kdump”/”crash” or “systemtap”), then make sure that you also have kernel-default-devel-debuginfo on your system.

The reason for this is, that the kernel-default-debuginfo package has only the debuginfo for the kernel modules, but it misses the debuginfo for /boot/vmlinux. This debuginfo is in kernel-default-devel-debuginfo package.

This is at least strange, since the vmlinux binary is not in the devel package but in the main kernel package.
But in practice it does not matter if this is a bug or not: you need both debuginfo packages installed to make kdump analysis with “crash” or systemtap work.

ExpressCard hotplug with kernel 3.11

August 16th, 2013

(Executive summary: boot with acpiphp.disable=1)

Kernel 3.11rc has fixed the mei driver suspend problem for me. It brought another quirk, however. ExpressCard hotplug does not work anymore with my trusty old Thinkpad X200s. I need this to use my USB3 card. With 3.11 it only works if it is already plugged in during boot.
To be honest, this has never been 100% automatic before: I always needed to manually load the “pciehp” module to get the slot to work. The other possible driver, “acpiphp” refused to load.
With 3.11, both the acpiphp and the pciehp drivers can no longer be built as modules but are both built in statically.
In addition, now the acpiphp driver claims to support my slot, which it in fact does not, but it still claims the slot and prevents the pciehp driver (which is initialized later) from working. The kernel hackers are working to fix up this mess, but it is probably not going to “just” work in 3.11, so for now the way to get the ExpressCard slot working on a Thinkpad X200s is to pass the boot option

acpiphp.disable=1

to the kernel.