dsd’s weblog

Beagle 0.1.2 was released on Friday and has just been added to Portage.

Highlights this time around include a fair reduction in memory consumption, various fixes and optimizations, and the ability to search for matches in a certain date range.

We now require Mono 1.1.10, so the issue where the mono-beagled process would hang at random times is gone.

Users of the firefox plugin will should reinstall the plugin, as it has been improved to use vastly fewer resources (we don’t start a new process every time you visit a webpage any more!).

Unfortunately indexing of word-files has been temporarily dropped in the Gentoo package, until gsf-sharp gets added to portage. This will hopefully happen soon.

For more info, see the release notes.

For a long time, it’s been possible to boot Linux from an external drive such as USB flash, without requiring an initrd (initial ramdisk). You can do this with the “root=/dev/sda1″ kernel parameter, where sda1 is the partition on the USB flash device containing your userspace (may vary depending on your partitioning setup and if you have SCSI or SATA devices).

(Whether or not your BIOS can boot from USB or if you have to store the bootloader and kernel on a more common boot medium is another story)

As of Linux 2.6.10, the USB flash storage initialization changed, and a side effect of this made it no longer possible to boot Linux from USB flash like this. The change meant that, in situations like this, the kernel would try to mount the root filesystem (on the USB flash disk) before the usb-storage driver was fully initialized.

Users saw errors on bootup along the lines of:

VFS: Cannot open root device 'sda1' or unknown-block(8,1)
Please append a correct 'root=' boot option
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(8,1)

Reverting this change was not an option (it was justified) so we had to find an alternative way to solve this problem.

After a few discussions, we decided that at this point in time there was no safe and elegant solution to the problem, so we had to go for a more simplistic approach. I wrote a patch which was accepted into Linux 2.6.11.

My patch added a rootdelay kernel parameter, which allows the user to specify a delay (in seconds) that the kernel should wait before trying to mount the root device. Since the kernel performs tasks in parallel, the usb-storage driver will continue initializing while the block layer is waiting for the specified delay, thus correcting the sequence of events.

So, to overcome this problem, you might use a grub configuration section such as:

title=My kernel which boots userland from a USB flash disk
root (hd0,0)
kernel /bzImage-2.6.14 root=/dev/sda1 rootdelay=10

Most users will be able to get away with a shorter delay (try 5 seconds), but some flash devices will require a longer delay.

This is a relatively minor feature, the change occurred a fair while ago, and the parameter is documented in Documentation/kernel-parameters.txt, but I’m still seeing a fair few people running into this problem. Hopefully this post will make the solution easier to find, until a more transparent solution is developed.

I recently mentioned my new project, writing a Linux driver for the “Microsoft Optical Desktop with Fingerprint Reader” keyboard. The keyboard works fine already (its just HID), but the fingerprint reader sensor requires its own driver, which I’m aiming to create.

Thanks to Tony Vroon from Gentoo for donating this device to me, and to the people who sent emails/comments after the last mention of this. Through this information and some extra googling, I now know:

• The fingerprint sensor is almost certainly designed/manufactured by Digital Persona, a biometrics company recently assimilated by Microsoft.
• The fingerprint sensor is probably a Digital Persona UareU 4000
• If this is true, the fingerprint image is encrypted…
• …but a developer familiar with the UareU Windows API suggests that the encryption key is defined by the host computer at installation time.
• …and this forum post suggests that the Microsoft keyboard lacks some features of the UareU 4000.
• The encryption algorithm might be XTEA (source)
• VALinux Japan have done some biometrics work, including fingerprint-based login using UareU devices. A presentation (html, pdf) suggests that they have produced/obtained a uareu kernel module which has a /dev/usb/uareu char interface. I wonder if they can help me out.
• The device is firmware-based, or at least, the driver sends a 1904 byte blob of data found inside one of the windows DLL files on every plugin.
• This guy also seems to have run into the uareu module. Can anyone help me find his email address?

I’m naming my driver dpfp and the initial work can be found here. So far I have created a script to extract the firmware from the windows driver distribution, and a skeleton driver which pulses the light around the sensor 3 times on plugin (looks very cool!). I’m a bit stuck on the next step, the sniffed data suggests the Windows driver is doing things which are impossible (sending data in the wrong direction). I’ve been experimenting trying to guess what it might be doing, but I haven’t been able to provoke the expected response yet (which is the device sending a section of the firmware back to the host computer — again strange…).

If any other Linux users are in possession of one of these keyboards or a standalone UareU reader, then please email me. I will send in an article to linuxbiometrics.com soon.

Update November 2007: I see I’m still getting a lot of hits from “digitalpersona linux” on Google (I’m still #1). I’ve recently launched a new project called fprint which supports DigitalPersona devices under Linux. Click to go to the project homepage.

The driver

I completed development of the Alauda driver in September and submitted the driver for inclusion to the Linux kernel.

The driver duplicates some code (checksum, media ID table) which is also present in other drivers, and it looks like we want to figure out a good way to share this code before including my work, which is a fair point – we don’t want to duplicate this yet again.

For now I’m publishing my driver as a standalone patch which people can use until we figure out the real integration details. These devices seem to be more common than I originally thought. Patch available here (against Linux 2.6.14).

Juice Box

In true open-source style, a group of hackers have taken my work and used it for something I didn’t design for: hacking the Juice Box – a portable media player based on ucLinux.

From what I gather, these devices boot from a small amount of NAND flash. To customise the device to a decent level, you need to replace this flash with your own.

Fortunately, xD media is basically NAND flash with a slightly different pin configuration, so they have done crazy things such as solder a pre-programmed XD card to the PCB:

However, you can’t just pre-program these XD cards on any old reader/writer. You need to use a device which gives you access to the physical block layout of the media, so that you can write to block 0 (amongst other things). Almost all XD reader/writer devices on the market handle physical block translation in hardware, and only provide a logical block interface to the host operating system, which does not satisfy the needs of these hackers.

The Alauda is probably the most common device that provides physical access, making writing a driver considerably harder, but allowing you to hack the media in ways such as this. I may even donate my spare Alauda device to their project.