After wrestling with incompatibilities of 64-bit Linux for a while, I finally downgraded my home PC to 32-bit Ubuntu 7.10 (Gutsy). I found some nice and less nice workarounds, like running the Windows version of Firefox under Wine in order to get Flash to work. I hadn’t found a workaround for the Java browser plugin, or for Skype, and was considering a 32-bit chroot environment.
Finally one of those automatic updates decided it for me. You know the ones, the messages offering later versions of software, critical security updates and recommended updates. Being able to just click OK to automatically be upgraded to the latest software is part of what makes Ubuntu so friendly. But this time it wasn’t so friendly. Something left my PC unable to boot to multi-user, unable to start networking, and unable to start graphics. I don’t know what because I didn’t keep the disk image around for a post-mortem. It was much much faster simply to blow away my root partition with a complete new OS installation. So while I was at it, I dropped down to 32-bit.
Lots of things started working, but some got worse. I had always had a problem on Gutsy that after suspend/resume the Ethernet driver would get a reversed MAC address, complain that it was invalid, and switch to a new eth instance with a random MAC. Of course this played havoc with my router trying to keep track of where my PC was in order to provide DNS. This problem occurs in the forcedeth driver, reverse engineered for the nForce chipset. Some people worked around the problem with limited success by adding commands in the suspend/resume scripts to stop and restart networking.
But now on 32-bit Gutsy it got worse. Upon resuming the screen stayed black, and since the network seemed to be down I couldn’t remotely login to find out what was wrong. I found lots of reports on the web about suspend/resume problems with the same error message in my .xsession-errors
Gtk-WARNING **: This process is currently running setuid or setgid.
This seems related to my NVIDIA GeForce 6150 LE graphics. Like many others who posted their experiences, the problem occurred for me both with the generic open source driver and with the Nvidia proprietary accelerated driver. One person mentioned a workaround by logging out, logging in to a failsafe X-terminal, and suspending manually from there.
Irony: The main reason I’m running Ubuntu instead of Solaris is that Solaris doesn’t yet have power management, and for a home PC, suspend and resume are essential. I’ve been eagerly watching the power mangement project Tesla at opensolaris.org, wondering why it’s taking so long. I guess like most things it’s easier to do, than it is to do right. By comparison, my PC’s when running Windows 98SE often fail to wake up at all, and those running Windows XP tend to wake up by themselves, unbidden. The only systems where suspend/resume always worked were Linspire and, of course, MacOS.
Neither workaround by itself would work for me, but putting them both together I end up with a clumsy workaround that lets me suspend/resume, and may possibly point the way towards a less cumbersome workaround.
- Disable networking via gnome panel
- Logout
- Select failsafe X-terminal session
- Login
- sudo /etc/acpi/sleep.sh
- (system sleeps)
- (normal wakeup by pressing ENTER)
- Logout
- Select normal gnome session
- Login
- Enable networking via gnome panel