I wonder why I have such a better feeling about the OpenMoko than the Nokia n800.

I feel that I know the OpenMoko already just by reading Harald's blog and browsing its wiki. It's a pretty stock arm system, boots with uboot, system in jffs2 flash, interesting interface to the necessarily proprietary cell phone stuff, all the hardware will work with only lightly modified linux kernels and the kdrive X server. Major downside of no wifi, though bluetooth is available, and if there's power, a USB wifi dongle could be used.

Afrer putting in a similar amount of time googling for info about the n800, I'm still left in the dark on a number of points. I don't know what the boot loader is, what kernel or X modifications are needed, whether non-free drivers might be needed for some hardware, etc. IIRC the n700 had some issues along those lines.

Of course, the reason I care about this stuff is that I can't conceive of owning a linux PDA or cell phone and not putting Debian on it, and I don't mean running Debian in a chroot, which is as far as I've heard of people getting with either the n800 or the n700. The GUI stuff for both these is pretty nice, and would make nice Debian packages. I, however, want to use ion.

Note: See discussion for some notes based on feedback.

discussion

Here are some scenarios for ways that I want to use Debian on semi-embedded and embedded devices. So far there's not a good way to accomplish most of these, and each scenario needs at best a different approach, from flashybrid to Embdebian to ADS root builder to hand hacked images.

That will change, I hope, if the grand unified scheme I'm plotting comes to fruition. If some of these scenarios interest you, please check out the design at http://wiki.debian.org/RootSync.

openmoko

First, install Debian to a 2 gb microSD card in the phone, using d-i. Bog-standard Debian install (except for it being g-i running on a cell phone!), standard partitioning.

Boot the install and use it for a while. Install more stuff and tweak the system. Now you want to remove that microSD card, to save power. So, unmount it, and remove it. Debian continues running; all the files you normally use, including everything needed to boot the system, have already been copied over to the flash.

If the flash gets too full, just delete any files you don't need right now. If you later find you're missing a file, just plug the microSD back in, mount it, and you can access the file again. This is also an easy way to do a backups, a simple command can sync your changes up to the microSD card.

Also the microSD card can be plugged into a different openmoko phone, chrooted into, a command run, the phone rebooted, and it's been taken over, now running the same Debian install. Great party trick. ;-)

slug with a 32 mb USB stick

This is my sister's nslu2 box, that only does one thing, really: Dial up to the internet and route packets to the access point. It's also nice to get Debian security updates from time to time. And I don't want to have a noisy hard drive on it, so it runs from a small USB stick.

The initial install is done to USB drive, then I add the USB stick to the picture, boot the nslu2 up, configure ppp, run it, and I can remove the drive, it's ready to run in embedded mode from the USB stick.

Later I need to apply a security update, so I plug in the USB drive, mount it, run aptitude, and I'm done, just unmount the USB drive again, and the USB stick now has updated versions of the necessary files.

true embedded system development

A company is creating a real embedded arm system, it needs to run from 64 mb of flash, with a fair chunk for their own application, and a fair chunk free for user data. An engineer is using his development system to work on creating the jffs2 filesystem that will go on the production hardware. He starts by untarring the Debian armel port to a drive, and copies in the custom application.

Then he sets up an empty jffs2 filesystem on mtdblockN. After rebooting the system, the jffs2 contains the files needed to boot Debian on its own. The engineer runs the custom application, and the jffs2 is now ready to run that too.

But it's getting a bit tight for space on the jffs2. Time for busybox. He runs "busybox install [long list of busybox commands]", replacing lots of core commands with their smaller busybox versions. After a few reboots, all the init scripts are hacked up to work with the busybox stuff. (Argh.. Debian should work with it by default. Anyone want patches?) Maybe he goes on to run mklibs or do something with uclibc.

This might take a few iterations to get right, but he doesn't worry about screwing up the system -- he knows that at any point he can delete all the files on the jffs2, reboot, and be back to his unmodified system on the disk drive.

Once everything is ready, he can load the jffs2 onto production hardware and the new embedded system is ready to be tested and qualified.

slug thick client

My nslu2 box, used for handling some USB devices like my UPS, security camera, etc. When the network is up, and the storage server is up, it can nfs mount root, but that doesn't work when the power goes out and the server needs to come down. I want it to keep working in that case, as a kind of detached thick client. After hacking nfs root support into d-i at some future point :-) I have it booting with nfs root already.

