http://article.gmane.org/gmane.linux.power-management.general/23624
Should have happened much sooner. Rest in peace.
Archive for the ‘linux’ Category
The s2ram Whitelist is finally dead - Yeah!
Tuesday, March 8th, 2011openSUSE 32bit to 64bit live conversion
Friday, February 25th, 2011Kids, don’t try this at home.
Anyway, here is what worked for me:
- add arch = x86_64 to /etc/zypp/zypp.conf
- zypper ref -f
- rpm -qa kernel*
- zypper in -f kernel-default kernel-default-base (the kernel packages found by the step above)
- mkinitrd
- reboot
- zypper in -f glibc
- zypper in -f rpm Attention: don’t install, just resolve everything and get the list of -32bit packages that would get installed
- zypper in -f file-32bit libbz2-1-32bit… Install all the -32bit packages that were selected in the previous step
- zypper in -f rpm
- zypper dup --no-recommends --download-in-advance
- mkinitrd
- reboot
Whenever zypper asks you for conflict resolution (which will be every single case), select the option that involves “change architecture”, never select “break …” or “do not install …”. There should be no “uninstall…” proposal in the summary before confirming, only architecture changes and newly installed -32bit packgages.
There were some failing postinstalls for glib and other libraries, which could probably have been avoided by more carefully updating in intermediate steps, or by installing some -32bit library packages before the “dup” step, but the resulting system seems to work just fine.
Making GNOME more Usable
Saturday, February 5th, 2011And while I am at it, some hints on getting GNOME a small little bit more usable. The problem is mostly the default window manager, and the gripes I’m having with it are basically the same that Linus Torvalds had some years ago. I want my window buttons to be configurable. To be more precise, I want the “maximize” button to behave like in almost every other window manager: 3 different mouse buttons, 3 different button actions: “maximize”, “maximize horizontally”, “maximize vertically”.
Linus’ problems have been addressed, and I’m explaining a lame workaround for my wishes to get something slightly similar to what I want. My workaround does only work because of the fixes for Linus’ problems.
After looking into the code I understood that the window buttons are only used with left-click, right and middle click are handled by the “window titlebar action” instead.
So I redefined the window titlebar mouse actions to do maximize horizontally / vertically on right click and double click. (I am pretty accustomed to having middle button on title bar put the window into the background, but I might change that).
So here’s what you have to do.
- open
regedit.exegconf-editor - browse to /apps/metacity/general
- change
action_double_click_titlebartotoggle_maximize_vertically - change
action_right_click_titlebartotoggle_maximize_horizontally
While you are at it, you might also enable resize_with_right_button, which restores even some more sanity.
For all those asking why I’m not using a different window manager with GNOME: been there, tried that, but the integration of them all was pretty horrible (keyboard shortcuts no longer easily configurable, …) and I want somehting that just works and does not always get in my way. If I wanted that, I could have kept KDE.
OpenStack “bexar” packages for openSUSE and SLES11SP1 are ready
Thursday, February 3rd, 2011Shortly after the OpenStack “bexar” (spoken “bear”) release was ready, my packages finished building and are available at the isv:B1-Systems:OpenStack Build Service repo.
Grab them, while they are still hot!
The ride might still be a bit bumpy as the whole OpenStack development is very Ubuntu centric, and thus some of the dependencies, especially to old versions of python stuff are tricky to find. However, first results look promising.
I’ll update here soon with some short hints on how to configure and use the whole lot.
Thanks go to my colleagues Christian Berendt and Andre Nähring at B1 Systems GmbH who have been tireless in testing packages and reporting packaging bugs and other problems. Thanks also to Gregory Haskins with whom I started the packaging effort early in december.
DeLorean?
Wednesday, February 2nd, 2011Check out this bugreport. Sometimes I’m wondering if Takashi has a time machine, allowing him to jump back in time in order to fix reported bugs in such an amazingly short time… 
Load average
Friday, January 28th, 2011No 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)
Don’t Ask
Wednesday, January 26th, 2011(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)
Increasing the X resolution for KVM guests
Monday, January 17th, 2011Today I wondered again, why my KVM guests get only 800×600 display resolution, even though the framebuffer console is configured for 1024×768. 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 1024×768 resolution.
“Could not find any loop device.” WTF?
Thursday, January 13th, 2011susi:~ # 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
CUPS “400 Bad Request” Problem - And its Simple Solution
Sunday, November 21st, 2010Recently I wondered why the CUPS client machines in my network, all with a client only setup, could not print.
I finally found out that the CUPS webfrontend on port 631 was only reachable when called as “http://print:631/”, with “http://print.home.s3e.de:631/”, there was only a “400 Bad Request” error.
So as a first solution I configured the client to print on “print”, not on “print.home.s3e.de”, but that was of course still an issue that needed investigation.
Long story short: I had this line in /etc/hosts:
192.168.200.1 server.home.s3e.de server proxy print ntp
(I’m running dnsmasq on this machine to serve the internal network with DNS and DHCP, so those multiple hostnames are for the different functions of the machine).
Adding “print.home.s3e.de” to this line and restarting cupsd solved those issues.
No idea why CUPS looks into /etc/hosts (or if it is some libc function that does this), but maybe this post helps somebody else with this problem.
