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
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.
I would like to share this talk with you for two reasons:
- I find his statement "You cannot not persuade" and its consequences to communication and daily life important to become aware of, and
- this view on design has implications on the user interfaces of software we build, too.
See for yourself...
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:
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)
update-initramfs -k all -u
As usual, please correct and/or extend in the comments as necessary.
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'
about it where Frans Pop states:
It is actually possible to reuse existing encrypted LVM volumes by following the procedure documented on  just before starting the partitioner.  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
vgscan and is an immutable page so i cannot improve it easily. To
summarize, this is what worked for me (no warrenties!):
- When it comes to disk partitioning before picking "manual" switch to another terminal, e.g. <Ctrl>+<Alt>+<F2>, <Return>.
- Open the Luks container using
cryptsetup luksOpen /dev/ foo foo_crypt
vgscanto detect the LVM volume group inside (
lvdisplayalone will not do)
vgchange -a y foo_cryptto activate all logical volumes
- Switch back to the installer terminal by pressing
+ + (which will list LVM your current LVM volumes now)
- Follow the installtion as usual but stop before rebooting
- On the second shell edit
/etc/crypttabto have a line
/dev/foo foo_crypt none hash=sha1so the crypt container is actually opened by the initramfs. Rather than "sha1" you may want to pick whatever
cryptsetup luksDump /dev/foo | fgrep -i hashproduced.
That's it. Got any corrections or extensions to this post? Please comment below.
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
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.
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
[ui] username = First Last <firstname.lastname@example.org>
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:
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.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
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.
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.
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.
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.
second preview image up there has been losslessly reduced by 40% in size just
by running it through