Friday, January 28, 2011

Load average

No comment:
  2:05pm  up 79 days  6:40,  5 users,  load average: 2948.98, 2948.04, 2945.49


(Later we found out that the load was actually "fake", the kernel had somehow died and everything accessing /proc/$pid/* was hanging in state D)

Wednesday, January 26, 2011

Don't Ask

(No, it was not me who made this necessary. Yes, we did reinstall the machine anyway.)
#!/bin/bash
while read p; do
rpm -V $p > /dev/null && continue
echo "fixing $p's file ownership..."
while read x x u g x x x x n x; do
chown -h $u:$g $n
done < <(rpm -qlv $p)
done < <(rpm -qa)

Monday, January 17, 2011

Increasing the X resolution for KVM guests

Today I wondered again, why my KVM guests get only 800x600 display resolution, even though the framebuffer console is configured for 1024x768. While most of the time this does not matter for testing, it does once you want to evalutate desktop environments or such in a VM.
I checked the xorg log file and found, that the Cirrus card emulation apparently has no DDC channel implemented, thus cannot detect the monitor and then X.org falls back to a plain SVGA monitor. From the logfile:
Using default hsync range of 31.50-37.90 kHz
Using default vrefresh range of 50.00-70.00 Hz

Simply setting those ranges to something reasonable (I got my values from "hwinfo --monitor") helps quite a lot. Put this into /etc/X11/xorg.conf.d/50-monitor.conf:
  HorizSync   31 - 61
VertRefresh 50 - 90
and you get a much more usable 1024x768 resolution.

Thursday, January 13, 2011

"Could not find any loop device." WTF?

susi:~ # mount /space/FACTORY.iso /mnt/ -oloop
mount: Could not find any loop device. Maybe this kernel does not know
about the loop device? (If so, recompile or `modprobe loop'.)

WTF? That never happened to me before, so I assumed (obviously) that something was broken in current FACTORY and filed a bug.

Finally we found out, that the loop module was always unconditionally loaded on every machine by boot.localfs, which is no longer run since I switched to systemd.

As Kay pointed out in the bug, it is very easy to fix:
susi:~ # echo loop > /etc/modules-load.d/loop.conf
At least until someone fixes the Kernel's loop device behaviour ;)