There's around 3 mb of unused flash on the slug, so I set up a jffs2 partition using that, and through some trial and error get the right files on there to let the system keep running in a degraded mode when the nfs mount goes down. 3 mb does fill up pretty quickly if the camera notices motion, but it's good enough, so I decide not to put a USB stick on the box.

As usual, it's wacked again. I've been going to bed at horrible hours, nowhere near a nice midnight baseline (most recently at 10 am).

I've bought melatonin, and I intend to use it.. Here's hoping for sanity.

discussion

As the first step in moving my automated d-i install testing away from the dilab and over to emulation, I've added support to the d-i regression tester (digress) to use qemu for serial-console based CDROM installation tests. It was fairly straightforward to do that, since digress already supported bochs and hercules.

I don't currently have an enourmous fast machine I can run qemu on. Actually, all of my servers, including my only amd64 server, have xen on them, which isn't ideal in combination with qemu (no kqemu..). So I thought I'd put this out as a howto, in the hope that lots of people will set up their own automated tests. If you do, please mail me and let me know, and I will aggregate all the tests together into a nice status page.

Here's how to set it up:

• sudo apt-get install qemu subversion libexpect-perl expect lockfile-progs
• sudo apt-get install kqemu-modules-2.6.18-4-686 # or similar, using unstable
• sudo modprobe kqemu
• svn co svn+ssh://svn.debian.org/d-i/trunk/scripts/digress
• Now edit digress/schemes/qemu/common, and set ISO to point to the CD image you want to test. You may also want to tune QEMU_DISK_SIZE, QEMU_EXTRA_PARAMS, STAGE_1_MAX_TIME, STAGE_2_MAX_TIME, and USER_PASSWORD. digress's README has more details about all the config options.
• Also edit digress/schemes/qemu/d-i, and change "url=kodama" to control where d-i will download its preseed file from. Until qemu bug #414342 is fixed, it can't support colons or slashes in the url to the preseed file, so the example is taking advantage of the default url guessing in d-i, which will look in eg http://kodama/d-i/etch/./preseed.cfg. Put in your hostname and set up a preseed file. digress/preseed.cfg is a reasonable starting point.
• To start a test, run ./test-harness qemu d-i
• The test will proceed automatically; digress will hit Enter at any prompts. Your preseed file should take care of any other choices.
• To cron the test, run cd ~/digress; ./daily-tests qemu d-i (be sure to update the CD image too). This will drop logs into digress/logs, and if you put that directory up on the web, I can produce a nice status page.

(Wonder if I should make a package of digress?)

A few ideas for things to test:

• netinst iso
• businesscard iso
• netboot mini iso
• true netboot (qemu -boot n)
• gnome desktop install
• kde desktop install
• xfce desktop install
• web server install
• lvm
• raid
• small disk
• lowmem
• amd64
• lilo
• all kinds of fun combos of the above, like lowmem gnome+web server install on lvm

I'm flattered to appear in the comics, although it's strange how I ended up speaking Frenglish in it..

Google has accepted ikiwiki as a project for the Google summer of code. It's an honour to have my year old project listed alongside 100 mostly major free software projects. I would not have thought to sign ikiwiki up at this point, but it's really a great point to do so, with so much still to do, so thanks to Josh Triplett for making it happen.

Students who are interested in being funded to work on ikiwiki this summer can check out our list of summer of code ideas or submit your own.

While looking for a left-handed bread knife, I ran across this page which is the most complete lists of left-handed unfriendly objects I've seen.

Reading down it, I'm suprised how many of these I've adapted to. I turn a can opener with my right hand, pour saucepans using my right hand, scythe with my right hand leading, use a tape measure as a right-hander would, and hold playing cards in my right hand. OTOH, I hate using scissors, I almost never hand-write anything, and I never could get a boomerang to work.

discussion

Spring is here..

For the first time, I have working ipv6 to both my main servers as well as my home network using 6to4. That's nice, what's driving me insane is that while I seem to have radvd set up properly on my OpenWRT system here at home, none of the boxes on the network are autoconfiguring their ipv6 addresses. And linux doesn't offer any way to debug this that I know of, besides logging the rather useless "wlan0: no IPv6 routers present". radvdump shows the clients can see the advertisements, which look ok. All the kernel parameters look ok. If I manually set up an address on the clients it works. So why is linux ignoring radvd? No idea, no way to tell..

