The Node

Posts Tagged ‘fix’

Recently I had the following error when attempting to access Ubuntu One’s cloud service control panel through Ubuntu 11.10, knackering Ubuntu’s file-sync.


org.freedesktop.DBus.Error.UnknownMethod: Method "current_status" with signature "" on interface "com.ubuntuone.SyncDaemon.Status" doesn't exist


While the Android and Windows clients for Ubuntu One still worked, ironically, Ubuntu One failed to sync it’s files through Ubuntu itself. Since I’d installed many updates since I’d last accessed Ubuntu One, this error had me foxed. After much Googling and experimentation, I came across the following fix, although after implementing it, you’ll have to re-sync all your U1 files. Anyway, here it is: -


rm -rf ~/.config/ubuntuone
rm -rf ~/.local/share/ubuntuone
sudo reboot


If you have your Ubuntu One login credentials stored in your GNOME keyring, you’ll also have to delete them before you reboot your machine. You can access your GNOME keyring by using the Seahorse GUI utility. You probably already have it installed but if not, you can install it with:-

sudo apt-get install seahorse

If you prefer the command line to a GUI you’re currently out of luck. However, this guy has written a Python script that accesses network passwords for the GNOME keyring from the command line. I think I might well try and expand on his work and see if I can add more functionality to allow full access to the keyring – could be useful.

Anyway, I digress…while the above solution fixes the problem, I’m still not entirely sure what the cause is. Anyhow, I hope this helps others.

I upgraded my Ubuntu 11.04 netbook today to 11.10. I admit, it wasn’t a flawless upgrade due to (wat I assume) was server overload over at Canonical. I ended up with a partial install much to my annoyance – which took about half an hour to research and fix.
It was much faster and generally smoother once I got past that. I assume part of this was the use of Unity2D on my netbook. However, the upgrade necessitates a reboot eventually, and that’s where the whole OS just froze on boot with the message “Waiting for Network Configuration”. Hitting escape showed me this: -

Unable to connect to the system bus: Failed to connect to socket /var/run/dbus/system_bus_socket: Connection refused (oneiric)

…although I think this has something to do with DBus – which is a daemon which handles inter-process communication and initiation. Since Ubuntu has been moving from the tradtional UNIX sysVinit (the mechanism which handles how the initial and child processes of the Linux kernel start) to Upstart, these things sound related.
Anyway, what all this means is that somewhere along the line, things are looking in the wrong place (I think). Instead of process stuff like process id files being stored in “/var/run” (WTF? – Why?), it’s stored in “/run”. This makes sense for the network interfaces defined under “/etc/network/interfaces/run” which is actually a symlink to “/run/network”, hence the error.
When you get the “Waiting for 60 seconds more for network configuration” Ubuntu message in the GUI, you should at some point be able to open a terminal window with CTRL-ALT-F1 and log in as normal via the bash shell. Finally, a damned command prompt :-/

Delete the DBus directory first under “/var/run/dbus” which hold the process id file and some other stuff. This frees the lockup on reboot. Then move everything under “/var/run” to “/run” with: -


mv /var/run/* /run
rmdir /var/run


Verify the contents of “/var/run” is now in “/run”. Now create a symlink from “/run” to “/var/run” with: -

ln -s /run /var/run

To be safe, I also symlinked “/var/lock” to “/run/lock” with: -

ln -s /run/lock /var/lock

Once, I rebooted after this, I actually got to the GNOME login screen, which does look lovely under 11.10….ironically wasted beauty on my right now since I’m sure you’d be glad to see any GUI login prompt at this point in the upgrade circus. The next problem was that although I had already updated the system with: -


sudo apt-get update
sudo apt-get upgrade


…Ubuntu kept telling me to reboot because of a new kernel update via the little red icon to the upper right next to the new Me Menu (which I’ve not looked at yet). I eventually got rid of this by cleaning out the repositories with: -

sudo apt-get clean all

and rebooting yet again. The last problem was with power management, which tends to lock up my netbook in 11.10. However, once I turned this off (I don’t use it anyway), all was well. The boot freeze, which is obviously the main problem should never have got past Canonical’s Quality Assurance and testing procedures. Something somewhere along the boot process is still looking for something under sysVinit rather than Upstart on some systems, as apparently this has been a bug in LaunchPad before. That was from July, way before a major release that can freeze systems was sent on it’s way into the world. Yowza.
Anyway, I’m assuming this will be fixed at some point and really, when Ubuntu 11.10 does run, it runs much better than 11.04. It’s a nicer user experience than Fedora 15 on desktop (although that may change in time).

It’s just sad, because at a certain point in time, Ubuntu was pretty stable (although I think the differences from Red Hat are insane ;-)) and although Unity runs faster and (from an hour or two’s usage seems improved in most visible ways) it’s getting more and more unstable. Although, to be fair, I did have a rather rocky road from 11.04 to 11.10 because of the partial installation of the 11.10 repos. I’ll update my experiences with 11.10 again soon if anything interesting happens, but this should help anyone else with the same problem.

Using one of the latest Linux kernels on a mobile device, such as a laptop or netbook, you might have seen a pretty hefty power regression, sometimes as much as 30% less battery life. This is especially noticeable under Ubuntu, which prompted the following post from LaunchPad.

Due to a regression inherited from the upstream linux kernel, Natty 11.04 can exhibit a 10-30% increase in power consumption. This is a known issue which is actively being investigated.

The temporary fix is pretty simple, but you must make sure that all PCIe hardware in your system supports active state power management (ASPM) because we’re going to force this to switch on in a kernel boot parameter. If you don’t have hardware that supports this, it won’t work and could lock up your system. However, if your hardware can manage it (most can), this switch will mitigate the worst of the power drain.

Now, this issue hasn’t properly been fixed after kernel 2.6.38 and is apparently still apparent in kernel 3.0. The root cause of this is essentially a problem with the BIOS manufacturers, and the BIOS incorrectly reporting its active state power management capability. This isn’t a problem on Windows because when an OEM installs Windows on a laptop, it can correctly tune these settings. But for a fresh install of Linux that you performed, a database of every motherboard and BIOS combination needs to be maintained in the open to set the force PCIE ASPM flag. If set wrongly, when the BIOS doesn’t support it, it could lead to locking which is far more serious for your Linux install (so be warned).

First, edit your GRUB boot configuration.

sudo vi /etc/default/grub

Find the fline that reads

GRUB_CMDLINE_LINUX=""

and change to: -

GRUB_CMDLINE_LINUX="pcie_aspm=force"

Save the file and update GRUB with: -

sudo update-grub

Reboot the machine and you should see about 25-30% battery life increase.

What about RedHat-bases systems?

Well, yes – this will work in the same manner if you’re running, say, Fedora on a laptop. Just add the same parameter as a kernel option under /boot/grub/menu.lst as part of the kernel line of the boot stanza.