In a recent work-related conversation, Matthew Wilcox pointed out that EFI partitions are mountable on Linux and many distributions keep ia64 system partitions mounted at /boot/efi by default, but Debian does not. Since that behavior is mostly my fault, I recounted the history by way of explaining why it worked that way... and on suggestion from Martin Pool am repeating it here to document all this for posterity.

When we were making ia64 bootstrap decisions, the default bootloader on i386 was lilo, and the closest example to what we needed for ia64 in Debian was powerpc. This is because systems using EFI only understand FAT partitions by default, and thus need a FAT partition somewhere that the firmware can read from... often the first partition on the first disk. The Debian model for handling such things at the time seemed to be to craft a command to hook from kernel package postinst scripts that did the heavy lifting in association with a config file. What went on behind the curtain wasn't something to bother the user with on an average day if you could avoid it cleanly.

Some bootloaders know how to read a config file from /boot directly, and we started out thinking we'd use elilo that way, but it was hard to match up paths/naming in EFI to what they would look like under Linux. It was also clear to me that most ia64 systems were going to have large system partitions so there'd be plenty of space. So we punted and copy the elilo executable, config file, and any kernels or initrd files referenced in the config to the system partition.

I also thought the default location other distributions had chosen for mounting the EFI partition once the kernel was up, /boot/efi, was pretty ugly, but I couldn't think of anything better. The problem is that the standard says you need an \efi\"whatever" directory as the root of your content in the system partition, so mounting the partition at /boot/efi yields paths like /boot/efi/efi/debian. Some distributions didn't adhere to the standard at first, and so didn't see the ugliness until they started to comply... but I was on a team at HP making disk partitioning and content decisions that caused me to be very aware of these details.

Putting that all together, I decided there wasn't any point in having the EFI partition mounted by default... anyone who cared and wanted it mounted could just add a line to /etc/fstab to put it wherever they wanted. If I were doing it again today, I'd have an entry in /fstab marked noauto delivered during system installation. I haven't cared enough to tackle that change, though.

Sadly, there's one detail of the current implementation that can get in the way of complete happiness. The Debian-specific 'elilo' script that runs in user space to manage the EFI boot partition contents based on the content of /etc/elilo.conf expects to have to mount the EFI partition, and exits with a complaint if the partition is already mounted. For typical users, this script only gets called during installation and from kernel package postinsts, and the actual elilo bootloader remains oblivious to all this. If other distros have picked up the Debian script, I'm not aware of it. So, you're no worse off mounting the EFI partition in Debian than with some other distro, you just get treated poorly if you try to use our elilo script while the partition is mounted.

Clearly, we could handle this better. If someone wants to offer up a patch to the elilo script that asks the user if it's OK to scribble in the already-mounted partition instead of doing a mount / scribble / unmount cycle in the presence of an existing mount, I'll be happy to include it in the Debian elilo package.

Meanwhile, a lot of us have switched from lilo to grub on our i386 systems, and I'd love for my ia64 systems to work more like my grub-equipped systems. But making a substantive change like teaching elilo to know where /boot is so that it can read a config file from there and do things more like grub, without symlinks, etc, has several issues. We'd need to get the right set of file systems supported from EFI/elilo, we'd need to address the naming issues, and we would require either user intervention on upgrade, or some clever automatic parsing and rewriting of the relevant config files.

I can think of other things that would be more rewarding to work on, so don't anyone hold their breath...