OK I found it in some other discussions; the problem is rsyslogd forks itself under "syslog" credentials and in the older kernel this user is not able to access kernel messages. Solution: comment line "$PrivDropToUser" in /etc/rsyslog.conf as I have very limited memory resources and can't afford two rsyslogd processes running as in the safer solution below.
There is another solution mentioned here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=573980
for the case the comment of the article get's delete, here is cut and paste:
--------------- The rest is the cut'n'paste (with some formatting) ---------------
From: "Stefan K." <archilles at kh-webcenter dot_de>
To: 573980 at bugs dot debian dot_org
Subject: Re: Bug#573980: rsyslog: klog does not work when dropping privileges
Date: Wed, 08 Jun 2011 13:52:05 +0200
I´m using a simple workaround for some time now. In addition to the normal rsyslog instance I run a second one. The "main" rsyslog doesn´t fetch kernel messages anymore and therefore can drop its root privileges. But it´s now listening on localhost for them.
The second instance runs as root and has only a minimum configuration to forward kernel messages to the "main" instance. So it is not reachable from the local network and opens no unix socket(?).
$AllowedSender UDP, 127.0.0.1
It´s started after the "main" instance by adding it to /etc/init.d/rsyslogd and stopped by init on shutdown/reboot with SIGTERM. I expect this to be safer on a (exposed) server. Although this requires some additional resources (cpu power and main memory), I guess it should be negligible today
/usr/sbin/rsyslogd -c5 -f /etc/rsyslog.conf.root -i /var/run/klogd-emu.pid