From: Bdale Garbee Date: Sun, 21 Nov 2004 07:01:00 +0000 (-0700) Subject: post X-Git-Url: https://git.gag.com/?p=web%2Fgag.com;a=commitdiff_plain;h=dcf9c0b1c6117acb926b0f3a3577484080af680c post --- diff --git a/bdale/blog/posts/elilo_in_Debian.mdwn b/bdale/blog/posts/elilo_in_Debian.mdwn new file mode 100644 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]]