Arch Linux in VirtualBox on EEE PC

For background refer to my previous post.

Now I’m going to go into some detail of the Arch Linux (hereafter referred to as Arch) installation and configuration process, or at least how it played out for me. I won’t be addressing those parts where the Beginners Guide was crystal clear and everything went as expected. I will be addressing the parts where I got confused or alarmed or where things just weren’t working as I would have expected.

VirtualBox

I should start off by mentioning the rather significant detail that I decided to install Arch as a guest OS running in VirtualBox under Windows XP. When I started out this seemed like a good idea; I wouldn’t have to worry about repartitioning the drive I currently had Windows XP on, I would be able to familiarize myself with Arch and how well it functions on the EEE PC before committing to it, it would be fun to try out VirtualBox, and if everything was hunky dory I hoped I could just take my VirtualBox disk image and clone it to a physical partition and be done. At that point I’d turn the tables and run Arch as my main OS while booting Windows XP as a VirtualBox guest OS on and as-needed basis.

Turns out I was naive. As I worked my way through the installation and configuration I realized that I’m failing to test how well Arch runs on the EEE PC. The stuff I would expect to be most problematic or difficult to configure doesn’t really come into play when running as guest OS. Video (including “compressed” 1024x768), sound, network cards, wifi, webcam, multi-touch trackpad, power management (including “Super Hybrid Engine”); all these are either not applicable or free-riding on the Windows drivers. I still have no idea how well all these things would work without Windows XP behind the scenes. In addition my Arch installation is configured for the mock hardware interfaces that VirtualBox exposes to it; for all I know it probably won’t run at all outside of VirtualBox!

Even had I realized the above I suspect I would still have chosen to install in VirtualBox first to try things out. Or perhaps I would have opted to try out another distro with a Live CD (or, more specifically, live thumb drive). Anyway, back to the Arch installation process…

Recovery

It turned out the mistake that I was referring to in my previous post wasn’t as fatal as I feared. I was in the Configure the System section of the Beginners Guide and believe I had made my way through initramfs and was about to select /etc/rc.conf in the menu when I inadvertently hit the ESC key. This exited the menu and a bunch of processing commenced, entirely prematurely. I had just skipped the steps where the guide said (with emphasis as it appears in the guide):

Closely following and understanding these steps is of key importance to ensure a properly configured system.

and, a few paragraphs further down:

Note: It is very important at this point to edit, or at the very least, to verify by opening, every configuration file. The installer script relies on your input to create these files on your installation. A common error is to skip over these critical steps of configuration.

I was fully expecting to have to wipe everything out and restart the installation procedure from scratch. However, once the configuration was done I was returned to the main menu and, lo and behold, I could back up one step and chose to reconfigure. This I did, following the guide closely, and as far as I can tell all is well. Sometimes you get lucky.

General installation process

I decided to install off the most recent core ISO (archlinux–2008.06-core-i686.iso). The relative merits of core vs FTP were unclear at the time but I believe if you use the FTP ISO you’ll end up with an up to date system from the start, while I ended up with eight month old packages.

I’m not particularly fond of the fuzzy compressed mode or scrolling the screen so I chose vga=771 to get 800x600 resolution instead of vga=773 and 1024x768. I imagine that without VirtualBox the scrolling and compressed mode wouldn’t have been available at all in which case vga=773 would be a very poor choice.

The first point of confusion arose when partitioning the hard drive. In the cfdisk interface a partition could be flagged as “bootable,” which sounds like it would be a desirable property for the partition with /boot filesystem. However, there is no mention of the flag in the Beginners Guide and in the example no flags are set on the partitions. I stayed true to the guide and didn’t set the flag and everything has worked fine. So while there isn’t an error per se in the guide it would be nice if it explicitly mentioned that the flag doesn’t need to be set. It certainly would have saved me some angst.

For the record I didn’t want to deal with deciding what is an appropriate size for all the file systems so I just went with one for / and a separate swap partition. It’s probably ridiculously easy to resize partitions after the fact but I wasn’t in a mood to investigate at the time.

At first I disabled crond in /etc/rc.conf but later realized I was missing out on good stuff like updatedb (necessary for locate to work) so I re-enabled it.

Setting up sound with alsa had me scratching my head for a while until I realized I had to enable sound for the guest in the VirtualBox settings.

I skipped part IV of the guide since I had already decided to use xmonad as my window manager. This was readily accomplished by pacman -S xmonad and I continued with other packages: vim, texlive, firefox…

The first “discrepancy” I noticed occurred when pacman was “updating kernel-headers” after installing cairo. It reported the rather disconcerting message:

error: scriptlet failed to execute correctly

