I recently got a 13″ Macbook Pro (5.5) and of course need to install Arch Linux on it. So here goes a log of my install experience. I am not going to cover everything, as there is already basic instructions on the Macbook page in the Arch Wiki and all over the net.

The basic specs are:

• 2.53GHz Intel Core 2 Duo
• 4GB (2x2GB) 1066MHz DDR3 SDRAM
• 500GB Serial ATA; 5400 rpm

More details as I deal with getting individual components working…

Installation: The install went fine using the latest test iso (2010.04.19-core-i686). The only “trick” was to change the partition table from GPT format (to msdos) before entering the installer. Luckily, parted is included on the install CD so this was simple. Also, install GRUB on the partition holding /boot instead of /dev/sda. There was no need to do anything with rEFIt as many guides prepared me for, but I think that is because I did not dual boot.

The final stage is to boot the OSX install CD and run:
bless --device /dev/disk0s2 --setBoot --legacy --verbose to speed up the boot time before you get to GRUB (3s vs 20s).

Video: This has a NVIDIA GeForce 9400M card, so a pacman -S nvidia and nvidia-xconfig then we are basically good to go.

Screen Brightness: There is mbp_nvidia_bl in the kernel, so you think that would work but no… Any changes made to the backlight level appear to be registered (and gnome-power-manager gives me a nice on-screen indicator that changes are being made) but the brightness stays the same. The Mactel PPA for Ubuntu contains a nvidia-bl kernel module which does the job. Grab the PKGBUILD here.

Keyboard Backlight: Using pommed is supposed to make this work and it did to an extent. The only issue was roll over from almost completely dimmed to fully on that made disabling the keyboard backlight impossible. Instead, I am just adjusting it manually using:
echo 255 > /sys/class/leds/smc::kdb_backlight/brightness(TODO: write a script using this to bind the adjustment keys to.) In OSX, this would automatically come on in low light conditions but I have no idea how to approach that.

Touchpad: This “works” out of the box, although is completely broken as far as I am concerned. I quickly found out that a major touchpad use is to click with your thumb and then use a finger to select text or move/resize a window, etc. That does not work as touching your finger after the click with the thumb is interpreted as some sort of multitouch event. A patched bcm5947 module fixes this (but is a hack and is unlikely to be included upstream…). Grab the PKGBUILD here.

Wifi: It has a Broadcom BCM4322 802.11a/b/g/m wireless card. That does not work with the b43 driver, so requires broadcom-wl driver. Grab the PKGBUILD here.

Suspend to RAM: Worked out of the box. I was only required to tell xfce4-power-manager to use it.

Webcam: Used the isight-firmware-tools package to extract the firmware from the file that I remembered to grab from OSX before wiping (or perhaps used google to find…) and restart.

Sound: Installed alsa, ran alsaconf and everything worked. Shortcut keys required setting up.

Keyboard: Ignoring the lack of Home/End/Page Up/Page Dn keys, the thing that most annoys me is that to by default the “action” functions take preference over F1-12. I use F1-12 a lot more that the action keys. So these need to be swapped (TODO: do this…)

Bluetooth: Untested. I have no real use for this at the moment…

Apple Remote: TODO

Long time reader Greg writes:

Why do you think that even though Arch’s userbase numbers have exploded during the last year, the number of contributors (not counting the AUR) remains almost the same?

Well Greg, here are my opinions on the issue. I should point out that these are my opinions and do not necessarily reflect the opinion of Arch developers as a whole.

Firstly, I tend to agree with this sentiment. Over the last six months to a year, there has only been one new person that has stood out to me as developer material based on the contributions they have made (and one who just will not accept the position no matter how much we ask – you know who you are!).

I think the primary reason for this is a very large change in userbase. The earliest comment by me that I can find noting this change was in the middle of 2008. A lot has changed since then (I was not an Arch developer or forum moderator then and I am now getting a Mac…), but the change in userbase has continued over the years. I think Arch has changed from what was a “Do It Yourself” distribution to one where people expect a lot of help. This is very evident on the forums, where very basic questions are asked on an hourly basis. People think there is a lot of “RTFM” on the Arch forums these days, but ask those same questions on the forum three years ago and that would be considered a polite response. It seems that despite the large increase in the number of users, the number of people with the skills required to fix a problem that they notice has not increased at the same rate.

The second reason I see is that there are less things to be fixed in Arch. The only reason I started contributing to Arch is so that I could fix things that annoyed me and that continues to be my primary motivation. I can imagine that the distribution as a whole runs rather smoothly from a users point of view, at least compared to historically. Also, a lot of the “easy” bugs in the user visible parts of the distribution have already been fixed, so the barrier to entry is higher. Saying that, I have made a couple of patches to pacman itself in the last few weeks and I still know next to nothing about the actual pacman codebase (I focus on makepkg). So there are still reasonably easy pickings for motivated individuals to get themselves familiarised with the code before tackling harder issues.

