Skip to main content

Work around overheating with cpufreq-set

One of my Gentoo boxes has overheating issues which I have yet to properly address on hardware level. Compiling something like Boost or Firefox results in a guaranteed emergency reboot, literally not cool. The box has a dual core CPU with 2.53 GHz. Fortunately, it can be throttled to do operate at a lower frequency which results in less heat from the CPU. Using cpufreq-info(1) I can see that the CPU is happy to operate under a few alternative frequencies:

$ cpufreq-info | fgrep 'available frequency' | head -n 1
  available frequency steps: 2.53 GHz, 2.53 GHz, 1.60 GHz, 800 MHz

Now different CPU governors give me different options:

  • Governor 'performance' runs at maximum frequency (i.e. 2.53 GHz), not cool
  • Governor 'powersave' runs at the minimum frequency (i.e. 800 MHz) where compilation may take forever
  • Governor 'ondemand' jumps from mode to mode depending on workload: still reboots from overheating
  • Governor 'userspace' allows me to keep the frequency at 1.60 GHz -- nice!

You can check for availability of a specific CPU governor with

$ zgrep FREQ_GOV_ /proc/config.gz
CONFIG_CPU_FREQ_GOV_PERFORMANCE=y
CONFIG_CPU_FREQ_GOV_POWERSAVE=y
CONFIG_CPU_FREQ_GOV_USERSPACE=y
CONFIG_CPU_FREQ_GOV_ONDEMAND=y
# CONFIG_CPU_FREQ_GOV_CONSERVATIVE is not set

and make use of modprobe(8) as needed. So with a single call

$ sudo cpufreq-set -r --min 1.60Ghz --max 1.60Ghz -g userspace

that box seems to stop overheating for now. Nice! [EDIT] : What Robin is suggesting in the comments would make

$ sudo cpufreq-set -r --max 1.60GHz -g ondemand

on the shell.

Fwd: Sebastian Deterding: What your designs say about you

I would like to share this talk with you for two reasons:

  1. I find his statement "You cannot not persuade" and its consequences to communication and daily life important to become aware of, and
  2. this view on design has implications on the user interfaces of software we build, too.

See for yourself...

German keyboard layout at disk unlocking time (i.e. in the initramfs boot process) with Debian

Among the first things a Debian installer does is making me select a proper keyboard layout. For a setup including disk encryption that makes me enter a password with a German keyboard layout just as I asked it to: good. After reboot, things look a little different: I am expected to enter my password with a US layout active (due to bug this known bug). With a a few non-alphanumerics in it, entering a password with a foreign layout becomes a challenge easily and/or gets annoying quickly. At that time, there is no feedback of the letters you type! To get the layout to German at boot time this procedure worked for me:

  1. In /etc/initramfs-tools/initramfs.conf change KEYMAP=n to KEYMAP= _y_
  2. Run ln -s /etc/console-setup/cached_UTF-8_del.kmap.gz /etc/console-setup/cached.kmap.gz (or similar depending on what the existing file is called for you)
  3. Run update-initramfs -k all -u
  4. Reboot

As usual, please correct and/or extend in the comments as necessary.

Installing Debian to an existing dm-crypt container

For my new work notebook I am aiming for a setup with Debian and Gentoo side by side. I installed Gentoo first and went for adding Debian today. For a notebook I want full disk encyrption of course and my plans were to use one big dm-crypt container for everything except /boot. Interestingly, the installer of Debian testing/wheezy does not support installing into an existing crypt container out of the box, not even when run in expert mode. There is an outstanding grave functionality bug titled "allow to 'reuse' encrypted volumes" about it where Frans Pop states:

It is actually possible to reuse existing encrypted LVM volumes by following the procedure documented on [1] just before starting the partitioner. [1] http://wiki.debian.org/DebianInstaller/Rescue/Crypto

The hint about "before starting the partitioner" is the most helpful bit about it. The guide he points to is not specific to the Debian installer, misses to mention vgscan and is an immutable page so i cannot improve it easily. To summarize, this is what worked for me (no warrenties!):

  1. When it comes to disk partitioning before picking "manual" switch to another terminal, e.g. <Ctrl>+<Alt>+<F2>, <Return>.
  2. Open the Luks container using cryptsetup luksOpen /dev/ foo foo_crypt
  3. Run vgscan to detect the LVM volume group inside (lvdisplay alone will not do)
  4. Run vgchange -a y foo_crypt to activate all logical volumes
  5. Switch back to the installer terminal by pressing ++ (which will list LVM your current LVM volumes now)
  6. Follow the installtion as usual but stop before rebooting
  7. On the second shell edit /etc/crypttab to have a line /dev/foo foo_crypt none hash=sha1 so the crypt container is actually opened by the initramfs. Rather than "sha1" you may want to pick whatever cryptsetup luksDump /dev/foo | fgrep -i hash produced.

