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 |
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.
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
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
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.
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.
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.
