Ever since I upgraded my notebook with a SSD, I was looking for a way to minimise or avoid unnecessary write accesses. The tools of choice (on Linux at least) are iostat for a rough summary and pidstat for the details. With the help of those two one can easily figure out which processes are responsible for write accesses.

Once a writing process is identified, lsof can tell you which files are actually written. Depending on what you want to achieve, you can then continue to relocate that file to a different disk (e.g. if you have two disks and want one of them to sleep most of the time) or to memory (using tmpfs). The latter obviously means that the written data will be lost at the next reboot, but sometimes this is perfectly fine e.g. for the files inside /tmp. Therefore, it is generally a good idea to move that directory into volatile memory following the instructions on the openSUSE Wiki.

All good and well if you actually manage to relocate or move a file. Often file locations are a matter of configuration and otherwise you can help yourself with dynamic links. But there was one very special file on my openSUSE 11.4 installation that withstood all my assaults for quiet some time. I’m speaking of a beast called .xsession-errors residing in your $HOME directory. Created by KDM, one would expect to be able to configure the location of that file. Indeed, there is a configuration option called ClientLogFile specifically for that purpose. Unfortunately this is only the first and easier of two necessary steps:

  1. As root open your /usr/share/kde4/config/kdm/kdmrc, go to a section labelled [X-:0-Core] (there may be multiple of those, but don’t worry and just pick the last one) and add the following line:

    This will move the file into the /tmp directory. Mind the path relative to $HOME.

  2. Now the hidden piece: again as root open your /etc/X11/xdm/Xsession and make the following changes (I deliberately use the patch syntax here i.e. remove lines with a minus sign and add those with a plus sign):
    --- Xsession.old        2011-05-01 19:46:40.000000000 +0200
    +++ Xsession    2011-05-02 22:18:39.000000000 +0200
    @@ -123,8 +123,8 @@
         # GDM seems to handle this its self
         test -z "$GDMSESSION" || break
    -    # Once if KDM does handle this its self
    -    #test -z "$KDMSESSION" || break
    +    # KDM handles this itself
    +    test -z "$KDE_SESSION_VERSION" || break
         # Avoid bad symbolic links
         case "$errfile" in

Done; logout, restart KDM, re-login and check if the xsession-errors* exists at the new location. If so, remove your old one and cheer to a long living SSD. Only, of course, if the new location is not on your SSD, but e.g. in memory. It doesn’t hurt to re-check with pidstat.

Eclipse CDT crash

If you’re using the Eclipse CDT for C++ development and experience crashes immediately after loading the workspace (during indexing) on Linux (I saw it on Fedora and openSUSE), you should use the workaround suggested in the corresponding Bugzilla entry. Essentially you have to add the line


to your eclipse.ini.

Fedora Live USB with GRUB

