Skip to content

Conversion from character set '646' to 'UTF-8' is not supported

While trying to setup syslog-ng on Solaris 10, I've come across:
# /usr/local/sbin/syslog-ng
Error parsing command line arguments: Conversion from character set '646'
to 'UTF-8' is not supported
Several places on the net lead me to suspect a missing charset.alias file. And indeed, syslog-ng was looking for one:
# truss -elfda /usr/local/sbin/syslog-ng 2>&1 | grep charset
29850/1:  1.9301 open64("/usr/local/lib/charset.alias", O_RDONLY) Err#2 ENOENT

# locate charset.alias
# ln -s /usr/lib/charset.alias /usr/local/lib/charset.alias
...Now syslog-ng is working fine. This does not seem to be syslog-ng related, but may help other applications as well. To be confirmed though....

Resizing a LUKS/dm-crypt partition on top of LVM

While there exist a few howtos to resize logical volumes on top of dm-crypt devices, I was looking for information on how to enlarge a dm-crypt device, which is backed by a LVM volume. And I found it, in short:
# umount /dev/mapper/backup
# lvextend -L +10G vg02/backup
  Extending logical volume backup to 40.00 GB
  Logical volume backup successfully resized
# cryptsetup status backup
/dev/mapper/backup is active:
  cipher:  aes-cbc-essiv:sha256
  keysize: 192 bits
  device:  /dev/mapper/vg02-backup
  offset:  1544 sectors
  size:    62913016 sectors
  mode:    read/write
# cryptsetup resize /dev/mapper/backup
# cryptsetup status backup
/dev/mapper/backup is active:
  cipher:  aes-cbc-essiv:sha256
  keysize: 192 bits
  device:  /dev/mapper/vg02-backup
  offset:  1544 sectors
  size:    83884536 sectors
  mode:    read/write

# resize2fs -p /dev/mapper/backup
resize2fs 1.40.8 (13-Mar-2008)
Resizing the filesystem on /dev/mapper/backup to 10485567 (4k) blocks.
Begin pass 1 (max = 80)
The filesystem on /dev/mapper/backup is now 10485567 blocks long.

# fsck.ext3 -Dfv /dev/mapper/backup
# mount /dev/mapper/backup /mnt/backup/
# df -h /mnt/backup/
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/backup     40G   29G  9.7G  75% /mnt/backup

# dpkg -s cryptsetup | grep ^Version
Version: 2:1.0.5-2ubuntu12

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?