Skip to content

dpkg: invalid character in version number

After upgrading to "PrecisePangolin", this message got printed whenever dpkg wanted to install a package:
dpkg: warning: parsing file '/var/lib/dpkg/available' near line 262698 \
          package 'lightning-extension-locale-hu':
 'Depends' field, reference to 'lightning-extension': error in version: \
          invalid character in version number
dpkg: warning: parsing file '/var/lib/dpkg/available' near line 76038 \
          package 'am-utils':
 'Replaces' field, reference to 'amd': error in version: \
          version number does not start with digit
This got printed a few times, for every package with a weird entry. Apparently /var/lib/dpkg/available got mangled during the upgrade:
Package: lightning-extension-locale-hu
Depends: lightning-extension (>= 0.7), lightning-extension (<< 0.7.*)
[...]
Package: am-utils
Replaces: amd (<= upl102-35)
Bug reports for this issue are usually being closed, so I refered to the suggested practice of clearing the available database:
$ dpkg --clear-avail
And it worked, dpkg installs much quieter now :-)

Can't keep data. Incompatible partition. Press DELETE if data loss OK or any other key to cancel

This v40z has an LSI 53C1030 SCSI Controller and I wanted to build a RAID1 array out of the two disks present. However, once in the configuration menu (press CTRL+C when the MPTBIOS is being initialized), it's impossible to add any disk to a RAID array:
 Adapter PropertiesRAID Properties → 
 Select a disk and press +
Now the following choices appear:
       F3 – Keep Data (Create 2 disk array)
 Delete – Erase Disk (Create 2 to 6 disk array)
I didn't care for the data and pressed Delete to build a fresh array. But this didn't happen, instead the following was printed:
 Can't keep data. Incompatible partition.
 Press DELETE if data loss OK or any other key to cancel
The user guide even has entry for this, suggesting to remove any partitions of type 8e (Linux LVM) from the primary disk. Well, the disks in question had an operating system installed, not a single partition was of type 0x8e.

Anyway, I booted the system into a recovery, deleted all partitions and created just one single partition of type 0x83 (Linux). Again in the MPTBIOS and I still cannot create a RAID array, as the very same error message appeared. Grrr.

Back into recovery and to delete the single 0x83 partition created earlier. That did the trick, now MPTBIOS did not complain and the RAID array is now in place. Yay! :-)

T-Mobile & ICS - but no tethering?

The wait is finally over, T-Mobile USA releases ICS for the HTC Sensation. But once the update is installed, tethering won't be "free" anymore? With "free" I meant "included in their already ridiculously expensive plans for their lousy 4G service", of course.

Sure, their Terms & Conditions are pretty clear on that:

Your Data Plan is intended for Web browsing, messaging, and similar
activities on your Device and not on any other equipment. Unless
explicitly permitted by your Data Plan, other uses, including for
example, using your Device as a modem or tethering your Device to
a personal computer or other hardware, are not permitted.
So, while having (and using) this feature before, T-Mobile was simply not enforcing their own policies. But come on, guys - it's 2012: releasing a belated ICS and at the same time disable on of the more useful features (not to mention cluttering it with your "branding") seems like one step forward, two steps backward to me. With no CyanogenMod readily available, I guess I'm gonna stick to v2.3.4 for now :-\

NFSv4: /mnt/nfs was not found in /proc/mounts

This machine had a stale NFS mount. But attempting to unmount gave a rather strange message:
$ umount /mnt/nfs
/mnt/nfs was not found in /proc/mounts
Let's look at mtab first:
$ mount | grep nfs
server:/mnt/export/dir0 on /mnt/nfs type nfs (ro,vers=4,addr=10.0.0.10,clientaddr=10.0.0.30)
OK, but why isn't it found in /proc/mounts then?
$ grep nfs /proc/mounts 
server:/mnt/export/dir0 /mnt/nfs\040(deleted) \
                   nfs4  ro,nosuid,nodev,noexec,relatime,\
                   vers=4,rsize=131072,wsize=131072,namlen=255,\
                   hard,proto=tcp,port=0,timeo=600,retrans=2,\
                   sec=sys,local_lock=none,clientaddr=10.0.0.30,\
                   minorversion=0,addr=10.0.0.10 0 0
