Skip to main content

bash completion: /dev/fd/62: No such file or directory

No need to cite the whole article (thanks!), so here's a short version: after upgrading from etch to lenny, bash completion would not work any more in this DomU:

# tail -f /var<TAB>-bash: /dev/fd/62: No such file or directory
-bash: /dev/fd/60: No such file or directory
# sudo ln -s /proc/self/fd /dev/fd
...or just install udev, although this package was not needed before the upgrade. Oh, there's a bug report for this one too.

what's wrong with grep(1)?

OK, I should not be so surprised anymore, but what the hell, man? What's wrong with grep that it's so horribly slow sometimes?

$ ls -lgoh mbox
-rw-r--r--  1   75M Feb 15 17:14 mbox

$ time /opt/grep/bin/egrep '^M|^begin|^end$' mbox | wc -l

real	11m15.924s
user	9m50.645s
sys	1m18.155s

$ time awk '/^M/ || /^begin/ || /^end$/' mbox | wc -l

real	0m2.110s
user	0m2.532s
sys	0m0.176s
(GNU grep 2.6-cvs, 2009 / awk version 20040207)

zpool.cache lost

Yet another incident with this E250. There must be something wrong with its SCSI controller, as it's throwing scsi errors every now and then. And sometimes it even corrupts the rootfs, which is still running on UFS. It's mirrored, yes - but when the controller decides to write crappy data, the filesystem gets corrupted anyway. So, I fsck'ed the filesystem and at one point it prompted me to:

DUP/BAD  I=26761  OWNER=root MODE=100644
SIZE=2764 MTIME=Feb  5 14:44 2009 

Well, what choice did I have? It's a "cache" file anyway, right? Oh boy was I suprised when I rebooted and all my ZFS pools were gone. Luckily zpool import is there to help:
   zpool import [-d dir] [-D]
         Lists pools available to import. If the -d option is not
         specified,   this   command   searches  for  devices  in
With -a added, it imported all pools, mounted them and created this /etc/zfs/zpool.cache file again. Yeah, ZFS :)


$ grep CONFIG_SCSI_WAIT_SCAN .config
$ make oldconfig
$ grep CONFIG_SCSI_WAIT_SCAN .config
Hm, but what does it all mean? This option does not even show up in menuconfig. This has been discussed numerous times and on LKML as well. The short story is:
The wait scan module is designed to wait for scans of driver modules.
Whether SCSI=y or m has no effect on this ... you can still have modular
drivers with built in SCSI. 
And since we don't know if there are any (out-of-tree) SCSI driver modules around, we just build this module. Except when CONFIG_MODULE=n is set. But I still fail to understand why we need a .config option, when it's not (de)selectable anyway? But then again I may not fully comprehend the module-vs-builtin paradigm and SCSI_WAIT_SCAN behaves differently when builtin?

OpenSSH config parser borked in MacOS X?

Sometimes I like to use certain ciphers for different hosts (for performance reasons). But the OpenSSH version (v5.1p1, OpenSSL 0.9.7l 28 Sep 2006) in MacOS 10.4.11 seems to read the config only halfway:

alice$ cat .ssh/config.test 
Host *
        Ciphers                 arcfour128
Host bob
        Ciphers                 arcfour

alice$ ssh -F .ssh/config.test bob
no matching cipher found: client arcfour128 server aes128-cbc,3des-cbc,[...]
It should've used 'arcfour', since the ssh2d does not understand all OpenSSH ciphers. When changing the global cipher preferences to something else, everything works as expected:
alice$ cat .ssh/config.test 
Host *
        Ciphers                 aes128-cbc
Host bob
        Ciphers                 arcfour

alice$ ssh -F .ssh/config.test bob

md5sum b0rked in Fink?

As MacOS X still doesn't ship with some md5sum equivalent, I gabbed the Fink version. Strange, that it got installed along with the dpkg package, as there's the coreutils package too. Anyway, in most cases I'd like to *verify* checksums, not generate them. The manpage says:

-c  Check md5sum of all files listed in file against the checksum listed
    in the same file. The actual format of that file is the same as output
    of md5sum.
...and then it goes on to tell us how to *generate* a checksum, oh well. But -c doesn't even work:
$ md5sum -c MD5SUM.txt
usage: md5sum [-bv] [-c [file]] | [file...]
Generates or checks MD5 Message Digests
    -c  check message digests (default is generate)
The input for -c should be the list of message digests and file names
that is printed on stdout by this program when it generates digests.
$ tail -1 MD5SUM.txt
677ecebf8ca5c5135dc1c951a34d42b5  cd_diags.iso
What's wrong here? Is md5sum really b0rked? Or is it just PEBKAC? So, here goes a quick 'n dirty workaround for verifying lots of files:
$ FILE=/path/to/md5sum.txt
$ for i in `awk '{print $2}' "$FILE"`; do \
   test -f "$i" || continue && C=`openssl md5 $i | awk '{print $2}'` && \
   egrep -q "$C  $i" "$FILE" && echo "FILE: $i OK" || echo "FILE: $i FAILED"

gnutls_handshake: Error in the push function.

Sometimes, when sending mails with attachments /var/log/exim4/mainlog says:

TLS error on connection from (hostname) [ipaddress] (gnutls_handshake):\
  Error in the push function.
I did not get around to dig deeper here, but - note to self: find out if this is related to #482012 and if setting MAIN_TLS_TRY_VERIFY_HOSTS to an empty value really helps.

.Inode not directory

OK, when searching for this one the first hit is currently the one you're looking for. So let's just place a short copy here. The story so far: when converting your rootdisk to a RAID-1 as described by the really amazing guide, one might encounter, at least on netbsd-4.0.1/sparc64:

ok boot disk 
Boot device: /pci@1f,4000/scsi@3/disk@0,0  File and args:
NetBSD IEEE 1275 Bootblock
.Inode not directory
...and then it stops. The solution is to install the bootblock again, but with a fixed version of /usr/mdec/bootblk:
# ftp
# get /pub/NetBSD-daily/netbsd-5/200812250000Z/sparc64/binary/sets/base.tgz
# gzip -dc base.tgz | tar -xf - ./usr/mdec/bootblk
# mv  usr/mdec/bootblk /usr/mdec/bootblk-5
# /usr/sbin/installboot -v /dev/rsd0a /usr/mdec/bootblk-5
Booting with "boot disk" will succeed, although this particular error message did not go away on our Ultra-60.
Update: PR 40306 has been opened to track this.