post

diff --git a/bdale/blog/posts/elilo_in_Debian.mdwn b/bdale/blog/posts/elilo_in_Debian.mdwn
new file mode 100644 (file)
index 0000000..c3b1a14
--- /dev/null
+++ b/bdale/blog/posts/elilo_in_Debian.mdwn
@@ -0,0 +1,78 @@
+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]]