Hah! Somehow the entry in /proc/mounts got mangled. OK, \040 is octal for SPACE. But umount(8) still fails:
$ umount /mnt/nfs\ \(deleted\)
umount.nfs: /mnt/nfs (deleted): not found
umount.nfs: /mnt/nfs (deleted): not found
Apparently umount(8) tried to find the entries from /proc/mounts in /etc/mtab but failed, due to the mismatch of both files. After adding \040(deleted) to the local-directory part in /etc/mtab, umount(8) did something:
$ umount /mnt/nfs*
umount: /mnt/nfs Stale NFS file handle
The entry got removed from /etc/mtab, but the mangled entry still shows up in /proc/mounts. Now all is left is a stale NFS file handle:
$ umount -f /mnt/nfs
umount2: Stale NFS file handle
umount: /mnt/nfs: Stale NFS file handle
Sadly, this could only be cured by a reboot :-\

Fedora dependency madness

$ yum install mysql-server
Loaded plugins: changelog
Resolving Dependencies
--> Running transaction check
[...]
Dependencies Resolved

 Package
====================================
Installing:
 mysql-server                              
Installing for dependencies:
 libaio                                    
 libevent                                  
 perl-AnyEvent                             
 perl-AnyEvent-AIO                         
 perl-AnyEvent-BDB                         
 perl-Async-MergePoint                     
 perl-BDB                                  
 perl-Compress-Raw-Bzip2                   
 perl-Compress-Raw-Zlib                    
 perl-Coro                                 
 perl-Curses                               
 perl-DBD-MySQL                            
 perl-DBI                                  
 perl-EV                                   
 perl-Encode-Locale                        
 perl-Event                                
 perl-Event-Lib                            
 perl-Glib                                 
 perl-Guard                                
 perl-HTML-Parser                          
 perl-HTML-Tagset                          
 perl-HTTP-Date                            
 perl-HTTP-Message                         
 perl-Heap                                 
 perl-IO-AIO                               
 perl-IO-Async                             
 perl-IO-Compress                          
 perl-IO-Socket-SSL                        
 perl-IO-Tty                               
 perl-LWP-MediaTypes                       
 perl-Net-HTTP                             
 perl-Net-LibIDN                           
 perl-Net-SSLeay                           
 perl-POE                                  
 perl-Socket-GetAddrInfo                   
 perl-Socket6                              
 perl-TermReadKey                          
 perl-TimeDate                             
 perl-URI                                  
 perl-common-sense                         
Transaction Summary
===========================================
Install  1 Package (+40 Dependent packages)
Total download size: 13 M
Installed size: 51 M
Is this ok [y/N]:  
Seriously? I thought had hoped the times of RPM's dependency hell were over?

Pacific vs. Pacific-New

While configuring tzdata, the debconf dialog asked:
 Please select the city or region corresponding to your time zone.
 Time zone: 
   [...]
   Mountain
   Pacific
   Pacific-New
   [...]
Huh? WTF is Pacific-New? Looking around one can find #524046 from 2009, where the "pacificnew" zonefile got included without any debate. In fact, the zonefiles appear to be equal in every detail:
$ ls -ligo /usr/share/zoneinfo/US/Pacific /usr/share/zoneinfo/US/Pacific-New
352130 -rw-r--r-- 2 2819 Oct 31 15:49 /usr/share/zoneinfo/US/Pacific
352130 -rw-r--r-- 2 2819 Oct 31 15:49 /usr/share/zoneinfo/US/Pacific-New
And even their checksums match. That being established, I think it's safe to just choose "Pacific" and be done with it. Who knows when they will remove the Pacific-New zonefile again...

Fuzzy uniq & colorized HTML diffs

The other day I came across a file full of these infamous "Alle Kinder..." jokes. But the file was rich in almost-duplicates:
$ grep Liter alle-kinder.txt 
Alle Kinder sind besoffen, nur nicht Dieter, der trinkt noch 'n Liter
Alle Kinder sind besoffen, nur nicht Dieter, der trinkt noch nen Liter
Alle Kinder sind besoffen. nur nicht Dieter, der trinkt noch 'n Liter.
So I could not just use sort(1) and filter out the duplicates - because they were not really duplicates. So I needed something to look for similar jokes in that file and filter them out, just like uniq(1) would do.

Luckily the internet is here to help, as always, and I came across this fantastic script: a fuzzy version of uniq(1). Running the file through the script, only one of the 3 occurences of the same joke is left:
$ funiq.sh alle-kinder.txt | grep Liter
Alle Kinder sind besoffen, nur nicht Dieter, der trinkt noch 'n Liter.
Great! Oh, but then it'd be interesting to see which entries got kicked by the fuzzy uniq script. Sure, diff(1) could do that. But for some reason I wanted diff's output in color. Hm, ColorDiff? But what if I wanted the output to be HTML too? Don't ask what gave me that idea but it's nice to know that other people are equally crazy and put up a bash script to convert diff output into colorized HTML. Yeah, you got that right:
$ diff -u alle-kinder.txt alle-kinder_fuzzy.txt | diff2html.sh | tidy > diff.html
And out comes something like this :-)

