Ever wanted to get a brand new ArchLinux install in coLinux without using large boot images? This article addresses the problems faced when trying to complete such an endeavor.


This article discusses a method for getting your own 'fresh' ArchLinux install (in colinux) using the core iso and the debian initrd as described on the LinuxRescueDisks page.

Overview of steps involved:

  • Configure a new co-host
    • Download the required images
    • Create the config file
    • Create the filesystem images
  • Start and prepare
    • Format the target filesystem (ext2)
    • Copy the root image and packages cache to the intermediate filesystem
  • Boot the intermediate filesystem and install archlinux
    • Format the final filesystem (ext2, reiserfs, ext3, etc.) and mount it
    • Edit Arch setup for the special conditions we are using it for
    • Use Arch setup to select and install the packages
    • Configure the system
  • Boot final filesystem and enjoy

Warning: SquashFS modules are not recent enough to loop-mount ArchLinux squashfs images.

During development of this method a lot of difficulty was caused by the squashfs images on the ArchLinux CDROM not being able to be loop-mounted using the modules provided with colinux ArchLinux's squashfs images are made using version 4.0 of the squashfs-tools. CoLinux packs squashfs modules which can handle up to the version 3.7 archive format.

Luckily, debian's initrd can be modified to provide the unsquashfs utility from the version 4.0 squashfs-tools package. This means we can make it work, but ideally we would like to mount the images directly somewhere in the filesystem. This issue is addressed in the section #Installing squashfs-tools.

Warning: Udev doesn't like legacy kernels anymore.

While trying to install ArchLinux 2010.05 into a colinux co-host using this method it became apparent that ArchLinux's udev is missing some kernel functionality in the colinux kernel causing it to exit prematurely. The colinux kernel is probably to old.

This can be circumvented by creating static device nodes as linux admins have done before we had udev (using MAKEDEVS or mknod). We can also copy the Debian installer udev admin and daemon, this requires a little additional editing, but restores udev functionality. This issue is addressed in the section #Fixing udev for legacy kernels.

In practice[]

This method is tested, in the test scenario these artifacts were used:

  • Tested on September 4th 2010
  • Host hardware
    • Generic AMD Athlon 64 686+ system
    • CPU: 3800+
    • Mem: 2 gb of pc2700 DDR ram
    • Hard drives: 1 IDE/ATA and 1 SATA hard drive with enough disk space
  • Host software
    • Windows XP Pro SP3 32bit (not nlite or xplite modified).
    • coLinux v0.7.7.1
      • Installed in C:\coLinux
  • Filesystem images
    • debian's netboot initrd.gz, see LinuxRescueDisks
    • ArchLinux core install iso
      • Version 2010.05

Note: When trying to mimic these settings you might change the install directory of coLinux. With this maneuver it's likely the path to the coLinux driver is changed as well. In this case you need to reinstall the driver using the deamon program (see below).

Linux driver (linux.sys) path broken[]

This problem description and solution need their own page.

When the above not is the case one can get an error similar to this one.

colinux: manager open: last error: The system cannot find the file specified.
Cooperative Linux Daemon, 0.6.4
Compiled on Mon May 29 22:19:09 2006

colinux: manager open: last error: The system cannot find the file specified.
error initializing
driver not installed
daemon: exit code 87c0a001
daemon: error - CO_RC_ERROR_ERROR, line 40, file colinux/user/monitor.o (62)

Note: this error message is created by uninstalling the driver, not relocating the install directory as mentioned in the note above.

This error message is more to the point than the one printed when the drivers path is broken.

Personal note:

The original message which I can't recall happened to me when I completed this chain of events.

Start host computer
Install coLinux
(driver is installed, loaded in ram and kept there)
Move colinux instalation directory
Start and stop some colinux co-host/guest
Restart host computer
Start some colinux co-host/guest


Remove and reinstall the driver.

Use the colinux-daemon.exe executable for this:

