First, Scratchbox needs the compat VDSO mode enabled. This is done by echo 0 > /proc/sys/vm/vdso_enabled. Also, Qemu requires mmap_min_addr set to 4096. These can be set permanently by adding the following lines to /etc/sysctl.conf.

# scratchbox support
vm.vdso_enabled = 0
vm.mmap_min_addr = 4096

On my desktop, which is x86_64, compat VDSO can only be set with the vdso32=0 kernel command-line option. Also, the scratchbox installer script checks for i386 architecture. It needs to faked out like this: setarch i386 ./maemo-scratchbox-install_4.1.sh.

The biggest problem is that suspend and hibernate don’t work. Suspend seems to work but does not restore. Hibernate suceeds with the most recent kernel but that kernel does not boot reliably.

I hadn’t noticed that I wasn’t running at the ideal resolution, 1280×900. 1080×768 looked a little squished. I had to switch to the ‘intel’ driver for Xorg for the graphics to work at the ideal resolution.

I just installed the compiz compositing window manager. The flipping effect when changing desktops is a nice touch even though it is a little blurry and jumpy.I understand what people were talking about with the wobbly window effect.

The Mighty Mouse is not detected automatically by the Bluetooth system. I have to run ‘hidd –search’ and occasionally restart the hidd daemon. The scroll ball only works in one direction. Unfortunately, moving the scroll ball horizontally scrolls vertically.

It allows downloading the packages from the mirrors which can be faster and easier than getting the images and producing the images from them. It is also more useful to keep the package repository and then produce the images as needed. I know some people keep the images and then mount them to get the files.

One thing I noticed is that the the disc1 and DVD templates are much larger than they should be. The cause is the repodata directory in the images is different than the one on the mirrors. My guess is that the output of createrepo is not deterministic; the contents seem to have different ordering but the input packages are the same.

Unfortunately, the madwifi driver did not compile cleanly on the Fedora development kernel. First, the Fedora kernels are currently 2.6.18-rc4 but they are versioned as 2.6.17. There is code in the driver which detects 2.6.18 but that doesn’t work with the mislabelled version. Also, madwifi uses the config.h header which was replaced by autoconf.h but is finally deprecated in 2.6.18. I submitted a ticket with patch to get this fixed.

I wanted to install the kernel modules as RPMs instead of from source. livna.org has madwifi packages for FC5. With some patching, they are suitable for building with the kmod scheme. This involves building packages for each kernel release, variant, and architecture. I only build for the i686 standard variant. The command line looks like:

rpmbuild -ba --target=i686 --define "kversion 2.6.17-1.2586.fc6" --define 'kvariants ""' madwifi-kmod.spec

I have put the packages I built at my Fedora package directory. Installing the packages from the rpm command-line can be tricky because multiple versions are installed at once. Doing an upgrade will remove the version for an old kernel. Upgrading the module versions requires installing the new version for installed kernels and then removing the old versions. Yum is supposed to handle this.

Getting the wireless working once the module was installed was a snap. I used NetworkManager and it just worked. It detected the wireless network and switched to it when the Ethernet cable is removed. It prompts for the WPA password.

The install went smoothly. Fedora booted up without any problems. Lots of things just worked. The display was autodetected to the right size. The trackpad worked. The Fn key works as modifier. A few things didn’t work out of the box. The wireless card will require third-party drivers. The internal sound isn’t working. It sleeps but doesn’t resume. My Bluetooth Mighty Mouse works but only after restarting the hidd daemon.

First, I tried Fedora Core 5 DVD. The installer got to a spot where it recognized that the drive was partitioned with GPT and asked if it could reformat it. I have the suspicion that this would have invovled erasing the whole drive including Mac OS X. This bug in anaconda was fixed in rawhide so that anaconda fully handles GPT drives. My guess is that Windows doesn’t know anything about EFI or GPT and goes into a compability mode where it writes the MBR partition.

Next, I tried Fedora Rawhide. It had a bug where every key entered was duplicated. This made it impossible to use the installer. I found a bugzilla entry and did some searching and it seems to be a recent kernel bug. Hopefully, it wll be fixed soon and I can try again. I wasn’t able to use the FC5 boot CD kernel to load the rawhide installer.

Then, I tried Ubuntu. The LiveCD booted great. And the installer’s gparted understood the GPT partitions. But it didn’t have any way to create an LVM partition. After I rebooted, the MacBook won’t boot because it couldn’t find a bootable partition. Luckily, booting with Option held gave to the boot selection menu with the Macintosh HD and that allowed booting to Mac OS X. And the Startup Disk pane in System Preferences allowed changing the default boot disk back to Mac OS X.

I actually used svk for the spec files for the packages. It was very handy for synchronizing and merging changes between home and work using the repository at my ISP. My repository doesn’t allow public changes but you can work the same way with any Subversion repository.

Setup the mirror:

svk mirror http://znark.com/svn/repos //mirror/znark

Sync the mirror to the svk depot.

svk sync //mirror/znark

Copy the mirror to local directory

svk copy //mirror/znark/cpanbuild //cpanbuild

Checkout the local directory

svk co //cpanbuild
cd cpanbuild

Make some changes and commit:

svk ci

Push the changes to the repository:

svk push

At another location, or after somebody else has made changes, I can do:

svk sync //mirror/znark
svk pull

In the images/pxeboot directory of the distribution repository, there is vmlinuz kernel and initrd.img ramdisk image. Download those and put them in /boot. Then edit /boot/grub/grub.conf and add the following entry:

title Fedora Installer
    kernel /vmlinuz
    initrd /initrd.img

This assumes that you have a separate /boot partition. If not, add /boot to the paths.

Then, reboot your machine and select the “Fedora Installer” entry from the grub menu. Once the installer has booted, you can do a network or hard disk install or upgrade.