Fedora 17 will be shipping next week. It's got a bunch of
new features, none of which I contributed to in the slightest. What I did work on was improving our support for installation on x86 Apple hardware. There's still a few shortcomings in this so it's not an announced or supported feature, but it's sufficient progress that it's worth writing about.
There's a few ways that Apple platforms differs from normal PC hardware. The first is that Apples are very much intended to be EFI first and BIOS second, while that's still not really true for commodity PC hardware. Apple launched Boot Camp shortly after they started shipping x86 Macs (and shortly after I'd
got Ubuntu running on one for the first time[1]) but the focus of Boot Camp has always been to be good enough to boot Windows and not much else[2]. The other is the integration with the boot environment. You can boot Linux easily enough by setting the standard EFI boot variables, but if you ever boot back into OS X it's easy to trigger deletion of those. There's then no straightforward way of resetting them, and you're left having to recover your installation.
The other difficult bit has been actually starting the installer at all. If you're happy to use BIOS emulation than this can be done without too much misery, but you're then left with dealing with Apple's custom synchronised GPT/MBR. More modern Macs will boot via the standard EFI mechanisms, but there's a range of problems that can be caused that way. Fedora 17 is the first Linux distribution to ship install media that will EFI boot a Mac when either written to optical media or a USB stick[3]. Put the install media in your system and then either select it in the OS X Startup Disk preferences menu and reboot, or reboot and hold down the alt key. In the latter case there'll be a nice Fedora logo. Click on it and it'll boot.
The biggest difference between Apple hardware and anyone else is that we'd normally put the bootloader in a FAT partition that's shared with any other installed operating systems. That does actually work on Apples, but then you run into the earlier point I mentioned. The Apple startup picker that you get by holding down the alt key doesn't pay any attention to the standard EFI boot variables, so it won't show a FAT partition merely because it's got an EFI bootloader on it. The same is true of the OS X Startup Disk preferences. The best way to get a drive to appear in the menu is to make it look like an OS X drive.
This was problematic in a few ways, due to the requirement for an OS X drive to be HFS+. The first was that we didn't have any support for that in our installer, so work had to be done there. The second was that the state of HFS+ was woefully poor in Linux[4]. Linux will refuse to write to an HFS+ filesystem if it hasn't been cleanly unmounted or fscked, and since we can't rely on everyone always shutting their machine down cleanly that means a working fsck.hfsplus. In theory we were shipping one of those. In practice, it reliably segfaulted on 64-bit systems[5]. So I had to package the latest version of Apple's code, and doing that involved dealing with the fact that Apple now use
blocks almost as much as Grub 2 uses nested functions, and that meant using Clang and that meant dealing with a bug where Clang segfaulted if it had been built with gcc 4.7[6], but finally once all of those yaks had been shaven we could trust our filesystem.
Of course, more problems existed. You can't just drop a bootloader onto an HFS+ partition and expect it to work. You need to write its inode value into the superblock. Trivial, except that if you do this from userspace then the kernel kindly overwrites your update when you unmount the disk and it updates the superblock. That required a mechanism for updating that data via the kernel, which meant
adding an ioctl. This would have been fine, except the OS X Startup Disk preference looks for a bootloader in a location other than where Fedora installs it. Changing our bootloader install path wasn't a great option, so the easiest thing to do was just to link them together. Except HFS+ doesn't really support hardlinks. When you hardlink something the original file gets moved into a magic directory in the filesystem root and the links are special files that refer to it. And it turns out that it's not actually the inode that the firmware wants when finding the bootloader, it's the catalogue ID, and these aren't the same when hardlinks are involved. So,
another kernel patch.
All that was left for the boot partition then was adding an icon and a drive label. We already had code for generating the icon, and the drive label
wasn't that difficult. Hurrah!
Ok, so we can construct a filesystem that (a) appears in the bootpicker, and (b) appears in the OS X Startup Disk preferences. We can even put a bootloader on it. This led to the next problem. The bootloader started without any trouble. But the bootloader couldn't read any files off the boot partition, including its configuration. This should have been obvious with hindsight - the problem was simply that grub legacy[7] doesn't support HFS+. Writing an HFS+ driver seemed like an excessive amount of work, especially since the firmware already supported reading HFS+, so instead I wrote a simple grub filesystem driver that
uses the UEFI interfaces to read files.
A working bootloader! One more problem there. grub looks in its startup directory to find its configuration file. We have two "copies" of grub hardlinked to each other, each looking in a different directory for configuration. Hardlinking the config files together worked fine, except that most tools that update config files have this irritating habit of writing to a temporary file and moving that over the original, thus breaking the hardlink. Easily solved by using a symlink instead, except that the UEFI filesystem semantics don't really support symlinks because UEFI only really envisaged using FAT. If you use Apple's UEFI HFS+ driver to open a symlink, you get a short file containing the target path of the symlink. Rather less than ideal, and
a rather gross hack to cope with it.
All set now, other than a bug in some older Mac firmware where
read would return BUFFER_TOO_SMALL without returning the real buffersize and the odd way that
Apple treat CDs. Oh, and a bug in Apple's Broadcom wifi driver that could
overwrite the kernel, and
case-sensitivity, something that obviously isn't something you often hit on UEFI when all you usually see is FAT.
Kernel-side, we had a couple of things. Obviously there the bugs I'd
mentioned in the past, but those had already been dealt with. New issues included the fact that we were frequently picking the wrong framebuffer address, especially on machines with multiple GPUs.
Fixed now, along with another issue where we'd sometimes get confused by models with
different GPU configurations. And at that point, most of the implementation work was done.
Of course, there was also the work of integrating this into the tools that we use to generate our install media, and I'd like to thank Will Woods, Brian Lane and Dennis Gilmore for the work they put into that, along with anyone I've forgotten. Tom Calloway handled getting the device label graphics generated right before deadline. A cast of thousands helped with testing.
So why did I mention shortcomings? First, this only works on machines with 64-bit firmware. Early 64-bit Apples still had 32-bit firmware. In theory we can support that case - in practice it's a moderate amount of writing, including some mildly awkward kernel code. But anything later than mid-2007 should have 64-bit firmware, so it's not a massive concern. Second, we seem to have fairly significant trouble with Radeon hardware on a lot of Macs. We
fixed one bug there, but something's still going wrong in setup and you'll frequently end up with a black screen. And thirdly, I'm sure there's some other machines that still don't work for (as yet) undetermined reasons.
With luck we'll get these things dealt with by Fedora 18. But even with these flaws, Fedora 17 will work fine on a lot of Apple hardware, and testing it is as simple as downloading and booting a live image. Bugs go in
the usual place.
[1] Note my charming belief that the Ubuntu installer would fully support this hardware via EFI in the near future. 6 years ago. It still doesn't.
[2] This can be fairly easily seen from little things like the name "Windows" being hardcoded into every UI that sees a Boot Camp drive.
[3] I cover this in more depth
here[4] To be fair, it mostly still is - there's plenty of work to be done there.
[5] Approximately nobody had noticed this, which is all kinds of unreassuring.
[6] Thanks to Kalev Lember for
dealing with that[7] Still the EFI bootloader in Fedora 17. We've already swapped Fedora 18 over to grub 2.
comments
Each instance (virtual machine) started from the same image is configured
identically. The same account and the same procedure will be used to
connect to it. If the machine image is public and if the instance is open
to the Internet, which is common when using commercial providers such as
The 
I was worried about having to learn hundreds of configuration options to
properly set up mailman, postfix and lighttpd on Debian Squeeze. Turned out,
that except for lighttpd it all works out of the box.
Crazy title, I know.
Over the past $WHILE, I ve found myself checking for the same things. Some of these are fit for inclusion into lintian it s self others, not so much.
Here s a rundown on what my lintian wrapper (tragically also called lintian and just higher up on my $PATH. I know it s a hack.)
Since I only use lintian on .changes files - it pre-processes for some information that is stuffed in the changes.
The first step is to get all the bugs that the package closes. It then takes these bugs, and queries the BTS to see what package they re filed against. If the bug is filed against a different bug then the package s source, it ll emit a warning. It has a greylist for stuff like WNPP . This will fail if something s filed against it s binary package rather then it s source :)
Next, the wrapper will get other info from the changes. It checks if the suite is in the blacklist ( UNRELEASED , and testing , (stable for me as well, since I don t usually deal with SRUs often)).
It ll also check for the changed-by and maintainer, ensuring they re the same. This will fail for co-maint d packages.
If you ve not guessed by now, this system relies on false-positives :)
Nextly, if there are .debs in the Files, it ll go through and check the control of each. It ll print out a stanza with the short-description inside a template, to see if the description works .
After that, it ll attempt to make HTTP requests to the Homepage (and eventually URLs in the description and VCS-Browse)
If the package has python in the source name anywhere, or in any of it s binary packages, it ll trigger 
As you can see, it s very (very) verbose, but i d rather cross stuff off a checklist then worry about something being off.
Anyway, it s a work in progress. Not even a serious one, at that. It s a bunch of hacks put together, so I can t really endorse anyone else using this stuff. If you feel crazy enough to do so, all the tools are found on my 
A few weeks ago, my sony VAIO type P that I have been using for the past 2 years have died.
I've now got my MacBook Air and back to being productive again. One thing is that I probably lost your mail since I recovered from my home directory backup from 5 May.
Not that I read mail all that often, but your mail will certainly be lost if you've sent me a mail in the meanwhile.
An offtopic post for an issue that I just ran into for the n-th time: after upgrading to Ubuntu Precise, my HP LaserJet 1018 stopped working again, the issue being that the printer firmware was not being uploaded to the printer properly. For posterity, (one) way to fix this is to uninstall the printer-driver-foo2zjs package, remove the printer itself from the list of printers, and then use HP utilities to set up the printer:
I'm doing a Kickstarter! The plan is to take 
I've just released version 0.13 of 