I don’t mean to imply that the message itself is terribly scary, scriptlet even has a cutesy ring to it, but I’d imagine its not good to have stuff going wrong when messing with your kernel. Anyway, I have no idea what that means or what the scriptlet that failed was supposed to do. The error didn’t show up in /var/log/pacman.log so I presumed it must have come from a build script external to pacman or something along those lines. The next time I saw a scriptlet fail was when updating shadow:

Fixing gshadow file...
add group 'uucp' in /etc/gshadow ?grpck: the files have been updated
error: scriptlet failed to execute correctly

Again not sure what that meant, nor what to do about it. Hoping it was nothing.

VirtualBox Guest Additions: Take One

At some point I realized that to get decent video drivers supporting the native 1024x600 resolution of the EEE PC I had to install the VirtualBox Guest Additions. I had the option of installing from the ISO that came with VirtualBox, but there were no instructions specifically for Arch. I saw mention in some forum of a virtualbox-ose-additions community package. Doing a pacman -Si virtualbox-ose-additions revealed that it was version 2.0.4–1 while my installation of VirtualBox is 2.1.2. The build date was 2008–11–12 so I decided to try my luck hoping not much would have changed between the two versions, especially given that the ISO is an auxiliary part of VirtualBox. Well, I was stopped short by pacman:

error: failed to prepare transaction (could not satisfy dependencies)
:: virtualbox-ose-additions-modules: requires kernel26<2.6.28>

I checked my kernel26 and it was version 2.6.25.6–1 which certainly seemed to comply with the stated requirement. However, a pacman -Si virtualbox-ose-additions-modules revealed the following requirement:

Depends on     : kernel26>=2.6.27  kernel26<2.6.28>

OK, my kernel26 didn’t fulfill the requirements, although the requirement reported wasn’t the one that was violated.

By now I was thinking maybe I should upgrade my kernel26. In fact, I was mildly surprised that pacman didn’t go ahead and do that for me. I checked with pacman and saw that the latest version of kernel26 is 2.6.28.2–1. It dawned upon me that the reason pacman reported the requirement kernel26<2.6.28 was because that was the one that would have been violated had the kernel26 been upgraded to the latest version. Makes sense I guess but would have been nice if the error message was more explicit about it.

I decided to hit the AUR site to see if it could shed any additional light on these packages and indeed, there I saw that virtualbox-ose-additions had been flagged as out of date! I can’t help but wish that a pacman would reveal this rather important piece of information; pacman -Si loses a lot of its appeal if I have to double-check each package on the web before installing. (One could argue that pacman implicitly “knows” this particular package is out of date by virtue of its dependencies being unsatisfiable, but I believe this is a special case; other packages may have been flagged e.g. for security reasons even though there dependencies are satisfiable.)

Recommendation: Always check package status in AUR before installing, especially before deciding to “try your luck.”

(I later realized that I was using the PUEL VirtualBox and not VirtualBox OSE so the packages in question may never have been applicable in the first place.)

Upgrading all packages

Given that the VirtualBox Guest Additions seem to be particular about the kernel version I decided that it would be a good idea to update the kernel and all my other packages before proceeding. A pacman -Su identified 76 packages needing upgrades and started downloading (these are presumable the packages that were installed from the eight months old core ISO). Upon completion of the downloads pacman complained:

error: failed to commit transaction (conflicting files)

and listed a mass of files in /usr/lib/klibc/include/asm. A quick google revealed an announcement and fix for this: rm /usr/lib/klibc/include/asm. Having removed the symlink all 76 packages upgraded just fine.

VirtualBox Guest Additions: Take Two

Back to the VirtualBox Guest Additions; it seemed my only option now was to install them from the ISO. I could either use the ISO provided with my Windows version of VirtualBox or I could install the virtualbox-additions package which to my understanding would just download the same ISO for me; I’d still have to mount it and install the actual software myself. I decided to go with the ISO that came with my VirtualBox.

I mounted the ISO in the VirtualBox Media Manager but when attempting to mount /media/cdrom in Arch I was told that the cdrom was missing from /etc/fstab. This was perfectly true; the EEE PC has no optical drive so during Arch configuration I had left the cdrom commented out. At the time I hadn’t fully internalized the distinction between installing straight to the EEE PC vs installing on VirtualBox, and it hadn’t occurred to me that VirtualBox provided emulated optical drives. I uncommented the cdrom in /etc/fstab and it mounted without further drama.

The installation instructions for the VirtualBox Guest Additions were conflicting and confusing between the wiki, forums, and VirtualBox manual. The VirtualBox manual recommended installing dkms first, but the dkms package in AUR was flagged as out of date. I tried my luck with the instructions on the ArchWiki’s VirtualBox page instead; verify gcc and make are installed and sh /media/cdrom/VBoxLinuxAdditions-x86.run. The wiki warned of “errors about init scripts and run levels and what not” but to my great surprise everything built and installed with nary a complaint.