Upside-Down-Ternet

With April Fool's Day coming closer, it's time for yet another Upside-Down-Ternet howto - only this time with OpenWrt redirecting to an external Squid proxy. The setup in short:
  • Install Squid3, with the following settings in squid.conf:
      acl localnet src 10.0.0.0/24
      http_access allow localnet
      http_port 3128 intercept
      url_rewrite_program /usr/local/bin/flip.pl
    
  • The /usr/local/bin/flip.pl does the actual work and turns the images upside down. There are a lot of other scripts to choose from :-)

  • Configure your local webserver, so that the URL from flip.pl can be served. Also, one must take care that permissions are set correctly:
      mkdir -m2750 /var/www/ternet
      chown proxy:www-data /var/www/ternet
    
    This way, the Squid proxy running as user "proxy" can write to the directory while the webserver, running as user "www-data" can read from it.

  • Since there's OpenWrt running on our gateway, we have all the iptables power we need to redirect traffic to our Squid proxy:
    SRC=10.0.0.0/24
    IFACE=br-lan
    ROUTER=10.0.0.1
    PROXY=10.0.0.20
    PROXY_PORT=3128
     iptables -t nat -A prerouting_rule \
         -i $IFACE ! -s $PROXY -p tcp --dport 80 -j DNAT --to $PROXY:$PROXY_PORT
     iptables -t nat -A postrouting_rule \
         -o $IFACE -s $SRC -d $PROXY -j SNAT --to $ROUTER
     iptables -A forwarding_rule \
         -i $IFACE -o $IFACE -s $SRC -d $PROXY -p tcp --dport $PROXY_PORT -j ACCEPT
    
    Note: We're using the internal OpenWrt chains here, instead of the predefined PREROUTING, POSTROUTING, FORWARD chains. This way our rules actually get inserted rather than appended to any existing rules.

mysqldump: Incorrect key file for table

Today, mysqldump complained about:
[...]
mysqldump: Couldn't execute 'SELECT /*!40001 SQL_NO_CACHE */ * FROM `COLUMNS`': 
        Incorrect key file for table '/var/run/mysqld/#sql_2935_0.MYI'; 
        try to repair it (126)
mysqldump: Got error: 126: Incorrect key file for table '/var/run/mysqld/#sql_2935_0.MYI'; 
        try to repair it when retrieving data from server
Well, the error message is pretty clear - but there's no table in /var/run/mysqld. In fact, no database should reside in this directory! The server's my.cnf has:
  datadir         = /var/lib/mysql
  tmpdir          = /var/run/mysqld
So, what was going on here? Of course, the internet was there to help :-) Because /var/run was mounted as tmpfs and only 10MB in size, mysqldump appears to have exceeded this space. Resizing /var/run helped:
$ mount -o remount,size=134217728 /var/run                # 128M
Watching /var/run during the next mysqldump run shows how much memory is needed for it to complete:
varrun                128M  2.2M  126M   2% /var/run
varrun                128M  3.8M  125M   3% /var/run
varrun                128M  4.3M  124M   4% /var/run
varrun                128M  5.9M  123M   5% /var/run
varrun                128M  7.6M  121M   6% /var/run
varrun                128M  8.6M  120M   7% /var/run
varrun                128M   11M  118M   8% /var/run
varrun                128M   12M  117M   9% /var/run
varrun                128M   13M  116M  10% /var/run
varrun                128M  1.3M  127M   2% /var/run
All databases combined are only ~750MB in size, but resizing /var/run a bit might have been long overdue anyway :-)

openSUSE dependency madness

No, I'm not bored - just curious what the other camps are up to. This time: openSUSE 12.1. Of course, after a minimal installation a few things are missing. Manpages, for example. But what the hell is this:
   $ zypper install man
   The following NEW packages are going to be installed:
     cups-libs fontconfig ghostscript-fonts-other ghostscript-fonts-std 
     ghostscript-library groff groff-devx lcms libfreetype6 libgimpprint
     libjpeg62 liblcms1 libpng14-14 libtiff3 man 

   The following recommended packages were automatically selected:
     ghostscript-fonts-other ghostscript-library 

   15 new packages to install.
   Overall download size: 14.9 MiB. After the operation, additional 67.8 MiB will be used.
15 new packages, almost 70 MB for a bunch of text files. And why would I need cups-libs or libjpeg62? Luckily, zypper too can be tought not to install recommended packages:
   $ zypper install --no-recommends man
   The following NEW packages are going to be installed:
     groff man 

   2 new packages to install.
   Overall download size: 2.4 MiB. After the operation, additional 10.0 MiB will be used.