Finally, I think there is becoming a gulf between developers and users. Perhaps this is an entirely unintended side-effect of the change in userbase. I know that many long term Arch users (including some developers) found the change in the types of questions being asked and demands being made on the forums quite demotivational and now spend far less time there. This means less interaction between users and developers, resulting in the developers being seen as quite a separate group. From a developer point of view, this could not be further from the truth. Arch is a “community distro” and contributions from the community are strongly encouraged. Remember that the x86_64 port started as a community project. If a user comes up with a good idea, and more importantly provides some code or implementation to back it up, it will be considered by the development team just as it would if a developer suggested it. Equally, developers make suggestions that are not taken up (trust me… I have had ideas rejected, taken out the back and shot before being buried in a shallow grave in a forest). But remember, talk is cheap. There have been many, many threads about the importance of package signing in pacman, but no-one has but in a decent effort to get this completed.

In short, we need more community members to step up and help out wherever they can. The core Arch development team is relatively small and our continued progress (beyond pure packaging) relies on contributions from the community. Even packaging could use more people (and we do take applications to become a developer from known community members). I am sure that there is something that annoys every user about their system. Why not try and fix it?

A while back, I wrote about using an x86_64 kernel on an i686 userland. After using this setup for a while, I began to discover that it is not that user friendly to have to use linux32 in front many commands. In particular, when building software the ./configure needs to be prefixed with it and bash can not handle creating an alias to transparently do that. Also, I would need to make aliases for all build tools I could encounter (make, cmake, qmake, …), which is almost an impossible task.

In true Baldrick style, I came up with a cunning plan… What if I called my shell with a linux32 prefix and then my system would think it was always an i686 one. I only need my system to think it is an x86_64 when I enter an x86_64 chroot, so that is much easier to create aliases to deal with. The trick was to create a /bin/bash32 file containing:

#!/bin/bash
linux32 /bin/bash -l "$@"

Then add bash32 to the list of shells in /etc/shells and use “chsh -s bash32” to start using it.

After using this setup for several weeks, the only issue I notice is that when using chroot, it will look for /bin/bash32 in the chroot and likely fail. That can be fixed by prefixing with the SHELL environmental variable pointing at an appropriate shell (more than likely /bin/bash). I am sure that creating a wrapper script to handle that would be easy but using chroots via the Arch devtools does not suffer from this problem so I have not looked into it further.

The Chakra Project is a “distrolet” based on Arch Linux and providing its own KDE packages (collectively called KDEmod). I really do not like KDE so I am only interested in how the install goes. I used QEMU with a 4GB image and 512MB RAM with the 2010-01-10 “Aesop” installer.

The installer is live CD based, so boots you into a nice looking desktop [01]. Starting the installation takes you to a graphical install system [02] with the prerequisite warning about being an alpha release and the issues it can cause your hamster. After reading some notes and agreeing to various EULAs [03], the install is all go.

Onto the preparation of your system. The language and time settings looked quite ugly [04], but I have suspicions that QEMU was running this quite slow and maybe this was an artefact. I found it good to know that despite the complexities of installing being hidden, there was options to go in deeper [05] if needed. Partitioning [06] was not particularly simple, but that is being reworked for the future.

The actual installation of packages [07] proceeds with a montage of screenshot to whet your appetite for your new install. Of course you probably have already seen what it looks like from the live CD… Then you create some new users [08] (although I do not know what exactly an “Administrator” is), enter the root password and install the bootloader. I have no idea what the “Configure System” item at the end of the installer sidebar does as after installing the bootloader I got a reboot dialog.

The booting system looks familiar [09] to any Arch Linux user. I had expected a graphical boot-up as I had heard something about it using Plymouth, but I guess that is for the future. The login screen indicates that the /etc/hosts file has issues with setting the hostname [10]. Other than that, I was left with a fully working KDE desktop with no obvious issues. Looking at some configuration files to see how well the automatic set-up went found some interesting points. The MODULES array in /etc/rc.conf both disables and enables the e1000 module [11]. Also, I noticed that kdm is started as a daemon rather than using the inittab method, which I guess is more in line with what Chakra wants to provide but I find that to be less flexible. The supplied pacman.conf has the repos listed in an interesting order [12] (I think [core] should at least come before the KDEmod repos).

Overall, the installer does its job despite a few rough edges. The install booted to the desktop with relatively few configuration issues that I could spot. Not bad for something labelled “alpha”. Is it the “Arch made easy” that is often touted on Distrowatch Weekly comments? Maybe. But with a distro like Arch, that is not necessarily a good thing.

Screenshot index:

[01] – Live CD Desktop
[02] – Installer start screen
[03] – EULAs
[04] – Language and timezone setup
[05] – Hidden “advanced” options
[06] – Partitioning
[07] – Package installation
[08] – User creation
[09] – Bootup
[10] – Login
[11] – /etc/rc.conf
[12] – /etc/pacman.conf