That's it. Got any corrections or extensions to this post? Please comment below.

blkid(8): Superficial comparision of versions from e2fsprogs and util-linux

Both e2fsprogs and util-linux ship a tool blkid: a frontend to the libblkid library. I was interested in the differences between these two tools. From my current understanding, util-linux's is a fork of an older version from e2fsprogs. The change log of util-linux(-ng) 2.15 (shipped with util-linux-2.21.1.tar.xz) reads:

The libblkid library has been moved from e2fsprogs to util-linux-ng.

If I take the help output of blkid of util-linux 2.21.1 and remove everything that blkid of e2fsprogs 1.42.1 already does, I end up with this:

# /sbin/blkid -h
blkid from util-linux 2.21.1 (libblkid 2.21.0, 30-Mar-2012)
[..]
 -d          don't encode non-printing characters
[..]
 -k          list all known filesystems/RAIDs and exit
[..]
 -t <token>  find device with a specific token (NAME=value pair)
[..]
 -U <uuid>   convert UUID to device name
[..]

Low-level probing options:
 -p          low-level superblocks probing (bypass cache)
 -i          gather information about I/O limits
 -S <size>   overwrite device size
 -O <offset> probe at the given offset
 -u <list>   filter by "usage" (e.g. -u filesystem,raid)
 -n <list>   filter by filesystem type (e.g. -n vfat,ext3)

In addition, parameter -o <format> supports "udev" and "export" more.

Setting user name and email in Mercurial

As I am rather new to the use of Mercurial it took me a bit of time to find an equivalent to Git's

# git config --global user.name .....
# git config --global user.email .....

earlier today. The answer is editing ~/.hgrc like

[ui]
username = First Last <mail@example.org>

as I learned here eventually. I should have learned it from the Command equivalence table, though. So I have added an entry myself now to speed up whoever runs into that problem next.

Masking bad RAM with Grub2

I recently ran into the situation that during installation of some packages in Debian the display started showing graphic errors and the root file system reported to be read only (as it was configure to switch to read-only on errors through its mount options). memtest86+ first complete pass showed no errors at all but later runs indicated errors at at least three addresses:

  • 00010c1d370
  • 00010c1dab0
  • 00004c1da90

Interestingly, grub2 supports masking sections of RAM out of the box, a feature I recently spotted in /etc/grub/grub.cfg by chance. The example and documentation of parameter GRUB_BADRAM in grub.cfg looked like it was just a list of sectors to ignore so I started with "0x10c1d370,0x10c1dab0,0x04c1da90" for it... to find a frozen Grub after reboot. After a bit of investigation I learned that every second entry is a mask on its predecessor and found a good howto and on how to construct these. The bad RAM mask gave me a few hours of no noticeable errors... and then it came back, from another unmasked section I suppose. That made me order new RAM of a different brand.

New shoes? New shoes!

I have never blogged about shoes before. So let's see what it's like. After all for being shoes these make me quite happy right now. Shoes! My old sneaker's started to die so with a single pair of shoes only I had to do something. I liked the fresh look of the red ones so I ended up with both of these. Very comfortable to wear so far. So Pictures!

Apropos new shoes: Paolo Nutini knows what new shoes can do, join his tune:

PS: The links go to the PUMA online shop but there is no affiliation with me so I do not earn money from your clicks or buys up there. PPS: The shoe pictures are all rights reversed by PUMA, they are sadly not licensed under Creative Commons. Neither is the video starring Mr. Nutini.

My best tool with package bumps: Meld

For quite some time I have been using Meld to detect relevant changes between two releases when I update a package in Gentoo. I run

# ebuild foobar-1.2.ebuild manifest prepare
# ebuild foobar-1.3.ebuild manifest prepare

and throw Meld at both outputs

# meld /var/tmp/portage/[..]/foobar-1.2/work/foobar-1.2/ \
       /var/tmp/portage/[..]/foobar-1.3/work/foobar-1.3/ &

Meld makes it easy to see what has changed and (especially) what has not changed. With sole diff -r that would be difficult. I usually start by inspecting changes to configure.ac. If upstream did a good job that diff tells what dependencies to touch, already. Near the left and right margin you can see where else the file has been modified. No need to scroll-search down for more: you already know what you get.

The NEWS and ChangeLog files usually offer pointers of interest, too.

If my hint on Meld made a single Gentoo packager juggler's life easier or more efficient, I have achieved what I was aiming for. Sorry for the noise to everyone else.

PS: The second preview image up there has been losslessly reduced by 40% in size just by running it through optipng -o7.