I rebooted, and then shutdown. After the shutdown Arch wouldn’t start; it would switch resolution to 800x600 but get stuck there with a black screen. I rebooted in fallback mode, removed vga=771 from /boot/grub/menu.lst and retried. Now that the boot process stayed in 640x480 I could see what was going wrong, although I little idea what it meant:

Code:  Bad EIP value.
EIP: [<00000000>] 0x0 SS:ESP 0068:c042fdf4
Kernel panic - not syncing: Fatal exception in interrupt

I guess someone doesn’t like zeroes. Restarted in fallback mode: same error this time! Normal mode: same error. Rebooted the EEE PC completely (this had helped previously with another VirtualBox problem): same error in both modes. I noted that there seemed to be some variation in when in the boot process the kernel panic occurred, although it was always very early. I had recently unplugged the EEE PC at which time it switched to its “Auto Power-Saving” mode with lower (and probably variable) clock speed. I speculated that maybe this mode was causing some random timing error (“not synching,” remember?) in the early bootup process. I changed to the “Super Performance” mode, rebooted Arch, and lo and behold, it worked! Once the boot was complete I switched back to the Auto Power-Saving mode.

I’ve had these kernel panics several times since. Also in Super Performance mode and with AC connected. They’re more frequent when power is disconnected and CPU throttled and I’ve rarely had two in a row with AC connected. I don’t think I had any of these before installing the VirtualBox Guest Additions.

Recommendation: Do not change the resolution of your fallback installation.

Recommendation: If you get kernel panics during bootup disable CPU throttling and if possible connect AC.

VirtualBox Guest Additions: Configuration

I added rc.vboxadd to /etc/rc.conf. During bootup the message

Starting VirtualBox host to guest time synchronization

is printed to the console which I presume means that rc.vboxadd-timesync is started by rc.vboxadd without having to be added individually to the daemons in /etc/rc.conf.

When shutting down Arch I noticed the error message:

/etc/rc.d/functions: line 167: /etc/rc.d/vboxadd-timesync: No such file or directory

The correct file name should be /etc/rc.d/rc.vboxadd-timesync. I tried to figure out what was the problem but wasn’t familiar enough with rc.d to be able to figure it out. In fact, I couldn’t even locate where the stop_daemon function where the error occured was called from.

Update 2009–02–20: Alan Savage figured this one out and submitted a patch for it.

Also, running /etc/rc.d/rc.vboxadd-timesync start (or stop) from the command line resulted in:

/etc/rc.d/rc.vboxadd-timesync: line 226: begin: command not found

The begin() function was indeed missing from the code block that defined functions for Arch so I copied the one from the Gentoo block and inserted it at line 169.

Update 2009–02–14: A better place to copy begin() from is the Arch-specific definition in rc.vboxadd. I’ve submitted a patch for this to the vbox-dev mailing list.

Configuring Xorg

Here are the contents of the xorg.conf file that VirtualBox Guest Additions installed:

# Default xorg.conf for Xorg 1.5+ without PCI_TXT_IDS_PATH enabled.
#
# This file was created by VirtualBox Additions installer as it
# was unable to find any existing configuration file for X.

Section "Device"
        Identifier      "VirtualBox Video Card"
        Driver          "vboxvideo"
EndSection

My impression was that Xorg was supposed to use hal to discover the video modes that the “VirtualBox Video Card” supported, and that the X screen resolution would seamlessly follow the VirtualBox window size. This didn’t work for me and I was stuck with 640x480 with no other modes available according to xrandr. I had to add the following to /etc/xorg.conf to get additional resolutions:

Section "Screen"
        Identifier       "Default Screen"
        Device           "VirtualBox Video Card"
        SubSection "Display"
                Modes   "1024x600" "800x600" "640x480" "1024x768"
        EndSubSection
EndSection

(As an aside I also tried generating an xorg.conf using hwd but when it didn’t use the vboxvideo driver (opting instead for vesa) I didn’t pursue that avenue further.)

The only other problem I’ve had with Xorg is that switching modes with Ctrl+Alt+Keyopad-Plus/Minus was unreliable at best at rendered the session unusable at worst. I disabled these keys with the DontZoom option as described in the xorg.conf manpage:

Section "ServerFlags"
        Option "DontZoom" "true"  # Disable mode-switching keys.
EndSection

Instead I use xrandr to switch modes, e.g:

xrandr --output VBOX1 --mode 1024x768

I have set up aliases for this, e.g.:

alias 1024x768='xrandr --output VBOX1 --mode 1024x768'

It’s a wrap!

That pretty much sums it up. Most everything seems to be in working order now and it’s trivial to install additional software with pacman as needed. The one thing I know I’ll want to figure out sooner or later is how to how to “hotswap” keyboard layouts but I’m in no hurry.