# grep experimental /etc/apt/sources.list deb http://ftp.debian.org/debian experimental main # cat /etc/apt/preferences.d/experimental Package: linux-base Pin: release a=experimental Pin-Priority: 800 # apt-get update # apt-get install linux-image-2.6.36-rc6-amd64Now, if it would only boot... :-)
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:
- V22438-01.zip (sol-10-u9-ga-sparc-dvd-iso.zip)
MD5 3A24F5746EBAB5F254C359F979E644F7 SHA-1 98953B5AECDE175831003A44FB5752B9C6E783AC
MD5 CB55F4B7AF194F6378AA5F304F3EA8FC SHA-1 5701FC18978337B163AD50F06DD0460F90E9AF8FLet's all hope they're adding those checksums to the download page again...
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 -> 8I 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.localis still being parsed during bootup, so we can put these commands in there! :-)
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-1If you forgot to set
VBoxManage setproperty hdfolder /Volumes/HFS/vm/rhel1/before importing the VM (hah!), the new (and converted?)
rhel-0.vmdkends 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.vmdkNow we should be able to start the VM with
VBoxHeadless -s rhel-1 &...just as any other VM. Yay!
$ 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.bk1After 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.
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:
- Start, Run, secpol.msc
- Right click "Software Restriction Policies," choose "New Software Restriction Policies"
- Right Click "Additional Rule" folder, click "New Path Rule"
- Where it says Path, Type the path of avnotify.exe on your computer
- Make sure the "Security Level" Dropdown menu is selected as "Disallowed"
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:
server=/example.com/10.0.0.1This will forward requests for
10.0.0.1. While we're on it, how about static DNS entries (w/o using DHCP) in DD-WRT? It's as easy as:
This has troubled me for quite some time now:
# adduser --encrypt-home foo [...] foo$ cat README.txt THIS DIRECTORY HAS BEEN UNMOUNTED TO PROTECT YOUR DATA. From the graphical desktop, click on: "Access Your Private Data" or From the command line, run: ecryptfs-mount-private 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 ************************************************************************ YOU SHOULD RECORD YOUR MOUNT PASSPHRASE AND STORE IT IN A SAFE LOCATION. ecryptfs-unwrap-passphrase ~/.ecryptfs/wrapped-passphrase THIS WILL BE REQUIRED IF YOU NEED TO RECOVER YOUR DATA AT A LATER TIME. ************************************************************************ [...] foo$ mount | tail -1 /home/foo/.Private on /home/foo type ecryptfs (ecryptfs_sig=521cef411f2c84b1, \ ecryptfs_fnek_sig=44158dfbb2100d2f,ecryptfs_cipher=aes,ecryptfs_key_bytes=16) foo$ df -h . Filesystem Size Used Avail Use% Mounted on /home/foo/.Private 9.4G 2.9G 6.1G 32% /home/foo
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)startIt 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
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/kmsgpipe.pid \ --exec /bin/dd -b -m -- if=/proc/kmsg of=/var/run/rsyslog/kmsgThe "real" fix here was to apply a bit of Windows-fu *) to this setup and reinstall
*) The three Rs of Microsoft support: Retry, Reboot, Reinstall