Archive for the ‘Uncategorized’ Category

VDR Video Disk Recorder – my way !

June 26, 2017

After more than 11 years of fine service recently the motherboard of my VDR PC failed. This PC had always been running headless (without a screen or keyboard) in my home office attached to  a dedicated DVB-S-LNB and to my LAN. I copied the recorded files  to a USB stick which I then put in my TV downstairs. But now it was broken and no repair possible.

At first I checked the offerings on “Harddisk Recorders”. But after some time I became aware that running these headless might not be a good idea. Though controlling apps are available I could not get as much detailed information as I wanted. So after some seesaw I finally bought a used Lenovo Thinkstation S10. This is a Midi Tower which easily can hold the PCI Technotrend S2300 DVB-S, which I swapped from the broken PC (this is an active card, back in 2005 more costly than the used Thinkstation in 2017).

I have described all the details of installing and configuring the Linux VDR software on Ubuntu 16.04 Xenial Xerus and the VDR Manager App on Android here on my webpage


xfce4: xfwm4: Tune the windowmanager to switch from one workspace to another and back

May 23, 2011

As already mentionend in this blog, I use xfce4 with 10 different workspaces. Important applications run on dedicated workspaces, e.g. firefox on #3, emacs on #4 and so on.

You may switch from one workspace to another very conveniently by keyboard (per default e.g. for workspace #3).

There is one more configuration option, which is unfortunately off by default. You will find it in the xfce-config tools under “Detailed configuration of the window manager”. Select the tab Workspaces. There is a line reading similar to “Remember last workspace, use it again when changing via keyboard shortcuts”. If you check this, bring you to the workspace #n. Pressing the same shortcut again, it will you bring back where you came from.

IMHO very convenient.

Using a shell you may set this via xfconf-query:

xfconf-query -c xfwm4 -p /general/toggle_workspaces -s true

jaunty: Resizing mpg using tcrequant gives bad quality output with lots of artifacts

December 19, 2009

Running Hardy for a year or so I used tcrequant without any problems. I use the tool to resize mpg files so that they fit onto a dvd. My wife prefers watching our home recorded videos this way …

After upgrading to Jaunty I realized that resized records came with artifacts. It turned out that tcrequant caused it.

In Hardy, I had:

root@jojo:~# /usr/bin/tcrequant -v
tcrequant (transcode v1.0.2) (C) 2003 Antoine Missout

With Jaunty came:

root@jojo:~# /usr/bin/tcrequant -v
tcrequant (transcode v1.0.7) (C) 2003 Antoine Missout

I found no way around and finally ended up with replacing the Jaunty binary by the old Hardy tcrequant binary. Yes – this is ugly …

If you are asking: Why do you use tcrequant anyway ? It’s said to be deprecated in Transcode ! May be – but have you ever compared the run time of avidemux or mencoder with tcrequant ? The latter is far quicker. Obviously quite different algorithms are used. But I’m lucky with the output of tcrequant 1.02 …

Java application issues: Lifebook reinstalled with i386

May 20, 2008

Yesterday I had my new Lifebook the first day in production. Unfortunately I had issues with a Java application which refused to start with the default Java in Hardy (I have to run Avocent DSView 3 to get server consoles and this is implemented in Java …).

So with openjdk-6-jre etc. and icedtea-gcjwebplugin as Web Browser Plugin
the application hung while loading. So I tried to switch back to sun-java5-jre but I had to learn that there is no package sun-java5-plugin for x86_64.

I can’t live without that ugly application – so in the evening I reinstalled my Lifebook with i386.

This is not fun – suggestions welcome !

Using tar and netcat to backup filesystems: A pitfall resulting in broken links and how to avoid it

January 16, 2008

As shown in yesterday’s blog entry, I failed to recover my Feisty laptop due to missing links. Remembering the old saying “Every fool may do a backup” I now managed to find my mistake.

The error may be shown using localhost, so here we go:

First I started the listening netcat like this:

cd /tmp
netcat -l -p 2342 | tar xvf -

Then I backuped /sbin using:

cd /
tar cf - sbin | netcat localhost 2342

Both processes do not stop, until you hit CTRL-C. And at this point I did a mistake: I hit CTRL-C on the receiving side (I saw no further files coming in). DO NOT DO THIS – IT WILL EVENTUALLY LEAVE YOU WITH BROKEN LINKS. E.g. instead of

root@lulu:/tmp# ls -l sbin/ip
lrwxrwxrwx 1 root root 7 2008-01-16 11:33 sbin/ip -> /bin/ip

you will have

root@lulu:/tmp# ls -l sbin/ip
---------- 1 root root 0 2008-01-16 11:28 sbin/ip

Let us dig a little bit deeper using strace. Again start the listening side and then the sending side. Do not hit CTRL-C. Looking at the process list you will see that the sending tar has finished, the receiving tar is still there. Strace this process and hit CTRL-C on the sending side. Check sbin/ip and you will find a link correctly pointing to /bin/ip.

This is the strace output:

root@lulu:/tmp# cat receiving-tar.strace
8394 read(0, "", 10240) = 0
8394 clock_gettime(CLOCK_REALTIME, {1200479622, 923188961}) = 0
8394 clock_gettime(CLOCK_REALTIME, {1200479622, 923263552}) = 0
8394 close(0) = 0
8394 SYS_299(0xffffff9c, 0x808e6a5, 0xbfd650fc, 0x808e6a5, 0xb7f6eff4) = 0
8394 chmod("sbin", 0755) = 0
8394 chown32("sbin", 0, 0) = 0
8394 lstat64("sbin/lsmod", {st_mode=S_IFREG, st_size=0, ...}) = 0
8394 unlink("sbin/lsmod") = 0
8394 symlink("/bin/lsmod", "sbin/lsmod") = 0
8394 lchown32("sbin/lsmod", 0, 0) = 0
8394 lstat64("sbin/ip", {st_mode=S_IFREG, st_size=0, ...}) = 0
8394 unlink("sbin/ip") = 0
8394 symlink("/bin/ip", "sbin/ip") = 0
8394 lchown32("sbin/ip", 0, 0) = 0
8394 close(1) = 0
8394 munmap(0xb7cff000, 4096) = 0
8394 exit_group(0) = ?

Obviously tar handles the symbolic links not in the moment as they appear but in some final procedure. When I hitted CTRL-C on the receiving side I prevented tar to run that final procedure as this strace clearly shows:

root@lulu:/tmp# cat receiving-tar-ctrl-c
8495 read(0, "", 10240) = 0
8495 --- SIGINT (Interrupt) @ 0 (0) ---

So you really must hit CTRL-C only on the sending side, interrupting netcat, which is safe as the sending tar already has gone.

Even better: Use netcat’s q option for the sending netcat, e.g.

Receiving process:

root@lulu:/tmp# netcat -l -p 2342 | tar xvf -

Sending side:

root@lulu:/# tar cf - sbin | netcat -q 2 localhost 2342

With -q 2, netcat stop go away 2 secs after detecting EOF on stdin. The receiving netcat then will go away too.

So my conclusion:

Always use tar + netcat this way:

Receiving side:

netcat -l -p 2342 | tar xvf –

Sending side:

tar cf – whatever-you-want-to-backup | netcat -q 2 localhost 2342

Never omit -q !


Just a hint for those using e.g. SuSE: Though netcat version is 1.10 (same as in Feisty) option -q ist not available (there are others missing too). So in SuSE you must hit CTRL-C on the right side …

Hard disk failure: Additional sense: Unrecovered read error – auto reallocate failed

January 15, 2008

Last week my laptop suddenly refused to boot any longer. Having configured nothing as root for quite some time, I read:

grub: Error 29: Disk write error

After restarting I got this error again. So I booted my Feisty cdrom and started to inspect the system. There was no obvious error in the first place. Being in a networked environment I decided to save my $HOME using netcat. This worked fine. So in the next step I backuped the root file system. This too worked fine. I finally tried to save another partition containing data of a virtual machine I use with vmplayer.

This failed spitting out a lot of driver error messages, e.g.

Additional sense: Unrecovered read error - auto reallocate failed

But the tar came back finally, saying:

root@ubuntu:/# tar cf - mnt | netcat cheetah 2342
tar: mnt/now2/now2-s004.vmdk: File shrank by 944635904 bytes; padding with zeros

To make a long story short:

After replacing the disk, restoring the filesystems, fixing grub and /etc/fstab my system came up – but with a lot of error messages. I could log in and after a while I found that all links like this one in /sbin were broken:

lrwxrwxrwx 1 root root 7 2008-01-15 14:30 ip -> /bin/ip

Instead I found:

---------- 1 root root 0 2008-01-15 14:50 ip

I fixed a lot of missing links in /sbin, /bin and all of the run level scripts manually. But finally I gave up because I did not find a method to fix the links in a really reliable way (apt, dpkg do not seem to help here – no way to rerun postinstall scripts IMHO).

So finally I reinstalled my laptop. Fortunately all data in $HOME was fine, so I was up and running again rather soon.

Nevertheless: Why failed my backup procedure ?

Solved: See next blog entry

Boot fails after Windows trouble: Use GRUB from Live-CD to reinstall MBR

December 6, 2007

The other day a colleague did some maintenance work on a multiboot system. Unfortunately he ended up with a completely unbootable system.

This was the right moment to have the Ubuntu CD ready. We booted Gutsy and then:

sudo su

At the grub prompt, we typed root space left bracket and then the TAB key:

grub> root (hd0,
Possible partitions are:
Partition num: 0, Filesystem type unknown, partition type 0x7
Partition num: 1, Filesystem type unknown, partition type 0x7
Partition num: 2, Filesystem type is ext2fs, partition type 0x83
Partition num: 4, Filesystem type unknown, partition type 0x82

This was an easy decision. There is only one partition, which carries an ext2. So input 2:

grub> root (hd0,2)

Now GRUB knows where to take his files from. The second and final step is to run setup. Again TAB is your friend.

grub> setup (hd0)
Checking if "/boot/grub/stage1" exists... yes
Checking if "/boot/grub/stage2" exists... yes
Checking if "/boot/grub/e2fs_stage1_5" exists... yes
Running "embed /boot/grub/e2fs_stage1_5 (hd0)"... 17 sectors are embedded.
Running "install /boot/grub/stage1 (hd0) (hd0)1+17 p (hd0,2)/boot/grub/stage2
/boot/grub/menu.lst"... succeeded

Please note that in this case we wanted to replace the MBR. That is why we wrote (hd0).
Finally leave grub with quit.

If for any reason you are not able to use the above described method root + TAB, you may use the find command in GRUB:

grub> find /boot/grub/stage1

Gutsy completely unusable for me: Hard freeze

December 2, 2007


running Feisty quite happily, I installed Gutsy on my laptop on a separate partition ( I use the laptop all the time and can take not risks here).

As always, the first thing I tested was Suspend to disk. It did not work (screen went black in a second. I had to switch off power finally). I then decided to take a deeper look later. When I clicked reboot, again: Screen black. I had to switch off.

Today I found time to test again. At first, I updated the box. Then I started testing. I soon found, that simply logging off sometimes made the box freeze. I logged in via ssh to get more information, but as the ssh session also froze, I decided to start netconsole to get any kernel messages. I activated magic key and then switched from X to console, as I wanted to play with Alt-SysRq.

Oops: The box immediately froze !!!

Luckily this sems to be reproducable, so I filed a bug:

Using DSL with pppd and pppoe in Feisty with suspend and resume

November 19, 2007


the other day I set up a Feisty box directly connected to a DSL modem. So I had to use pppd and pppoe. The setup utility pppoeconf was already on the system (in /usr/sbin), but the package pppoe was missing (does that make sense: pppoeconf without pppoe ???). I installed pppoe and ran pppoeconf.

A minute later I was online.

After rebooting I was online again. But after suspending the box to disk and resuming there was pppd still kind of running – but useless. IMHO this is ok.

But the user expects to be online again of course.

This is what I did:

lulu:/etc/acpi/suspend.d> cat


lulu:/etc/acpi/resume.d> cat

I intended to terminate pppd via poff when suspending and start a fresh pppd when resuming was nearly finished.

This did not really work. I found an error message telling me that the interface was not up. So I added

ifconfig eth0 up

to the script. I thought I was done now, but at least occasionally the link was not up when I started to access the net.


lulu:/etc/acpi/resume.d> cat
ifconfig eth0 up
sleep 2
sleep 2

this works now fine.


sudo netstat -nlp --inet

I finally closed all ports. (System | Services).