Posts Tagged ‘Ubuntu Netbook Remix’

Ubuntu (UNR) no hard-drive munching anymore

Wednesday, September 23rd, 2009

I recently wrote a blogpost about how my new computers hard-drive was being slowly worn down by Ubuntu. So after doing some research and a whole lot of trial and error, the quick answer was changing one little setting in /etc/laptop-mode/laptop-mode.conf:

By default this particular setting, ENABLE_LAPTOP_MODE_ON_BATTERY, is initially set to 1, and once changed to 0 the hard-drive keep going its business with very few load cycles.

This does however mean certain SERIOUS trade-offs. Ubuntu incorporates the laptop-mode in order to better protect the laptop hard-drives when it is “mobile” i.e. off AC power.

If you know that your laptop is going to be on the receiving end of bumps hard enough to damage the hard-drive, then this isn’t a good idea. On the other hand if you, like me, feel that you’d rather have the laptop hard-drive work a bit longer, and that the risk of bumping the laptop is small enough to warrant it, then this is the way to do it.

Since my last post, and the LCC reading of 1008, it is now only incrementing once in a while and mostly during boots. Right now the reading is 1124. That is entirely ok.

Netbooks, bash-scripting and rmmod

Saturday, September 12th, 2009

I recently bought a netbook (Acer Aspire One A531H) which I promptly installed Ubuntu Netbook Remix on. This has worked very well so far, and except for an early problem with wlan (which was fixed after a couple of minutes worth of searching and reading) the only real problem I have had with this little guy is something I experience with all laptops.

The Problem

The sensitive touch-pad of doom. Perhaps I am doing something wrong, I don’t know, but the touch-pads ALWAYS gives me trouble (mostly by “conveniently” moving the cursor to another part of the text while I am writing something).

I tried a workaround, using syndaemon with the flag -d, to have the touch-pad temporarily disabled while using the keyboard, moving that into a script and configure that script to run at startup. It is a nice idea, but it re-enables the touch-pad too quickly again, so while cutting the number of incidents in more than half, I still wasn’t satisfied.

On my regular laptop, which I always connect an external trackball to, I have permanently disabled the touch-pad (sudo rmmod psmouse at upstart) but permanently disabling it on the netbook wouldn’t work either, since for some tasks (like web-surfing, no I haven’t gotten around to learning the vimperator add-on just yet) are quite a lot easier with a mouse than without it.

The Solution

So what I really wanted was a convenient way of quickly enabling and disabling the touch-pad, when I needed to.

Reusing old knowledge about how to manually add shortcuts to metacity, all I had to do was to create a script which ascertained the status of the psmouse module (loaded or not) and upon that, either removed or loaded it.

To get the state of a module Foo, one can use lsmod | grep Foo, which in this case leads to lsmod | grep psmouse. This will either yield nothing (module not loaded) or a line (module loaded).

We can improve on this a bit, making sure we always get some kind of value returned, something like lsmod | grep Foo | wc -l. Since the last command in the chain now counts the number of lines that was returned from grep, we now either get 0 or 1 returned.

So there I was, thinking I am done, having entered the gconf-editor, pointed the script to command_2 (apps > metacity > keybinding_commands) and assigned a key-binding (<Control><Alt>t) to run_command_2 (apps > metacity > global_keybindings). Life was playing, all was well. Except for the fact that hitting that key combination did absolutely nothing to shut down the touch-pad.

Which was odd, since running the script worked. The individual commands to disable and enable the touch-pad (sudo rmmod psmouse and sudo modprobe psmouse, respectively) worked flawlessly… so why didn’t this work?

Then it hit me. Running either of those commands from the command-line, would result in it prompting me for my password, something a poor script without any ability to accept input from stdin can’t do. It couldn’t even tell me about it since there was no stdout for it to use either.

gksudo to the rescue. Since gksudo pushes up a graphical password prompt, the script could once more ask me for a password, and I could again supply it. And now it works nicely :D

In closing, the script:


if [ $(lsmod | grep psmouse | wc -l) -eq 0 ]
    gksudo modprobe psmouse
    gksudo rmmod psmouse
exit 0