Shallow Thoughts : : install

SimpleCV on Raspberry Pi

I'm at PyCon, and I spent a lot of the afternoon in the Raspberry Pi lab.

Raspberry Pis are big at PyCon this year -- because everybody at the conference got a free RPi! To encourage everyone to play, they have a lab set up, well equipped with monitors, keyboards, power and ethernet cables, plus a collection of breadboards, wires, LEDs, switches and sensors.

I'm primarily interested in the RPi as a robotics controller, one powerful enough to run a camera and do some minimal image processing (which an Arduino can't do). And on Thursday, I attended a PyCon tutorial on the Python image processing library SimpleCV. It's a wrapper for OpenCV that makes it easy to access parts of images, do basic transforms like greyscale, monochrome, blur, flip and rotate, do edge and line detection, and even detect faces and other objects. Sounded like just the ticket, if I could get it to work on a Raspberry Pi.

SimpleCV can be a bit tricky to install on Mac and Windows, apparently. But the README on the SimpleCV git repository gives an easy 2-line install for Ubuntu. It doesn't run on Debian Squeeze (though it installs), because apparently it depends on a recent version of pygame and Squeeze's is too old; but Ubuntu Pangolin handled it just fine.

The question was, would it work on Raspbian Wheezy? Seemed like a perfect project to try out in the PyCon RPi lab. Once my RPi was set up and I'd run an apt-get update, I used used netsurf (the most modern of the lightweight browsers available on the RPi) to browse to the SimpleCV installation instructions. The first line,

sudo apt-get install ipython python-opencv python-scipy python-numpy python-pygame python-setuptools python-pip

was no problem. All those packages are available in the Raspbian repositories.

But the second line,

sudo pip install https://github.com/ingenuitas/SimpleCV/zipball/master

failed miserably. Seems that pip likes to put its large downloaded files in /tmp; and on Raspbian, running off an SD card, /tmp quite reasonably is a tmpfs, running in RAM. But that means it's quite small, and programs that expect to be able to use it to store large files are doomed to failure.

I tried a couple of simple Linux patches, with no success. You can't rename /tmp to replace it with a symlink to a directory on the SD card, because /tmp is always in use. And pip makes a new temp directory name each time it's run, so you can't just symlink the pip location to a place on the SD card.

I thought about rebooting after editing the tmpfs out of /etc/fstab, but it turns out it's not set up there, and it wasn't obvious how to disable the tmpfs. Searching later from home, the size is set in /etc/default/tmpfs. As for disabling the tmpfs and using the SD card instead, it's not clear. There's a block of code in /etc/init.d/mountkernfs.sh that makes that decision; it looks like symlinking /tmp to somewhere else might do it, or else commenting out the code that sets RAMTMP="yes". But I haven't tested that.

Instead of rebooting, I downloaded the file to the SD card:

wget https://github.com/ingenuitas/SimpleCV/master

But it turned out it's not so easy to pip install from a local file. After much fussing around I came up with this, which worked:

pip install http:///home/pi/master --download-cache /home/pi/tmp

That worked, and the resulting SimpleCV install worked nicely! I typed some simple tests into the simplecv shell, playing around with their built-in test image "lenna":

img = Image('lenna')
img.show()
img.binarize().show()
img.toGray().show()
img.edges().show()
img.invert().show()

And, for something a little harder, some face feature detection: let's find her eyes and outline them in yellow.

img.listHaarFeatures()
img.findHaarFeatures('eye.xml').draw(color=Color.YELLOW)

SimpleCV is lots of fun! And the edge detection was quite fast on the RPi -- this may well be usable by a robot, once I get the motors going.

Tags: raspberry pi, python, programming, hardware, linux
[ 20:43 Mar 16, 2013    More linux/install | permalink to this entry | comments ]

How To Satisfy Debian Dependencies Without Installing The Stupid Package

(This is a guest post by David North.)

