5. Debian testing - Error cracking CSS key. Check regionset

I don't normally buy or watch DVDs, since the movie studios and distributors are not treating the linux community fairly. However, I was recently given a movie to watch, which turned out to not be as straight-forward as I would've liked it to be.

Long story short, in spite of following the usual routine of installing libdvdcss2 and other relevant packages, the movie would not play. Starting a movie player from the command line, I could see what error messages where associated with the failure to play, and the key was "Error cracking css key".

After having tried a few different things, I ended up installing regionset. When running regionset (sudo regionset) it did not echo a value for the current region which my dvd player was set to - apparently the device had not been locked to a region yet. Setting the region of my dvd player to the region of the dvd caused playback to work for all movie player clients.

Whether playback did not work because the
1. region was not set at all
or
2. region was not set to the same region as the DVD
remains to be found out.

Typically, you can only change the region of your playback device a limited number of times (3-5), so you will want to change it as few times as possible.

4. Getting mouse and keyboard to work on Lenovo Thinkpad SL410 under Debian Testing/Wheezy

For the past few months (it seems) Debian Testing will install just fine on system. On the first boot, however, neither (internal or external) mouse nor keyboard will be responsive and to a casual observer it will appear that the system has hanged. This is fairly well documented and the solution is simple if you have an EXTERNAL keyboard and mouse available (but I'll show it here anyway):
1. Disconnect and reconnect your mouse and keyboard, or, on a laptop, connect a usb keyboard, so that you can log in.
2. Open the terminal  or a console (e.g. ctrl+alt+f1) and proceed to rename /run e.g. sudo mv /run /xrun

You could also delete the folder instead of renaming it. At this point you simply have to reboot and everything should be working without any reconnecting.

NOTE that everything will be responsive during the inital part of the boot - the mouse and keyboard do not stop working until startx/gdm3 starts.

If you do not have an external keyboard you would be advised to install openssh-server during the installation of Debian. This way you should be able to ssh to your laptop from another computer and fix it remotely.

I've set up four systems - three desktops and one laptop - using this approach, and all has been well. The past week a laptop that was set up this way suddenly booted into gdm3 with an unresponsive mouse and keyboard. Plugging in an external keyboard (which I do anyway to slow down the onset of carpal tunnel from using a keyboard at weird angles - I'm not much of a fan of touchpads either) made my laptop usable, but the problem has been annoying - a system which you use for work should be in, well, working order.

At any rate, the /run folder was back. I tried just removing /run/udev, and it didn't help. I couldn't easily remove /run, since it was locked, but by attaching the hdd to another system I could remove it. On boot I got a number of error messages saying that various folders under /var/run/ could not be accessed, and I never made it to either gdm3 or a console. Booting by selecting the 'rescue/recover' option in grub dropped me into a terminal, but I could little beyond creating a /run folder (sudo mkdir /run).

ls /var/run -lah showed that /var/run was linked to /run. /var/lock had also shown up in various error messages. I renamed the /var/run and the /var/lock files (xrun and xlock), made sure that there was no /run folder, and rebooted. Still not happy and no console - complains about various things missing. Booting using the recover option (or is it rescue? Whatever, you'll know when you see it) created the necessary files, but did not create a /run folder. Rebooting and selecting the normal startup option in grub now went off without a hitch, with gdm3 behaving and the touchpad working. It took a few nervous seconds after the start of gdm before the mouse became responsive, but work it did.

So, if you're having the same problem, and you haven't had much luck deleting /run, have a look at /var and see if there are any links.

Now, the big question is: why was /run recreated in the first place?

---

Links to this post:
http://forums.debian.net/viewtopic.php?f=6&t=86208

3. Compiling nwchem on Ubuntu 10.10 64 bit

** See post on 15/12/2011 for information about Debian 64 bit. It builds fine on Squeeze but not Wheezy. This seems to have to do with the version of mpich2.**

Figuring out how to compile nwchem with mpich support took a little while, but this seems to have worked:

First mpich2 and gfortran need to be installed (since it was not installed on a virgin system there may have been other required packages already installed)
sudo apt-get install mpich2 gfortran

I created a file called myconfig.sh in the nwchem directory, with the following content:

setenv LARGE_FILES TRUE
setenv TCGRSH /usr/local/bin/ssh
setenv NWCHEM_TOP /work/nwchem
setenv NWCHEM_TARGET LINUX64
setenv NWCHEM_MODULES all
setenv USE_MPI y
setenv USE_MPIF y
setenv MPI_LOC /usr
setenv MPI_LIB $MPI_LOC/lib
setenv MPI_INCLUDE $MPI_LOC/include/mpich2
setenv LIBMPI "-lfmpich -lmpich"
cd $NWCHEM_TOP/src
make nwchem_config
make FC=gfortran >& make.log

do a csh myconfig.sh and you should be good to go.

I then added the following to the end of my ~/.bashrc and sourced it:

PATH=$PATH://work/nwchem/bin/LINUX64
export NWCHEM_EXECUTABLE=/work/nwchem/bin/LINUX64/nwchem

Jobs can then be submitted (assuming that mpd is up) by
mpdrun -n 2 nwchem nameofjob.nw