Skip to 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 sol-10-u9-ga-x86-dvd-iso.zip 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: 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!