Update:

Getting ipv6 client autoconfiguration to work on linux seems like a bit of a black art. You're think you could just load ipv6, take an interface down and back up (or even just wait for radvd to broadcast) and have autoconfiguration just work. This does not seem to be the case, after beating my head against this for several hours with no success I finally rebooted my laptop and it's now doing autoconfiguration.

No such luck with my desktop and nslu2, despite reboots and poking. And something strange is going on, since twice I've seen dhclient clear autoconfigured ipv6 settings from an interface.

Update 2:

Fixed. Turns out I hit Debian bug #410375.

My evil plan described at http://wiki.debian.org/RootSync seems to be actually doable, and I have an early prototype. Here's a fun transcript. I start with a debootstrapped /tmp/sid chroot, and let it watch me run a few commands, copying accessed files into /tmp/new. This automatically creates a fairly minimal chroot that can only run those commands.

transcript:

root@kodama:/home/joey/src/packages/unreleased/rootsync>ls /tmp/new
ls: /tmp/new: No such file or directory
root@kodama:/home/joey/src/packages/unreleased/rootsync>./watcher /tmp/sid /tmp/new &
[1] 3698
** starting up ...
** scanning /tmp/sid ...
** running
root@kodama:/home/joey/src/packages/unreleased/rootsync>ls /tmp/new
bin/  dev/  etc/  lib/  sbin/  usr/  var/
root@kodama:/home/joey/src/packages/unreleased/rootsync>cd /tmp/sid
root@kodama:/tmp/sid>chroot . bin/sh
sh-3.1# ** add /tmp/new/bin/bash
** add /tmp/new/lib/ld-2.3.6.so
** add /tmp/new/etc/ld.so.cache
** add /tmp/new/lib/libncurses.so.5.5
** add /tmp/new/lib/tls/libdl-2.3.6.so
** add /tmp/new/lib/tls/libc-2.3.6.so
** add /tmp/new/dev/tty
** add /tmp/new/etc/mtab
** add /tmp/new/etc/nsswitch.conf
** add /tmp/new/lib/tls/libnss_compat-2.3.6.so
** add /tmp/new/lib/tls/libnsl-2.3.6.so
** add /tmp/new/lib/tls/libnss_nis-2.3.6.so
** add /tmp/new/lib/tls/libnss_files-2.3.6.so
** add /tmp/new/etc/passwd
** add /tmp/new/root/.bash_history
** add /tmp/new/lib/terminfo/x/xterm
** add /tmp/new/etc/inputrc

sh-3.1# w
sh-3.1# ** add /tmp/new/usr/bin/w.procps
** add /tmp/new/lib/libproc-3.2.7.so
sh-3.1# ls
** add /tmp/new/bin/ls
bin   dev  home    lib    mnt  proc  sbin  sys  usr
boot  etc  initrd  media  opt  root  srv   tmp  var
sh-3.1# ** add /tmp/new/lib/tls/librt-2.3.6.so
** add /tmp/new/lib/libacl.so.1.1.0
** add /tmp/new/lib/libselinux.so.1
** add /tmp/new/lib/tls/libpthread-2.3.6.so
** add /tmp/new/lib/libattr.so.1.1.0
** add /tmp/new/lib/libsepol.so.1
sh-3.1# exit
root@kodama:/tmp/sid>** update /tmp/sid/root/.bash_history
root@kodama:/tmp/sid>cd ../new
root@kodama:/tmp/new>du -s
3.7M    .
root@kodama:/tmp/new>chroot . bin/sh
sh-3.1# ls
bin  dev  etc  lib  root  sbin  usr  var
sh-3.1# w
sh-3.1# find
sh: find: command not found

It'll be a way from here to something usable on a semi-embedded system, but I'm excited at how well it already works!

Am I the only one who hears "program foo, now with fancy colors" and feels a sense of dread?

Please, try for: "program foo, now with a few carefully chosen, tasteful, colorblind-friendly highlighting colors that can be easily turned off".

discussion

discussion