• eeeXubuntu is not a distribution. It is not a fork of Xubuntu specifically for the eee. Rather, it is a refinement on the Ubuntu install process for this CD-less form factor and hardware configuration.
  • Fixes, if possible, should be sent upstream
  • In a perfect world, eeeXubuntu wouldn't be needed.
• eeeXubuntu should work within Ubuntu's package management system whenever possible. Scripts are fine, but they should be atomic, reliable, and consider the upgrade path for the machine. (What happens if a package is upgraded?)
• The eeePC is a crossover device. It comes with Linux; for many people, it might be their first exposure to Linux. Keeping this in mind, eeeXubuntu might be their first Ubuntu experience as well. The quality of the final package should reflect this.
  • Hard-core tweakers are not the audience.

(… all this is open to suggestion, of course)

Description: This package is built from a Madwifi development snapshot (dated October 18, 2007) patched to support the Atheros AR5007EG chipset using the patch available at MadWifi Ticket #1679.

Download: madwifi-source_0.9.3.3+r2756.20071018-1_all.deb

Description: Although Ubuntu ships with an atl2 driver in its generic module package, this driver is unstable on the eeePC for many users. eeeXubuntu includes a binary version of the driver compiled from the unmodified source code made available by Ben Armstrong in a post on the eeeuser forums.

Download: atl2-source_1.0.40.4-1_all.deb

• What's the best way to implement? Custom re-roll of the acpi package specifically for the eeepc? Script changes to the config files?
• Is a custom kernel module required?

• By using powertop search better optimization for eeeXubuntu

• Use noatime
• Remove hardcoded “cdrom” reference created during the install process

Most of the good stuff is contained in /preseed/eeepc on the CD. I'm hooking the install process using a script in the casper filesystem which the Live CD boots. This process is somewhat poorly documented in general. However, it's relatively straightforward.

Ubiquity runs the install process, copies over the Live casper filesystem (mounted read-only), and removes unneeded packages at the end of the process. As a last step, the scripts in /usr/lib/ubiquity/target-config are run immediately before the system is restarted. The wrapper script /usr/lib/ubiquity/target-config/50eeepc is used to invoke the changes stored in /preseed/eeepc.

Currently, there are two methods for modifying the target Xubuntu install.

• patches: are primarily used for configuration files.
• files: contain .tar.gz archives that can be applied at the root level of the target filesystem

There should probably be a third type:

• scripts: self explanatory. Would be the easiest way of installing custom debs.

The 50eeepc script invoked by Ubiquity iterates through all the changes in /preseed/eeepc.

Note: Scripts must be absolutely silent. Any output can hang the reboot at the end of the install process (Ubiquity interprets this as an error condition). Currently I'm logging to the root of the target filesystem to aid in debugging.