I use one of two main ways to get linux onto a machine:
If I'm not sure I want to lose the pre-installed Windows installation or I want to have a controlled migration path to linux via a dual boot then the latter is definitely the better option. Getting the iso images onto the Windows disk is usually quite easy over a fast LAN. The only tricky part is finding an appropriate tool to shrink the Windows partition so that there is enough room for linux. I chose the former course of action, as the patched Windows XP installation (Service Pack 1: which is essential to fix various glaring Microsoft security loopholes) does not work on the C1MHP.
The C1MHP comes with a CRWD2 CD-R/RW/DVD player and it is able to boot from this. However this is a FireWire device and I had difficulty trying to install RedHat 8.0 initially. It would boot into the anaconda install program but after that had apparently lost sight of the FireWire device and could no longer see a RedHat install tree.
This experience forced me to try RedHat 9, and this installed from CD without any such hitch. The relevant ohci/sbp2 driver was loaded at the start of the process and everything went smoothly from there.
These are the various kernel versions I either tried or thought about trying before settling on 2.4.22-acpi:
CONFIG_PM=y
# CONFIG_APM is not set
#
# ACPI Support
#
CONFIG_ACPI=y
CONFIG_ACPI_BOOT=y
CONFIG_ACPI_BUS=y
CONFIG_ACPI_INTERPRETER=y
CONFIG_ACPI_EC=y
CONFIG_ACPI_POWER=y
CONFIG_ACPI_PCI=y
CONFIG_ACPI_SLEEP=y
CONFIG_ACPI_SYSTEM=y
CONFIG_ACPI_AC=m
CONFIG_ACPI_BATTERY=m
CONFIG_ACPI_BUTTON=m
CONFIG_ACPI_FAN=m
CONFIG_ACPI_PROCESSOR=m
CONFIG_ACPI_THERMAL=m
# CONFIG_ACPI_ASUS is not set
# CONFIG_ACPI_TOSHIBA is not set
CONFIG_ACPI_DEBUG=y
CONFIG_ACPI_RELAXED_AML=y
It is gratifying to note that with the new kernel, the machine can now automatically switch itself off on an INIT 0. Additionally, in the kernel configuration section entitled Processor type and features, it seems necessary to set:
CONFIG_X86_MSR=y
CONFIG_X86_CPUID=y
if the cpu processor frequency stepping (used for power-saving by the longrun script) is to work. Of course you tend only to find this sort of thing out after compiling them as modules.
To get this working, both acpi and acpid need to be installed and running. Also the following modules need to be loaded, if they haven't been compiled into the kernel.
ac.o
battery.o
button.o
fan.o
processor.o
thermal.o
I have modified the /etc/init.d/acpid script to load/unload these modules automatically in the same fashion as, say, the /etc/init.d/pcmcia script does. This seems to be appropriate since acpi/acpid don't query any particular /dev abstraction (which would allow autoloading from /etc/modules.conf) -- but there may be a better suggestion.
Just a small point about processor.o: although it doesn't prevent the module loading or working, I see the following message on the console and in /var/log/messages:
acpi_processor-0899 [55657] acpi_processor_get_per: Unsupported address space [127] (control_register)
Installing acpid supplies the directory /proc/acpi, which is in turn used by acpi to provide an apm-like interface to other applications (use acpi -V to view this information). Now on starting the battery charge applet in gnome (for instance), the computer correctly reports the battery/ac power status.