Skip to main content

Oracle Solaris checksums

While OpenSolaris still lists them, I couldn't find checksums for Oracle Solaris on the download page. Fortunately I found their E-Delivery site, although it's a bit cryptic to use.

For my just downloaded I have to choose "Oracle Solaris" and "Oracle Solaris on x86-64 (64bit)" and then select the "Oracle Solaris 10 9/10 Operating System Multi-Language Media Pack". Now I'm presented with 3 different downloads (not necessarily related to my selection earlier), each of them has a "Part number.

By clicking "View Digest" I'm presented with the MD5 and SHA-1 digests of those part numbers (with .zip added) - so I have to switch back to the other window again to find out which part number I'm looking for at the digest site. Oh dear. Well, here are the digests for the current Oracle Solaris release:

    MD5       3A24F5746EBAB5F254C359F979E644F7
    SHA-1     98953B5AECDE175831003A44FB5752B9C6E783AC
  • (
  •     MD5       CB55F4B7AF194F6378AA5F304F3EA8FC
        SHA-1     5701FC18978337B163AD50F06DD0460F90E9AF8F
    Let's all hope they're adding those checksums to the download page again...

    aio_queue_async_request: too many in flight for proc: 16

    Lateley I've been seeing the following on this MacOS 10.6.4 (xnu-1504.7.4):

       aio_queue_async_request(): too many in flight for proc: 16.
    This is logged over and over again to the kernel log. The messages stem from bsd/kern/kern_aio.c, but I suspect the "rude" application doing this might be VirtualBox. That's the toughest application on this box anyway and I noticed quite a few (new) messages when VirtualBox is running. And since the VM in question was running suspiciously slow, I'm tempted to tune these limits. How about:
    # sysctl -w kern.aiomax=128 kern.aioprocmax=32 kern.aiothreads=8
    kern.aiomax: 90 -> 128
    kern.aioprocmax: 16 -> 32
    kern.aiothreads: 4 -> 8
    I haven't done any tests yet, so let's wait and see if it helps - or breaks :-))

    Update: Even with MacOS 10.6.7 (1504.9.37), /etc/rc.local is still being parsed during bootup, so we can put these commands in there! :-)

    Cloning VirtualBox machines

    Much has been written about cloning VirtualBox guests, currently this should all be a matter of:
      VBoxManage export rhel-0 --output /Volumes/HFS/vm/rhel1/rhel1.ovf
      VBoxManage import /Volumes/HFS/vm/rhel1/rhel1.ovf 
      VBoxManage modifyvm rhel-0_1 --name rhel-1
    If you forgot to set
       VBoxManage setproperty hdfolder /Volumes/HFS/vm/rhel1/
    before importing the VM (hah!), the new (and converted?) rhel-0.vmdk ends up in the "default hdfolder", which is set to "/Volumes/HFS/vm/" in my case and the disks of new imported/cloned VMs would pollute the directory layout :-( Anyway, here's how to relocate the disk, hammer-style:
      # First we're going to detach and close the disk
      VBoxManage storageattach rhel-1 --storagectl "SATA Controller" --port 0 \
                                                        --device 0 --medium none
      VBoxManage closemedium disk 98ba164c-98e4-4892-a3c4-c73c12adc594
      # Move the disk to the right place
      mv ../../rhel-0.vmdk rhel1/rhel-1.vmdk 
      # re-attach the disk
      VBoxManage storageattach rhel-1 --storagectl "SATA Controller" --port 0 \
                --device 0 --type hdd --medium /Volumes/HFS/vm/rhel1/rhel-1.vmdk 
    Now we should be able to start the VM with
       VBoxHeadless -s rhel-1 &
    ...just as any other VM. Yay!

    Terminal Server Patch

    There's a nice patch for WindowsXP Pro SP3 to enable concurrent RDP sessions. For your (and my) convenience, here are the files again:

    $ ls -lgo termsrv.* 
    -rwxr--r-- 1 295424 2010-08-26 15:47 termsrv.dll
    -rwxr--r-- 1 295424 2008-04-13 17:12 termsrv.bk1
    $ md5sum termsrv.*
    56f4867bae6fd78e5365a3a7afa59c82  termsrv.dll
    ff3477c03be7201c294c35f684b3479f  termsrv.bk1
    After patching termsrv.dll (and backing up the original, and escaping Windows File Protection), we still have to add a new registry key:
      HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\Licensing Core\
      EnableConcurrentSessions=1 (DWORD)
    Reboot, and we should be done.

    How to remove the popup ads in Avira Antivir

    When working with certain systems one might have to install some antivirs software. The Personal Edition of Avira Antivir does its job pretty well, I think: at least I feel safer by having some magic virus catcher installed :-) However, every time Antivir gets its (daily) updates, a nag screen pops up. Here's how to disable this popup ad:

    1. Start, Run, secpol.msc
    2. Right click "Software Restriction Policies," choose "New Software Restriction Policies"
    3. Right Click "Additional Rule" folder, click "New Path Rule"
    4. Where it says Path, Type the path of avnotify.exe on your computer
    5. Make sure the "Security Level" Dropdown menu is selected as "Disallowed"
    This should be it. Thanks, Wikihow editors :-)

    Update: there's a new nag screen, listing current offers and urges one to buy their premium version. I'm fine with the free version but I'd like to get rid of the advertisments too. Adding some more path rules to the Software Restriction Policies and disallow their execution above should do the trick:

    • ApnIc.dll
    • ApnStub.exe
    • ApnToolbarInstaller.exe
    • avnotify.dll
    • avnotify.exe
    • ipmgui.exe - ?

    Encrypted /home with Ubuntu 10.04

    This has troubled me for quite some time now:

    # adduser --encrypt-home foo
    foo$ cat README.txt 
    From the graphical desktop, click on:
     "Access Your Private Data"
    From the command line, run:
    foo$ ecryptfs-mount-private 
    ERROR: Encrypted private directory is not setup properly

    When adding the user via the GUI it did not work either :-\ Turns out, I had to reinstall, again:

    # apt-get purge ecryptfs-utils libecryptfs0 keyutils \
              libpam-encfs encfs librlog5 libboost-*
    # apt-get install libpam-encfs ecryptfs-utils
    # adduser --debug --encrypt-home foo
    Adding user `foo' ...
    Selecting UID from range 1000 to 29999 ...
    Selecting GID from range 1000 to 29999 ...
    Adding new group `foo' (1001) ...
    /usr/sbin/groupadd -g 1001 foo
    Adding new user `foo' (1001) with group `foo' ...
    /usr/sbin/useradd -d /home/foo -g foo -s /bin/bash -u 1001 foo
    Creating home directory `/home/foo' ...
    Setting up encryption ...
    /usr/bin/ecryptfs-setup-private -b -u foo
      ecryptfs-unwrap-passphrase ~/.ecryptfs/wrapped-passphrase
    foo$ mount | tail -1
    /home/foo/.Private on /home/foo type ecryptfs (ecryptfs_sig=521cef411f2c84b1, \
    foo$ df -h .
    Filesystem            Size  Used Avail Use% Mounted on
    /home/foo/.Private    9.4G  2.9G  6.1G  32% /home/foo

    rsyslog: imklog: Cannot open proc file system

    For some time now rsyslog was not logging kern.* messages any more on this Ubuntu system:

    Jul  6 18:07:08 len kernel: imklog: Cannot open proc file system, 2.
    Jul  6 18:07:08 len rsyslogd: [origin software="rsyslogd" ...] (re)start
    It has been upgraded from 9.10, and LP#401433 seems to suggest that some upgrade broke imklog. The fix suggested there would involve the following commands, but since my /var/run is a tmpfs, I'd have to have this executed after every reboot (and before rsyslog starts):
      mkdir -m0700 -p /var/run/rsyslog
      chown syslog:syslog /var/run/rsyslog
      mkfifo -m 600 /var/run/rsyslog/kmsg
      chown syslog:syslog /var/run/rsyslog/kmsg
      start-stop-daemon --start --pidfile /var/run/rsyslog/ \
                        --exec /bin/dd -b -m -- if=/proc/kmsg of=/var/run/rsyslog/kmsg
    The "real" fix here was to apply a bit of Windows-fu *) to this setup and reinstall rsyslog :-\

    *) The three Rs of Microsoft support: Retry, Reboot, Reinstall