Using multiple Linux distributions with the Special Developer Edition

Note: an experimental implementation of support for multiple root filesystems is available in the openAOS system. Please see SDEMultiRoot for details.

The SDE is supplied with a demonstration build of Angstrom Linux, although other distributions can be installed. The question arises whether we can boot multiple Linux distributions, with the user selecting at boot time. True multi-boot (i.e., different kernels and initrds) is tricky, because there's only so much space in the flash. But if all that differs is the root filesystem image, it's actually quite straightforward. The tricky part is building a kernel and initrd which will work with different distributions of Linux. I'm assuming that if you're read this far, you already have an idea how to do this :) Lacking a better term, I'm calling the approach `multi-start'.

When the unit boots, it uncompresses the initrd from flash and mounts it at /. It then runs a script or binary, as specified on the kernel's init' parameter. With the SDE kernel, the init process is at /init.sh` in the initrd. Broadly speaking, the init script has to do the following as a minimum:

• load drivers for the hard disk and initialize
• load drivers for the display (not all units need this) and initialize
• mount the filesystem containing the real root filesystem somewhere
• (select a root filesystem image if you're supporting multi-start)
• mount the root filesystem image as a loopback on /new_root
• umount everthing that the full boot is likely to mount again, like /sys and /proc
• call pivot_root() to make /new_root the new / filesystem
• exec the new init script or binary on the new, full root filesystem. This will probably be either /linuxrc or /sbin/init

There are (as always) some complications.

1. Different Archos units have different disk and display hardware, and require different initialization. However, the init script supplied by Archos in their overlay for the Angstrom build already takes care of this -- it's just a case of copying this logic and making sure your initrd has the necessary drivers in the places the init script looks for them.

2. If you're running multiple distributions out of the same initrd then, as a minimum they all need to have an init script or binary at the same place, or at least have symlinks to make it look as if they do. /sbin/init is a fair bet for many distributions. If this can't be assumed, then your init script will need to exec a different init for different distributions.

3. Some distributions expect the initrd init script to set environment variables, and/or to have loaded certain kernel modules. In general, it probably doesn't hurt to set env vars and load modules that are _not_ specifically needed by a particular Linux installation, but leaving them out when they are needed is likely to be troublesome.

4. I've said it before but it merits saying again: the kernels have to be compatible. This is not real multi-boot. Some distributions need to have particular kernel features enabled, and it's _essential_ that the root filesystem you're mounting contains modules in /lib/modules that will load into whatever kernel you're booting. Unless the kernel is built from the same source with the same config in all the different distributions, it's going to be difficult to be 100% certain about this. However, so long as you standardise on a specific kernel version, I've found that reasonable results can be achieved.

5. At the time the initrd is executed, the framebuffer is initialized (at least in part) because it has shown the boot splash screen. But there is no console as such. There would be little point, as there is no keyboard. So to provide the user with a way to make a menu selection for the root filesystem image, you need something that will operate directly on the framebuffer and read directly from the hardware buttons. It's possible in theory to use the same utility that Archos uses in it's recovery scripts (aui), but that's proprietary, and Archos hasn't given us permission to distribute it. However, I have built a little utility that is intended to be a drop-in replacement for AUI, and allows the user to make selections. These sections can then be used by the init script to mount whatever root filesystem is required, along with other distribution-specific setup. See fbmenu for details.

Dual-start with Archos AVOS

If we can select multiple root filesystems (and we can), then it ought to be possible in principle to allow users to use the stock AVOS firmware and other Linux distributions on the same unit. After all, the AVOS root filesystem is implemented as an image (cramfs, in this case). It turns out that it is possible to do this, but there are some problems.

1. Most obviously, it's legally awkward. If you've installed the SDE, then it will have erased the Archos AVOS images on the hidden partition. So if you've still got them and are in a position to boot them, you've got them by a method which is at least legally questionable. Copying the hidden partition to the data partition before installing the SDE and then copying it back afterwards may be lawful in some jurisdictions. But passing around the Archos binaries almost certainly won't be, and I certainly don't propose to do this. If you want to dual-start with AVOS, you'll have to make your own arrangements to ensure you have the necessary Archos bits in the appropriate places.

2. The AVOS root filesystem is not very large, and is designed to be run from a ramdisk. Your init script will have to create the ramdisk and copy the cramfs image into it, then mount that ramdisk on /new_root. You'll need to skip over the digital signature at the front, which exposes another area of legal uncertainty.

3. You can't put the AVOS root filesystem on the data partition -- it has to go on the hidden partition. That's because AVOS actually unmounts the data partition when you connect the unit to a computer over USB. Or rather, it tries to. If it can't, it will still expose the data partition over USB, despite still being mounted. The result will be unhappiness.

4. AVOS requires a whole heap of modules to be loaded before it gets started. Your init script will have to do this. Some of these modules are not open-source, and will have to be copied out of the AVOS root filesystem image. Even knowing which modules to load requires inspection of Archos' own init script, which (so far as I know) can only be got by dragging it out of the flash -- a further area of legal uncertainty.