colinux-daemon --remove-driver
colinux-daemon --install-driver

Now you should be ready to go again.

You can check the status of the driver using this command:

colinux-daemon --status-driver

It should say something like:

Cooperative Linux Daemon, 0.6.4
Compiled on Mon May 29 22:19:09 2006

checking if the driver is installed
current state: 4 (fully initialized)
current number of monitors: 0
current linux api version: 10
current periphery api version: 15

Hands On[]


This article assumes you already have a working coLinux installation and are familiar on how to start a linux guest/co-host using your install.

Also you should have moderate linux experience, or someone who can help you when you get stuck. Skills needed are basic linux skills:

  • Running commands
  • Understanding bash scripts
  • Understanding of most common linux utility programs
  • Mounting / unmounting logic including filesystem types
  • Configuring a new archlinux installation (walking the /etc dir)
    • Think of configuring network, daemons, etc
  • Installing additional packages, if needed (using pacman)

These skills are not required, if you are lucky you can just copy and paste the commands and get away with it. However, to understand what's going on the above skills are recommended.

Not needed skills:

  • (Re)building a kernel
  • Configuring bootloaders
  • Programming

In short, when you are a linux/unix user with some experience you'll be nearly there already.

Pre: The colinux config file[]

The colinux config file used in the field testing.




eth0=ndis-bridge,"Network Connection"

# kernel parameters

Pre: The filesystem images[]

As seen in the config file above, we will be using three custom file images:

  • rootfs - Which will contain the final install of ArchLinux. During field testing this disk file was 2GB big. It can probably be as small as 500MB for the installation to work, but when you really want to customize ArchLinux a larger disk image can be wise.
  • swapfs - In field testing this was not used but is a good idea when you don't have copious amounts of RAM available.
  • cdromfs - This will hold the uncompressed squashfs images from the iso image. The uncompressed cdrom weighs in at about 800MB so in field testing an image of 1GB was used.

Use the commands below to create the different images on windows:

fsutil file createnew rootfs 2147483648
fsutil file createnew swapfs 536870912
fsutil file createnew cdromfs 1073741824

Stage 1: Booting the Debian initrd[]

As can be read on the LinuxRescueDisks page, Debian has an initrd image which can be used to do all kinds of things.

We will be using it to create a temporary drive and extract the squashfs images used on the newer ArchLinux iso's onto it.

To do this we will boot up and install mke2fs and squashfs-tools on the ramdisk.

Loading Debian installer's components and mke2fs[]

To save time working with the available "ip" network interface configuration utility and manually downloading and unpacking packages including dependencies, we will use the Debian installer to do this for us.

For full control you should go into expert install mode, consult the LinuxRescueDisks Debian initrd section on how to do this.

Once you're in the main menu select the "Download installer components" menu item. Then three stages will follow:

  • The installer will first try and detect network hardware.
  • It will then try and configure the hardware using DHCP and if that doesn't succeed it will give you the opportunity to configure the hardware manually.
  • And finally you will be offered the chance to select additional packages. You can safely leave everything unchecked. But if you want, you can select packages. For example, to continue this installer using ssh (package network-console).

When the last step completed successfully and you're back in the main menu you can switch to a console terminal (hit ALT+F1 or ALT+F2).

The ramdisk should now be loaded with mke2fs.

Installing squashfs-tools[]

To install the squashfs tools we will manually download and unpack it. This is a real .deb package, but should work fine with the installer's glibc.

# install squashfs-tools
udpkg --unpack squashfs-tools_4.0-8_i386.deb

Note: the urls used in the block above will most likely be outdated by the time this is used by anyone. To get new urls you need to look around on the Debian mirrors. You can also use Debian's Packages.gz file to check dependencies and location of all packages available.

Temporary install drive and unpacking install media[]

After this you can issue the following commands to format the cdromfs disk and extract the squashfs images on it.

mke2fs /dev/hdd