Much better :-) There's an installRecommends switch in /etc/zypp/zypper.conf, but this was not honored by zypper 1.6.18 :-\

Sadly, this does not help with all packages:
   $ zypper install --no-recommends nginx
   The following NEW packages are going to be installed:
     fontconfig gd libfreetype6 libGeoIP1 libjpeg62 libpng14-14 libxslt1 nginx-1.0 
     xorg-x11-libICE xorg-x11-libSM xorg-x11-libX11 xorg-x11-libXau 
     xorg-x11-libxcb xorg-x11-libXext xorg-x11-libXpm xorg-x11-libXt 

   16 new packages to install.
   Overall download size: 3.0 MiB. After the operation, additional 11.8 MiB will be used.
Really? openSUSE has bundled a webserver with Xorg libraries? Sigh... I can already smell the b0rkage when the next update is due and zypper is trying to untangle all the dependencies for every friggin' package ever installed because of insane dependencies like this.

Oh, and while we're at it: you might want to remove patterns-openSUSE-minimal_base-conflicts otherwise lots of packages won't install.

No sound in MacOS 10.7?

Well, now that more and more fanboys have upgraded to 10.7, the forums are full of it: sometimes it happens that sound stops working in MacOS Lion.
As it turns out, restarting coreaudiod is all it takes to get it working again:
$ launchctl list | grep audio
7159    -       com.apple.audio.coreaudiod

$ launchctl stop com.apple.audio.coreaudiod

$ sudo launchctl list | grep audio
7589    -       com.apple.audio.coreaudiod

XCode: You have updates available for other accounts

Logged in to my Mac App Store account today, the "Purchases" tab greeted me with an update for Xcode. However, clicking on it only resulted in the following:
  You have updates available for other accounts.
  Sign into the account you used to purchase it.
Huh? I don't have any other accounts. One Apple account is more than enough :-\
So, what's the deal here? Luckily, others had similar issues and a solution as well. Either one should do:
  • Delete or move /Applications/Install Xcode.app resp. Install XCode.dmg, usually found in /Applications as well. Then try again to update Xcode.
  • Refresh your Spotlight index. I.e. add/remove your system disk to the index, then try again to update.

MacOS X automount

Sure, Disk Utility.app can be used to set up NFS mounts. But as long as automount(8) is supported in MacOS X, let's use this for a more general approach:

Create the mount points first, both for SMB and NFS:
  $ mkdir /mnt/{nfs,smb}/{a,b}
Then we create automount ''maps'' for each protocol:
 $ cat /etc/auto_nfs 
 /mnt/nfs/a -fstype=nfs,rw,resvport 10.0.0.10:/export/foo
 /mnt/nfs/b -fstype=nfs,ro,resvport 10.0.0.10:/export/bar
 
 $ cat /etc/auto_smb 
 /mnt/smb/a -fstype=smbfs,rw ://10.0.0.10/foo
 /mnt/smb/b -fstype=smbfs,ro ://10.0.0.10/bar
With that in place, we have to include both files in auto_master(5)
 $ grep -v ^\# /etc/auto_master
 +auto_master            # Use directory service
 /-                      auto_smb
 /-                      auto_nfs
Tell automountd(8) to flush any cached information:
 $ automount -v -c
Sometimes it's necessary to restart automountd:
 $ launchctl stop  com.apple.automountd
 $ launchctl start com.apple.automountd
Now the shares should be mounted automatically upon access.

Ignoring unknown extended header keyword `SCHILY.dev'

While extracting a tarball, GNU/tar told me:
Ignoring unknown extended header keyword `SCHILY.dev'
Ignoring unknown extended header keyword `SCHILY.ino'
Ignoring unknown extended header keyword `SCHILY.nlink'
Hm, what does that remind me of? Ah, star! Digging in the bits still left on BerliOS, there seems to be something what looks like a POSIX proposal:
$ cat star/README.posix-2001
[...]
        Star supports the following fields in the extended header:
[...]
        Vendor unique:
        "SCHILY.devmajor" "SCHILY.devminor"     (create/extract)

        In -dump mode (a preparation for incremental dumps) star archives:

        "SCHILY.dev"            The field stat.st_dev   - the filesys indicator
        "SCHILY.ino"            The field stat.st_ino   - the file ID #
        "SCHILY.nlink"          The field stat.st_nlink - the hard link count
        "SCHILY.filetype"       The real file type      - this allows e.g.
                                                              socket/door
Wow. Alas, these headers remain unrecognized in GNU/tar, hence the (benign) warnings.