Debian developers tend to get overzealous in their dependency lists, probably to avoid constant headaches from fringe cases whose favorite programs fail because they also need some obscure library or package support (and yes, I'm talking to you, Ubuntu). But what if you don't want some goofy dependency (and the cascade of other crap it pulls in?)

As a small aside, aptitude/apt-get hold <pkg> is terrific if you just want to keep a package at a pre-horkage level, but for some obcure reason you can't "hold" a package that isn't installed. So that won't work as of 11/2012.

You can however generate an equivalent package with a higher version number and install it, which naturally blocks the offending package. Even better, the replacement package need do nothing at all other than satisfy the apt database. Even better, the whole thing is incredibly simple.

First install the "equivs" package. This will deliver two programs:

• equivs-control
• equivs-build

Officially you should start with 'equivs-control <:pkgname>' which will create a file 'pkgname' in the current directory. Inside are various fields but you only need eight and can simply delete the rest. Here's approximately what you should end up with for a fictional package "pkgname":

Section: misc
Priority: optional
Standards-Version: 3.9.2

Package: pkgname
Version: 1:42
Maintainer: Your Name <your@email.address>
Architecture: all
Description: fake pkgname to block a dumb dependency

The first three lines are just boilerplate, though you may have to increment the standards-version at some point if you reuse the file. No changes are needed now.

The pkgname does actually have to match the name of the package you want to block. The version must be higher than that of the target package. Maintainer need not be you, but it's a good idea to at least use a name you recognize as yourself. Architecture can be left as "all" unless you're doing something extra tricky. Description is not necessary but a good idea; put your notes here.

The only trick is the version. Note the 1:42 structure here. The first number is the "epoch" in debian-speak, and may or may not be used. In practice I've never seen an epoch greater than one, so I suggest using either 1 or 2 here rather than just leaving it blank. You can see the epoch number in a package when you use aptitude show <pkgname>. The version is the number immediately after the colon, and for safety's sake should be considerably larger than the version you're trying to block (to avoid future updates). I like to use "42" for obvious reasons unless the actual package version is too close. Factoid: if no "epoch" is indicated debian will assume epoch 0, which will not show up as a zero in a .deb (or in aptitude show) but rather as a blank. The version number will have no colon in this event.

Having done this, all you need do is issue the command 'equivs-build path-to-pkgname' (preferably from the same directory) and you get a fake deb to install with dpkg -i. Say goodbye to the dependency.

One more trick: once you have your file <pkgname> with the Eight Important Fields, you can pretty much skip using equivs-control. All it does is make the initial text file, and it will be easier to edit the one you already have with a new package name (and rename the file at the same time). Note, however, this handy file will not necessarily be useful on other debian-based systems or later installs, so running equivs-control after a big upgrade or moving to another distro is very good practice. If you compare the files and they have the same entries, great. If not, use the new ones.

Tags: linux, debian, ubuntu, install
[ 10:50 Nov 14, 2012    More linux/install | permalink to this entry | comments ]

Touchpad and trackball blues: Emulate the middle button, and touchpad disable

In setting up a laptop -- Debian "Squeeze" with a Gnome 2 desktop -- for an invalid who will be doing most of her computing from bed, we hit a snag. Two snags, actually: both related to the switching between the trackpad and an external trackball.

Disabling and re-enabling the trackpad

First, the trackpad gets in the way when she's typing. "Disable touchpad while typing" was already set, but it doesn't actually work -- the mouse was always moving when her palm brushed against it.

On her desktop computer, she's always used a Logitech trackball -- never really got the hang of mice, but that trackball always worked well for her. And fortunately, unlike a mouse, a trackball works just fine from bed.

Once the trackball is working, there's really no need to have the trackpad enabled. So why not just turn it off when the external trackball is there? I thought I'd once seen a preference like that ... but it was nowhere to be found in the Gnome 2 desktop.

It turns out the easiest way to disable a trackpad is this:

synclient TouchpadOff=1

Using 0 instead of 1 turns it back on. So we gave her shell aliases for both these commands. A web search will show various approaches to writing udev rules to run something like that automatically, but she felt it was easy enough to type a command when she switches modes, so we're going with that for now.

Emulate the middle button on an external mouse or trackball

We thought we were done -- until we tried to paste that alias into her shell and discovered that 2-button paste doesn't work for external mice in Squeeze.

Usually, when you have a mouse-like device that has only two buttons, you can click the left and right buttons together to emulate a middle click. She'd been using that on her old Ubuntu Lucid install, and it works on pretty much every trackpad I've used. But it didn't work with the USB trackball on Squeeze.

Gnome used to have a preference for middle button emulation, but it's gone now. There's a program you can install called gpointing-device-settings that offers a 2-button emulation setting ... but it doesn't save the settings anywhere. And since it's a GUI program you can't make it part of your login or boot process -- you'd have to go through and click to set it every time. Not happening.

2-buttom emulation is an X setting -- one of the settings that used to be specified in Xorg.conf, and now wanders around to different places on every distro. A little web searching didn't turn up a likely candidate for Squeeze, but it did turn up a way that's probably more distro independent: the xinput command.

After installing xinput, you need the X ID of the external mouse or trackball. xinput list should show you something like this (plus more stuff for keyboards and possibly other devices):

$ xinput list
  Virtual core pointer                          id=2    [master pointer  (3)]
      Virtual core XTEST pointer                id=4    [slave  pointer  (2)]
      SynPS/2 Synaptics TouchPad                id=10   [slave  pointer  (2)]
      Kensington Kensington USB/PS2 Orbit       id=13   [slave  pointer  (2)]

Once you have the id of the external device, list its properties:

$ xinput list-props 13                                       ~ 9:01PM
Device 'Kensington Kensington USB/PS2 Orbit':
        Device Enabled (132):   1
  ... long list of other properties ...
        Evdev Middle Button Emulation (303):    0
        Evdev Middle Button Timeout (304):      50
  ... more properties ...

You can see that middle button emulation is disabled (0). So turn it on:

$ xinput --set-prop 13 "Evdev Middle Button Emulation" 1

Click both buttons together, and sure enough -- a middle button paste! I added that to the alias that turns the trackpad off -- though of course, it could also be added to a udev rule that fires automatically when the mouse is plugged in.

Tags: linux, laptop
[ 14:34 Sep 08, 2012    More linux/install | permalink to this entry | comments ]

Configuring extlinux's auto-update on Debian

A few days ago, I wrote about how to set up and configure extlinux (syslinux) as a bootloader. But on Debian or Ubuntu, if you make changes to files like /boot/extlinux/extlinux.conf directly, they'll be overwritten.

The configuration files are regenerated by a program called extlinux-update, which runs automatically every time you update your kernel. (Specifically, it runs from the postinst script of the linux-base package: you can see it in /var/lib/dpkg/info/linux-base.postinst.)

So what's a Debian user to do if she wants to customize the menus, add a splash image or boot other operating systems?

First, if you decide you really don't want Debian overwriting your configuration files, you can change disable updates by editing /etc/default/extlinux. Just be aware you won't get your boot menu updated when you install new kernels -- you'll have to remember to update them by hand.

It might be worth it: the automatic update is nearly as annoying as the grub2 updater: it creates two automatic entries for every kernel you have installed. So if you have several distros installed, each with a kernel or two in your shared /boot, you'll get an entry to boot Debian Squeeze with the Ubuntu Oneiric kernel, one for Squeeze with the Natty kernel, one for Squeeze with the Fedora 16 kernel ... as well as entries for every kernel you have that's actually owned by Debian. And then for each of these, you'll also get a second entry, to boot in recovery mode. If you have several distros installed, it makes for a very long and confusing boot menu!

It's a shame that the auto-updater doesn't restrict itself to kernels managed by the packaging system, which would be easy enough to do. (Wonder if they would accept a patch?) You might be able to fudge something that works right by setting up symlinks so that the only readable kernels actually live on the root partition, so Debian can't read the kernels from the other distros. Sounds a bit complicated and I haven't tried it. For now, I've turned off automatic updating on my system.

But if your setup is simpler -- perhaps just one Debian or one Ubuntu partition plus some non-Linux entries such as BSD or Windows -- here's how to set up Debian-style automatic updating and still keep all your non-Linux boot entries and your nice menu customizations.

Debian automatic updates and themes

First, take a quick look at /etc/default/extlinux and customize anything there you might need, like the names of the kernels, kernel boot parameters or timeout. See man extlinux-update for details.

For configuring menu colors, image backgrounds and such, you'll need to make a theme. You can see a sample theme by installing the package syslinux-themes-debian -- but watch out. If you haven't configured apt not to pull in suggested packages, that may bring back grub or grub-legacy, which you probably don't want.

You can make a theme without needing that package, though. Create a directory /usr/share/syslinux/themes/mythemename (the extlinux-update man page claims you can put a theme anywhere and specify it by its full path, but it lies). Create a directory called extlinux inside it, and make a file with everything you want from extlinux.conf. For example:

default 0
prompt 1
timeout 50

ui vesamenu.c32
menu title Welcome to my Linux machine!
menu background mysplash.png
menu color title 1;36 #ffff8888 #00000000 std
menu color unsel 0    #ffffffff #00000000 none
menu color sel   7    #ff000000 #ffffff00 none

include linux.cfg
menu separator
include themes/mythemename/other.cfg

Note that last line: you can include other files from your theme. For instance, you can create a file called other.cfg with entries for other partitions you want to boot:

label oneiric
menu label Ubuntu Oneiric Ocelot
kernel /vmlinuz-3.0.0-12-generic
append initrd=/initrd.img-3.0.0-12-generic root=UUID=c332b3e2-5c38-4c50-982a-680af82c00ab ro quiet

label fedora
menu label Fedora 16
kernel /vmlinuz-3.1.0-7.fc16.i686
append initrd=/initramfs-3.1.0-7.fc16.i686.img root=UUID=47f6b1fa-eb5d-4254-9fe0-79c8b106f0d9 ro quiet

menu separator

LABEL Windows
KERNEL chain.c32
APPEND hd0 1

Of course, you could have a debian.cfg, an ubuntu.cfg, a fedora.cfg etc. if you wanted to have multiple distros all keeping their kernels up-to-date. Or you can keep the whole thing in one file, theme.cfg. You can make a theme as complex or as simple as you like.

Tags: linux, boot, extlinux, syslinux, debian, ubuntu
[ 11:26 Nov 24, 2011    More linux/install | permalink to this entry | comments ]

How to install extlinux (syslinux) as a bootloader

When my new netbook arrived, I chose Debian Squeeze as the first Linux distro to install, because I was under the impression it still used grub1, and I wanted to avoid grub2. I was wrong -- Squeeze uses grub2. Uninstalling grub2, installing grub-legacy and running grub-install and update-grub didn't help; it turns out even in Debian's grub-legacy package, those programs come from grub2's grub-common package.

What a hassle! But maybe it was a blessing in disguise -- I'd been looking for an excuse to explore extlinux as a bootloader as a way out of the grub mess.

Extlinux is one of the many spinoffs of syslinux -- the bootloader used for live CDs and many other applications. It's not as commonly used as a bootloader for desktops and laptops, but it's perfectly capable of that. It's simple, well tested and has been around for years. And it supports the few things I want out of a bootloader: it has a simple configuration file that lives on the /boot partition; it can chain-load Windows, on machines with a Windows partition; it even offers pretty graphical menus with image backgrounds.

Since there isn't much written about how to use extlinux, I wrote up my experiences along with some tips for configuring it. It came out too long for a blog article, so instead I've made it its own page: How to install extlinux (syslinux) as a bootloader.

Tags: linux, boot, extlinux, syslinux
[ 15:19 Nov 20, 2011    More linux/install | permalink to this entry | comments ]

Making an Ubuntu live USB stick persistent

I wrote a few days ago about my multi-distro Linux live USB stick. Very handy!

But one thing that bugs me about live distros: they're set up with default settings and don't have a lot of the programs I want to use. Even getting a terminal takes quite a lot of clicks on most distros. If only they would save their settings!

It's possible to make a live USB stick "persistent", but not much is written about it. Most of what's written tells you to create the USB stick with usb-creator -- a GUI app that I've tried periodically for the past two years without ever once succeeding in creating a bootable USB stick.

Even if usb-creator did work, it wouldn't work with a multi-boot stick like this one, because it would want to overwrite the whole drive. So how does persistence really work? What is usb-creator doing, anyway?

How persistence works: Casper

The best howto I've found on Ubuntu persistence is LiveCD Persistence. But it's long and you have to wade through a lot of fdisk commands and similar arcana. So here's how to take your multi-distro stick and make at least one of the installs persistent.

Ubuntu persistence uses a package called casper which overlays the live filesystem with the contents of another filesystem. Figuring out where it looks for that filesystem is the key.

Casper looks for its persistent storage in two possible places: a partition with the label "casper-rw", and a file named "casper-rw" at the root of its mounted partitions.

So you could make a separate partition labeled "casper-rw", using your favorite partitioning tool, such as gparted or fdisk. But if you already have your multi-distro stick set up as one big partition, it's just as easy to create a file. You'll have to decide how big to make the file, based on the size of your USB stick.

I'm using a 4G stick, and I chose 512M for my persistent partition:

$ dd if=/dev/zero of=/path/to/casper-rw bs=1M count=512

Be patient: this step takes a while.

Next, create a filesystem inside that file. I'm not sure what the tradeoffs are among various filesystem types -- no filesystem is optimized for being run as a loopback file read from a vfat USB stick that was also the boot device. So I flipped a coin and used ext3:

$ mkfs.ext3 /path/to/casper-rw
/path/to/casper-rw is not a block special device.
Proceed anyway? (y,n) y

One more step: you need to add the persistent flag to your boot options. If you're following the multi-distro USB stick tutorial I linked to earlier, that means you should edit boot/grub/grub.cfg on the USB stick, find the boot stanza you're using for Ubuntu, and make the line starting with linux look something like this:

    linux (loop)/casper/vmlinuz boot=casper iso-scan/filename=$isofile quiet splash noprompt persistent --

Now write the stick, unmount it, and try booting your live install.

Testing: did it work?

The LiveCD/Persistence page says persistent settings aren't necessarily saved for the default "ubuntu" user, so it's a good idea to make a new user. I did so.

Oops -- about that Ubuntu new user thing

But at least in Ubuntu Oneiric: there's a problem with that. If you create a user, even as class Administrator (and of course you do want to be an Administrator), it doesn't ask you for a password. If you now log out or reboot, your new user should be saved -- but you won't be able to do anything with the system, because anything that requires sudo will prompt you for your nonexistent password. Even attempting to set a password will prompt you for the nonexistent password.

Apparently you can "unlock" the user at the time you create it, and then maybe it'll let you set a password. I didn't know this beforehand, so here's how to set a password on a locked user from a terminal:

$ sudo passwd username

For some reason, sudo will let you do this without prompting for a password, even though you can't do anything administrative through the GUI.

Testing redux

Once you're logged in as your new user, try making some changes. Add and remove some items from the unity taskbar. Install a couple of packages. Change the background.

Now try rebooting. If your casper-rw file worked, it should remember your changes.

When you're not booted from your live USB stick, you can poke around in the filesystem it uses by mounting it in "loopback" mode. Plug the stick into a running Linux machine, mount it the usb stick, then mount it with

$ sudo mount -o loop /path/to/casper-rw /mnt

/path/to is wherever you mounted your usb stick -- e.g. /media/whatever. With the file mounted in loopback mode, you should be able to adjust settings or add new files without needing to boot the live install -- and they should show up the next time you use the live install.

My live Ubuntu Oneiric install is so much more fun to use now!

Tags: ubuntu, linux, install
[ 14:41 Oct 28, 2011    More linux/install | permalink to this entry | comments ]

Creating a multi-distro Linux Live USB stick

Linux live USB sticks (flash drivers) are awesome. You can carry them anywhere and give a demo of Linux on anyone's computer, any time. But how do you keep track of them? Especially since USB sticks don't have any place to write a label. How do you remember that the shiny blue stick is the one with Ubuntu Oneiric, the black one has Ubuntu Lucid, the other blue one that's missing its top is Debian ... and so forth. It's impossible! Plus, such a waste -- you can hardly buy a flash drive smaller than 4G these days, and then you go and devote it to a 700Mb ISO designed to fit on a CD. Silly.

The answer: get one big USB stick and put lots of distros on it, using grub to let you choose at boot time.

To create my stick, I followed the easy instructions at HOWTO: Booting LiveCD ISOs from USB flash drive with Grub2. I found that tutorial quite simple, so I'm not going to duplicate the instructions there. I used the non-LUA version, since my grub on Ubuntu Natty didn't seem to support LUA. Basically you run grub-install to the stick, create a directory called iso where you stick all your ISO files, then create a grub.cfg with magic incantations to boot each ISO.

Ah, wait ... magic incantations? The tutorial is missing one important part: what if you want to use an ISO that isn't already mentioned in the tutorial? If Ubuntu's entry is
linux (loop)/casper/vmlinuz boot=casper iso-scan/filename=$isofile quiet splash noprompt -- and Parted Magic's is
linux (loop)/pmagic/bzImage iso_filename=$isofile edd=off noapic load_ramdisk=1 prompt_ramdisk=0 rwnomce sleep=10 loglevel=0 then you know there's some magic going on there.

I knew I needed at least the Ubuntu "alternate installer", since it allows installing a command-line system without the Unity desktop, and Debian Squeeze, since that's currently the most power-efficient Linux for laptops, in addition to the distros mentioned in the tutorial. How do you figure out what to put in those grub.cfg lines? Here's how to figure it out from the ISO file. I'll use the Debian Squeeze ISO as an example.

Step 1: mount the ISO file.

$ sudo mount -o loop /pix/boot/isos/debian-6.0.0-i386-netinst.iso /mnt

Step 2: find the kernel

$ ls /mnt/*/vmlinuz /mnt/*/bzImage
/mnt/install.386/vmlinuz

Step 3: find the initrd. It might have various names, and might or might not be compressed, but the name will almost always start with init.

$ ls /mnt/*/vmlinuz /mnt/*/init*
/mnt/install.386/initrd.gz

Unmount the ISO file.

$ umount /mnt

The trick in steps 2 and 3 is that nearly all live ISO images put the kernel and initrd a single directory below the root. If you're using an ISO that doesn't, you may have to search more deeply (try /mnt/*/*).

In the case of Debian Squeeze, now I have the two filenames: /install.386/vmlinuz and /install.386/initrd.gz. (I've removed the /mnt part since that won't be there when I'm booting from the USB stick.) Now I can edit boot/grub/grub.cfg and make a boot stanza for Debian:

menuentry "Debian Squeeze" {
    set isofile="/boot/isos/debian-6.0.0-i386-netinst.iso"

    loopback loop $isofile 
    linux (loop)/install.386/vmlinuz iso_filename=$isofile quiet splash noprompt --
    initrd (loop)/install.386/initrd.gz
}

Here's the entry for the Ubuntu alternate installer:

menuentry "Oneiric 11.10 alternate" {
    set isofile="/boot/isos/ubuntu-11.10-alternate-i386.iso"
 
    loopback loop $isofile 
    linux (loop)/install/vmlinuz iso_filename=$isofile
    initrd (loop)/install/initrd.gz
}

It sounds a little convoluted, I know -- but you only have to do it once, and then you have this amazing keychain drive with every Linux distro on it you can think of. Amaze your friends!

Tags: linux, install, ubuntu, debian, grub
[ 21:21 Oct 25, 2011    More linux/install | permalink to this entry | comments ]

Ubuntu "Natty Narwhal" on the ExoPC

Intel hosted a MeeGo developer camp on Friday where they gave out ExoPC tablets for developers, and I was lucky enough to get one.

Intel is making a big MeeGo push -- they want lots of apps available for this platform, so they're trying to make it as easy as possible for develoeprs to make new apps for their AppUp store.

Meego looks fun -- it's a real Unix under the hood, with a more or less mainstream kernel and a shell. I'm looking forward to developing for it; in theory it can run Python programs (using Qt or possibly even gtk for the front end) as well as C++ Qt apps. Of course, I'll be writing about MeeGo developing once I know more about it; for now I'm still setting up my development environment.

But on a lazy Saturday, I thought it would be fun to see if the new Ubuntu 11.04, "Natty Narwhal", can run on the ExoPC. Natty's whizzy new "Unity" interface (actually not new, but much revamped since the previous Ubuntu release) is rumoured to be somewhat aimed at tablets with touchscreens. How would it work on the ExoPC?

Making a bootable Ubuntu USB stick

The first step was to create a bootable USB stick with Ubuntu on it. Sadly, this is not as easy as on Fedora or SuSE. Ubuntu is still very CD oriented, and to make a live USB stick you need to take an ISO intended for a CDROM then run a program that changes it to make it bootable from USB.

There are two programs for this: usb-creator and unetbootin. In the past, I've had zero luck getting these programs to work except when running under a Gnome desktop on the same version of Ubuntu I was trying to install. Maybe it would be better this time.

I tried usb-creator-gtk first, since that seems to be the one Ubuntu pushes most. It installed without too many extra dependencies -- it did pull in several PolicyKit libraries like libpolkit-backend-1-0 and libpolkit-gobject-1-0. When I ran it, it saw the USB stick right away, and I chose the ubuntu-11.04-desktop-i386.iso file I'd downloaded. But the Make Startup Disk button remained blank. I guess I needed to click the Erase Disk button first. So I did -- and was presented with an error dialog that said:

org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.PolicyKit1 was not provided by any service files

Dave (who's wrestled with this problem more than I have) suggested maybe it wanted a vfat partition on the USB stick. So I quit usb-creator-gtk, used gparted to make the stick into a single vfat partition, and restarted usb-creator-gtk. Now everything was un-greyed -- so I clicked Make Startup Disk and was immediately presented with another dialog:

Installation failed

No clue about what went wrong or why. Okay, on to unetbootin.

When I ran unetbootin, it gave me a helpful dialog that "unetbootin must be run as root." Then it proceeded to show its window anyway. I can read, so I quit and ran it again as root. I chose the iso file, clicked OK -- and it worked! In a minute or two I had a bootable Ubuntu USB stick.

(Update: unetbootin is better than usb-creator for another reason: you can use it to burn CDs other than the default live desktop CD -- like if you want to burn the "alternate installer" ISO so you can install server systems, use RAID partitions, etc.)

Booting on the ExoPC

Natty booted up just fine! I inserted the USB stick, powered on, leapt for the XXX button that shows the boot menu and told it to boot from the stick. Natty booted quite fast, and before long I was in the Unity desktop, and, oddly, it started off in a banshee screen telling me I didn't have any albums installed. I dismissed banshee ...

... at which point I found I couldn't actually do much without a keyboard. I couldn't sign on to our wi-fi since I couldn't type the password, and I didn't have any local files installed. But wait! I had an SD card with some photos on it, and Ubuntu recognized it just fine and popped up a file browser.

But I wanted to try net access. I borrowed Dave's Mac USB keyboard to type in the WPA password. It worked fine, and soon I was signed on to wi-fi and happily browsing the web.

"onboard" keyboard

What about an onscreen keyboard, though? I found one, called "onboard". It's installed by default. Unfortunately, I couldn't find a way to run it without a keyboard. Unity has a "+" button that took me to a window with a text field labeled Search Applications, but you have to type something there before it will show you any applications. I couldn't find any way to get a list of applications without a keyboard.

With a keyboard, I was able to find a terminal app, from which I was able to run onboard. It's tiny! Far too small for me to type on a capacitive display, even with my tiny fingers. It has no man page, but it does have a --help argument, by which I was able to discover the -s argument: onboard -s 900x300 did nicely. It's ugly, but I can live with that. Now if I can figure out how to make a custom Unity launcher for that, I'll be all set.

Unity on tablets -- not quite there yet

With onboard running, I gave Dave back his keyboard, and discovered a few other problems. I couldn't scroll in the file browser window: the scrollbar thumb is only a few pixels wide, too narrow to hit with a finger on a touchscreen, and the onboard keyboard has no up/down arrows or Page Up/Down. I tried dragging with two fingers, but no dice.

Also, when I went back to that Unity Search Applications screen, I discovered it takes up the whole screen, covering the onscreen keyboard, and there's no way to move it so I can type.

Update: forgot to mention that Unity, for all its huge Playskool buttons, has a lot of very small targets that are hard to hit with a finger. It took me two or three tries to choose the wi-fi icon on the top bar rather than the icon to the left or right of it, and shutdown is similarly tricky.

So Natty's usability on tablets isn't quite there. Still, I'm impressed at how easy it was to get this far. I didn't expect it to boot, run and be so usable without any extra work on my part. Very cool!

And no, I won't be installing Natty permanently on the ExoPC. I got this tablet for MeeGo development and I'm not welching on that deal. But it's fun to know that it's so easy to boot Ubuntu when I want to.

Tags: exopc, ubuntu, tablet, boot, install
[ 12:46 Apr 30, 2011    More linux/install | permalink to this entry | comments ]