cd /mnt
mkdir cdrom archcd
mount /dev/hdc cdrom
mount /dev/hdd archcd

mkdir -p archcd/src/core/pkg/
unsquashfs -force -dest archcd/src/core/pkg/ cdrom/core-pkgs.sqfs
unsquashfs -force -dest archcd/ cdrom/root-image.sqfs
unsquashfs -force -dest archcd/ cdrom/overlay.sqfs

Fixing udev for legacy kernels[]

When using the test setup (colinux and ArchLinux 2010.05) udev wouldn't start. This is caused by it not being able to get a netlink from the kernel. This is a new feature of udev, I think, and is not supported by the colinux kernel yet.

We can make /dev static in the ArchInstall rootfs and make sure udev and co don't start.

But while testing I've done a dirty fix, I've copied the udevd and udevadm binaries from Debian's initrd into the ArchInstall rootfs.

To do this, issue the following commands

cd /mnt/archcd/sbin

mv udevd udevd.old
mv udevadm udevadm.old

cp /sbin/udevd .
cp /sbin/udevadm .

Now, this older udevd binary doesn't work well without the /dev/.udev/db directory present. So we need to create it before udev is started, to accomplish this we edit rc.sysinit (nano /mnt/archcd/etc/rc.sysinit).

We change the section which looks like this:

echo > /proc/sys/kernel/hotplug

stat_busy "Starting UDev Daemon"
/sbin/udevd --daemon

run_hook sysinit_udevlaunched

to look like:

echo > /proc/sys/kernel/hotplug

stat_busy "Starting UDev Daemon"
mkdir -p /dev/.udev/db
/sbin/udevd --daemon

run_hook sysinit_udevlaunched

If you still cannot get udev to create devices, most notably booting will halt cause it cannot access a tty to use to login to the box, something else has gone bump and you can try editing rc.sysinit to not start udev and adding static device nodes to /mnt/archcd/dev/ manually.

Post stage 1: Switching root filesystem[]

At this time you'll have a working fresh ext2 ArchLinux installation image. To boot this you need to use the normal coLinux initrd instead of Debian's one.

This is accomplished by changing the initrd directive in the config file:




You also have to make sure the intermediate filesystem (cdromfs) is booted and that it's mounted read/write instead of read-only. The install cd expects to be booted from a read/write filesystem and will give a lot of errors when booting if the filesystem is read-only. So change:

# kernel parameters


# kernel parameters

Now reboot your colinux and it will seem if you just got colinux to read install iso's the way you would expect.

Stage 2: Prepare the final filesystem and install ArchLinux on it[]

