Ubuntulite: Problems Running Feisty on Old Hardware

While I was moderately happy with Fluxbuntu, I decided to give Ubuntulite a shot. It sounded like a great idea – the most basic of basic systems, with minimal Openbox setup on top of it. Fluxbuntu still seemed to exhibit some strange bloat here and there, and a very stripped down system seemed exactly what my old junky Presario 1240 needed.

So I followed the Ubuntulite instructions to the iota and got the system on my machine. It’s very spartan, and rough around the edges, but hey – that’s what I wanted, wasn’t it?

But I run into a heap of issues with this installation. And I’m not really blaming Ubuntulite team for this. I think this is sum of unfortunate software choices, and inherit Feisty issues. My biggest issue was the strange shit that was happening on boot time. Every time I would power up this machine, I would get the following lovely message:

[ 0.000000] ACPI: Unable to locate RSDP
Loading, please wait...
kinit: name_to_dev_t(dev/disk/by/uuid/the-long-uuid-goes-here) = hda5(3,5)
kinit: trying to resume from /dev/disk/by/the-long-uuid-goes-here
kinit: No resume image, doing normal boot...

The machine would actually hang and wait about a minute on the Loading prompt before displaying the kinit messages and resuming boot sequence. Apparently, this issue has not one but at least two bug reports on launchpad already #103148 and #105316 and neither one has been resolved. There is also this thread in the Ubuntu forums about it. I followed all the proposed fixes and nothing worked. This was not a show stopper, but an annoyance.

I finally resolved it by following the instructions here, but instead of using the UUID’s I actually modified my fstab to use standard notation like /dev/hda5. If you are to lazy to follow the link and try to figure it out on your own, here is what you do. In your /etc/fstab you will see the following line for swap:

#/dev/hda5
UUID=the-swap-partition-uuid-number-here	swap	sw	0	0

Delete the UUID bullshit and change it to:

/dev/hda5	swap	sw	0	0

Now open your /etc/initramfs-tools/conf.d/resume. It will have a long UUID listed there. Get rid of it, and replace it by simple:

RESUME=/dev/hda5

Once that is done, do:

sudo update-initramfs -u

Note that this will take around 17 million hours when you are on slow hardware, so just be patient. Once it is done, sudo reboot now. Problem solved – at least for me. Your millage may vary.

To get rid of the ACPI error I just modified my GRUB entry to add acpi=off noacpi at the end of the kernel string. Go to your /boot/grub/menu.list and find the part where it lists all the bootable entries. Find the line that specifies the kernel – it will look something like this:

kernel	/boot/vmlinuz-version.number root=/dev/hda2 ro quiet splash elevator=cfq

Slap the aforementioned string at the end like so:

kernel	/boot/vmlinuz-version.number root=/dev/hda2 ro quiet splash elevator=cfq acpi=off noacpi

This is an old POS laptop, and none of the distros I tried could figure out the ACPI stuff for it. I kinda gave up on that stuff. I mean, there is no point in loading it if it won’t work on this machine anyway, no?

The rest of the boot was working ok, but I noticed bunch of things there that I can probably shave off to save time – like fetchmail, CUPS and etc.

Openbox configured itself pretty well, but with two odd quirks. First one would only show up when you switched to a TTY using the Alt+Function Key shortcut and then go back to X. The display would become inexplicably dim and dark. Almost as if someone turned down the brightness on your monitor down to the lowest setting – but only when displaying X. All the other terminal screens looked fine. Killing X and restarting it solves the problem. I’m suspecting this is some oddball vesa quirk. Fluxbuntu did not seem to have this issue. :(

Any idea why this happens and how to fix it? Once again, this is not a show stopper – just annoying as hell.

The most bizzare quirk however was the odd Openbox numlock behavior. The Presario 1240 is a laptop, and as many mobile machines it as one of those Fn keys and no numeric keypad. In a half assed attempt to provide customers with one, Compaq decided to use combos like Fn+J through L to mean 1-3 thereby re-using the whole right side of the keyboard as the numpad.

When logged into Openbox, it forces NumLock to the on state and so my keyboard would actually use these alternate values for all the “fake-numpad” keys. So pressing K would actually type 2, pressing P would trigger a minus sign and etc. I could still get the “normal” letters by holding down the Fn key as I press them but that was just plain stupid. External keyboard would work normally, and pressing NumLock on it would “fix” this issue on the built in keyboard as well.

Quickly swiching to a TTY and back would do the same. But then I’d have to deal with that dark-vision effect so that was not a good solution either. Why wouldn’t I just hit NumLock on the laptop keyboard? Oh, probably because I fucking couldn’t. You see – NumLock on that keyboard is one of these special keys that can only be accessed while holding Fn key. And for some reason, it would just not work. Whooptie do!

Fortunately, it seems that I’m not the only person experiencing this issue, and there is a quick software fix for this behavior called numlockx:

numlockx off

The downside of this is that you have to run this command every time you boot into X. I’ll have to figure how to plug this command into the openbox boot sequence, along with commands to start the fbpanel and xsetroot into something not ugly. Care to point me in the right direction? I still haven’t gotten around to customizing my environment this way.

Its strange, but none of the other distros I used really touched NumLock. Go figure.

Btw, I’m not saying Ubuntulite is bad I actually I kinda like it. Being rough around the edges is kinda their aim, so I can’t complain about that. And the fact it doesn’t pus any given setup GUI setup on you let’s me experiment with different lightweight components and create an environment I’m happy with. Most of my problems seem to be Feisty related – rather than Ubuntulite specific. Dapper was rock solid on this machine. Feisty is a tad flaky as you can see from the issues above. I will play around some more with this system. I think I solved most of the jarring issues, and the rest will probably just fall into places soon. If it continues being flaky, and pisses me off I will probably scrap this installation and try Vector or Wolvix at some point. We’ll see.

[tags]ubuntu, ubuntulite, compaq, presario 1240, ubuntulite on presario 1240, compaq presario, lptop[/tags]