--- /dev/null
+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...
+
+[[!tag tags/debian]]