Now, if you are familiar with the ArchLinux installation cd, you will know you are dropped on a shell prompt and have to start the installation script manually (it's /arch/setup). This will not work as expected as ArchLinux is not exactly build for this kind of installation procedure. You will not be able to partition and format filesystems from within the setup and this is required before you can select and install packages.

So first we have to make a new filesystem manually on the final disk image and mount it on /mnt as setup will install it's packages there. Use the following commands:

mkreiserfs -f /dev/hda
mount /dev/hda /mnt

Now we have taken care of the disk management menu item for the setup. Only thing is, setup doesn't know that we have been so nice as to do it's work for it. So we need to modify the setup.

In file /usr/lib/aif/core/libs/ around line 178 look for function interactive_prepare_disks. It should look something like this:

interactive_prepare_disks ()
	local ret=1 # 1 means unsuccessful. 0 for ok
	[ "$BLOCK_ROLLBACK_USELESS" = "0" ] && show_warning "Rollback may be needed" "It seems you already went here.  You should probably rollback previous changes before reformatting, otherwise stuff will probably fail"
	while [ "$DONE" = "0" ]
		rollbackstr=" (you don't need to do this)"
		[ "$BLOCK_ROLLBACK_USELESS" = "0" ] && rollbackstr=" (this will revert your last changes)"
		[ -n "$NEXTITEM" ] && default="$NEXTITEM"

		#TODO: inform user (using dialog's --item-help or so) that autoprepare uses 1 disk and uses it in a "fairly regular" (though somewhat customizable) manner.
		ask_option $default "Prepare Hard Drive" '' required \
			"1" "Auto-Prepare (erases an ENTIRE hard drive and sets up partitions, filesystems and mountpoints)" \
			"2" "Manually Partition Hard Drives" \
			"3" "Manually Configure block devices, filesystems and mountpoints" \
			"4" "Rollback last filesystem changes$rollbackstr" \
			"5" "Return to Main Menu" || return 1

		case $ANSWER_OPTION in
				[ "$BLOCK_ROLLBACK_USELESS" = "0" ] && ask_yesno "You should probably rollback your last changes first, otherwise this will probably fail.  Go back to menu to do rollback?" && NEXTITEM=4 && continue
				interactive_autoprepare && NEXTITEM=5 && ret=0 && DISK_CONFIG_TYPE=auto;; #TODO: for some reason. if this completes $?=0, next item will be 1 :/
				[ "$BLOCK_ROLLBACK_USELESS" = "0" ] && ask_yesno "You should probably rollback your last changes first, otherwise this will probably fail.  Go back to menu to do rollback?" && NEXTITEM=4 && continue
				interactive_partition && ret=1 && NEXTITEM=3 && DISK_CONFIG_TYPE=manual
				[ "$BLOCK_ROLLBACK_USELESS" = "0" ] && ask_yesno "You should probably rollback your last changes first, otherwise this will probably fail.  Go back to menu to do rollback?" && NEXTITEM=4 && continue
				interactive_filesystems && ret=0 && NEXTITEM=5 && DISK_CONFIG_TYPE=manual
				if [ "$BLOCK_ROLLBACK_USELESS" = "1" ]
					ask_yesno "It seems like you haven't partitioned/formatted/mounted anything yet (or rolled back already).  This operation is useless (unless the installer is buggy), but it doesn't harm.  Do you want to continue?" || NEXTITEM=5
				if [ $? -eq 0 -o "$BLOCK_ROLLBACK_USELESS" = "0" ]
					if rollback_filesystems #TODO: this part doesn't belong here. move it to ui-interactive. (interactive_rollback)
						infofy "Rollback succeeded"
						show_warning "Rollback failed" "Rollback failed"
				DONE=1 ;;
	return $ret

Now, at the bottom of the case statement change:

				DONE=1 ;;



You can now start the install script:


First select cd as the package source, as they have already been unpacked in /src/core/pkg/.

Now go into the disk management sub-menu, but immediately return to the main menu by selecting the last option in the list.

Your cursor will now be placed on the select packages item, enter that sub-menu and select the packages you want.

Upon returning to the main menu your cursor will be placed on the install packages item, select it and watch your packages being installed.

You can configure the system further from the setup utility, but you can also go to /mnt/etc and edit it there directly using your favorite text editor. It's up to you.

In either case you will need to add the root filesystem to the /mnt/etc/fstab file. Add something along the lines of:

# <file system>        <dir>         <type>    <options>          <dump> <pass>
/dev/hda               /             reiserfs  defaults            0      0

Also the just installed udev could again not work with the colinux kernel, if it doesn't work you should fix this using one of the procedures outlined in the #Fixing udev for legacy kernels section.

Post stage 2: Switching root filesystem (again)[]

The final filesystem is ready and can be booted. To do so we will edit the config file to make the root filesystem be the final filesystem image (rootfs) and that it will be mounted read-only by the kernel.

This is accomplished by changing the config file like this:

# kernel parameters

gets changed to

# kernel parameters


At this stage, when you reboot your co-host and everything went as it should you will be booted into a fresh ArchLinux install backed by a reiserfs root filesystem.

Good luck and have fun with it!