Installing Debian Wheezy amd64

To take advantage of the 8GB of memory now in amber, I decided to install the amd64 version of Debian Wheezy aka Testing. Wheezy was announced as being released in May, i.e. going stable, so it seemed a bit pointless installing the current stable release, squeeze.

I downloaded one of the weekly snapshots, available on debian.org. Installation was straightforward, and I configured the following partitions on the SSD drive (shared with Windows 7):

Mount Point Device Label Size
/ /dev/sdb5 ssd-root 1GB
/tmp /dev/sdb6 ssd-tmp 1GB
/var /dev/sdb7 ssd-var 2GB
/usr /dev/sdb7 ssd-usr 8GB
/home /dev/sdb3 ssd-home 30GB
swap /dev/sdb2 ssd-swap 8GB

Issues

Using xrandr for dual-screen management

I could not get the xrandr command in ~/.xinitrc to work. XFCE always duplicated the screens. Entering exactly the same xrandr command in an urxvt shell worked fine once XFCE was up, changing the display to one desktop extended over two screens.

One of the things I tried to fix the problem involved turning off everything in the Session and Startup -> Application Autostart menu, that is, Power Manager, PolicyKit Authentication and XFCE Volume Daemon. And lo, the xrandr command in ~/.xinitrc was effective. So, which of the things I turned off was it? Well, I don't know, because I turned them all back on the the problem did not recur.

Later: I may have stumbled upon the real fix for this issue. See this journal entry, specific to XFCE4.

Shutdown from XFCE

The ability to shutdown from XFCE was gone, only logout was possible - shutdown and restart were grayed out.

First advice I found on the web was to add:

  mark ALL = NOPASSWD: /usr/lib/x86_64-linux-gnu/xfce4/session/xfsm-shutdown-helper

to the sudoers file (added via a new file in /etc/sudoers.d/). This did not work.

Next, I found this:

  Update the file: /usr/share/polkit-1/actions/org.freedesktop.consolekit.policy

  In it, look for two lines with  
  "<allow_active>auth_admin_keep</allow_active>" and change them to  
  "<allow_active>yes</allow_active>".

Still didn't work.

However, this did. It is described here and /usr/share/doc/xfce4/README.Debian

Here's the relevant except from the README:

   === Console startup

   Users that prefer to start X from the console can use startx or startxfce4.

   The former is preferred in a Debian system as it will run all
   standard X session startup files (ConsoleKit, gpg-agent, ssh-agent etc.).
   You should not use any .xinitrc or pass any argument to startx (as it'll
   prevent running the Xsession scripts.
   Put:

   ----
   exec startxfce4
   ----

   in $HOME/.xsession to have startx run the complete Xfce desktop
   environment.

So I got rid of .xinitrc and put the following into the .xsession file:

  xrandr --output VGA-0 --auto --left-of DVI-0
  exec startxfce4

No power down on shutdown

Having just got access to shutdown via the XFCE, I then found the system didn't actually power off on shutdown. At first I though this was related to performing the shutdown from the GUI, but the same problem occured when running shutdown -h now from the console.

The apparent fix was to add the line INIT_HALT=poweroff to the /etc/default/halt file, which now looks like this:

  # Default behaviour of shutdown -h / halt. Set to "halt" or "poweroff".
  HALT=poweroff
  INIT_HALT=poweroff

Later

This solution did not, in fact, work. Intermittently, the system would just not power-down. After a while, I found one sure way of provoking the non-power-down behaviour was to start amber by Wake-On-LAN. I compared the interface setup on squeeze with that on wheezy. Hmm, on squeeze I had installed ethtool. I wonder...

  sudo apt-get install ethtool

Yep, that enabled a proper power-down after a Wake-On-LAN. It remains to be seen if the problem recurs in another scenario.

8th August, 2013 - Really Solved?

Nope, the ethtool fix was a red-herring too. amber still failed to power-down on occasion. However, the big clue was when Windows 7 also started failing to power-down. Clearly the issue was not OS-related.

I tried detaching bits of unused hardware (e.g. wireless card), shifting the memory about, but none of that made any difference. Actually, that's not true. Shifting the memory around made the pwoer-down failure happen all the time, so at least it was easier to reproduce. I looked at the BIOS settings for inspiration. Hmm, there's an option called QuickBoot which was enabled. The documentation stated it skipped certains checks on boot to make it faster. I disabled it and rebooted, then shutdown. Power-down occurred! I rebooted and re-enabled QuickBoot and tried again. Yes, still powering down properly. Working theory is that QuickBoot stopped the BIOS from managing the new memory correctly, until a full boot and check sequence was performed. However, let's give it a while before concluding we've solved the problem.

gnome-keyring-daemon

I was asked for a password for the "Default" keyring at some point in starting and restarting XFCE. I just typed in my normal weak password and thought no more about it. Except, every time I started XFCE after that I was asked for the bloody keyring password. This seems to be annoying a lot of people.

The simplest fix was to kill all instances of the daemon and remove the stored keyrings and passwords, like so:

  $ killall gnome-keyring-daemon
  $ rm -rf ~/.gnome2/keyrings

When next prompted to define a password for the Default keyring just hit Continue to enter a blank password, which effectively turns off the keyring. Ignore the dire warnings.