As already mentioned in my last post, my laptop won’t boot from a USB stick prepared using a binary copy of an ISO (by means of dd). Here is the method I use to boot the Fedora Live images off my USB stick using GNU GRUB2. The device node of the USB driver is denoted /dev/sdX in the following and must be replaced with the actual device node (e.g. /dev/sdc).

  1. Prepare a partition on the USB stick and/or make sure there is enough space on it (it must be slightly larger than the ISO image).
  2. Make sure it is flagged bootable. ( fdisk -l /dev/sdX is your friend)
  3. Remember the name of the USB partition you’re going to use or if unlabelled, label it.
  4. Loop-mount the ISO image using something like mount -o loop /path/to/iso /mnt/loop
  5. Copy the content of the ISO over to the USB
  6. Install GRUB on the USB by issuing grub-install --no-floppy --root-directory=/mnt/usb /dev/sdX
  7. Create a /mnt/usb/boot/grub/grub.cfg with the following content
    menuentry "Fedora Live" {
     linux /isolinux/vmlinuz0 root=live:LABEL=XYZ rootfstype=auto ro liveimg quiet  rhgb rd_NO_LUKS rd_NO_MD rd_NO_DM
     initrd /isolinux/initrd0.img
    menuentry "Fedora Live (Basic Video)" {
     linux /isolinux/vmlinuz0 root=live:LABEL=XYZ rootfstype=auto ro liveimg quiet  rhgb rd_NO_LUKS rd_NO_MD rd_NO_DM xdriver=vesa nomodeset
     initrd /isolinux/initrd0.img

    where XYZ must be replaced by the actual partition name of your USB partition.

  8. Unmount and boot

Fedora 15 Live USB for HP 8440p

Unfortunately, none of the „common methods“ for creating a Live USB workes such that my HP EliteBook 8400p would boot them. The procedure described by Jordon Mears came closest. The only technical difference is, that for some obscure reason, the machine won’t boot from anything else than FAT when it comes to USB sticks.

Here are the slightly modified steps:

  1. Download the ISO image
  2. Unmount USB
  3. Delete partitions on the USB
  4. Create one primary partition of type 0x0c (Win 95 FAT LBA) of size ??.
  5. Make it bootable
  6. Use mkfs.vfat -n USB /dev/sdX1 to create the filesystem
  7. Make sure syslinux, and isomd5sum are installed
  8. Use livecd-iso-to-disk --overlay-size-mb 512 /path/to/iso /dev/sdX1
  9. Sync

Good luck!

Fedora 14 and SSH port forwarding

Yesterday I upgraded also my workstation to Fedora 14 and soon ran into a rather unexpected problem that I couldn’t resolve due to an overwhelming amount of misleading reports and discussions on the web a.k.a. „noise“. The use-case was, that I tunnel from home to my workstation via SSH on a regular basis and for different purposes. After yesterdays upgrade I double-checked that all firewall settings are OK to permit the connection before I went home. Initialising the tunnel later that evening went without a problem, but using it issued a weird error:

channel 2: open failed: administratively prohibited: open failed

A search on the web yielded all kinds of results, mostly referring to settings in the SSH daemon. All solutions either mentioned AllowTcpForwarding, which is anyway yes by default, or PermitTunnel, which has nothing to do with port forwarding. As was to be expected, these hints didn’t help in my case.

Desperate to find more useful keyword for a search, I ran ssh in verbose mode (with -vvv), which gave (global IP addresses are replaced by X.X.X.X):

debug1: Connection to port 11080 forwarding to socks port 0 requested.
debug2: fd 8 setting TCP_NODELAY
debug2: fd 8 setting O_NONBLOCK
debug3: fd 8 is O_NONBLOCK
debug1: channel 2: new [dynamic-tcpip]
debug2: channel 2: pre_dynamic: have 0
debug2: channel 2: pre_dynamic: have 3
debug2: channel 2: decode socks5
debug2: channel 2: socks5 auth done
debug2: channel 2: pre_dynamic: need more
debug2: channel 2: pre_dynamic: have 0
debug2: channel 2: pre_dynamic: have 10
debug2: channel 2: decode socks5
debug2: channel 2: socks5 post auth
debug2: channel 2: dynamic request: socks5 host X.X.X.X port 80 command 1
channel 2: open failed: administratively prohibited: open failed
debug2: channel 2: zombie
debug2: channel 2: garbage collecting
debug1: channel 2: free: direct-tcpip: listening port 11080 for X.X.X.X port 80, connect from port 59418, nchannels 3
debug3: channel 2: status: The following connections are open:
  #1 client-session (t4 r0 i0/0 o0/0 fd 5/6 cc -1)

debug3: channel 2: close_fds r 8 w 8 e -1

No luck either.

Finally, I had the idea that SELinux could interfere here without giving the SSH daemon the possibility of a helpful error message. When I logged into my workstation this morning, the SELinux warning gave the appropriate solution in the form of a command (to be issued by root):

$ setsebool -P sshd_forward_ports 1

This fixed the problem and everything now works as before. \me = happy.