Bug#689753: linux-image-3.5-trunk-amd64: Please support /boot being vfat, or another way of having the kernel on the EFI system partition
Package: src:linux
Version: 3.5.5-1~experimental.1
Severity: normal
Call me a masochist, but I've been using UEFI boot on systems new enough
to support it. For this, it makes sense to have the kernel and initrd
images on the EFI system partition.
It's not an absolute requirement. One could have grub on the system
partition, and have grub read the kernel off whatever filesystem it's on.
However, as far as I can tell, the direction the boot process is going
is for the kernel to be an EFI executable. No boot loader in the
oldschool sense, just something to select which kernel to run and pass a
command line.
To simply run the kernel as an EFI application, two requirements:
- The kernel image has to be compiled as an EFI executable. Recent
Debian kernel images are.
- The kernel image has to be on a file system EFI can read. That doesn't
necessarily mean the system partition, but it does mean vfat.
Now, in linux-image-* packages, the kernel image is simply a file in
/boot. If /boot is the EFI system partition, dpkg will fail to update
the package, because dpkg assumes file systems have hard link support.
When this issue came up back in 2008, it was decided to just accept this
dpkg limitation and officially require /boot to be a POSIX file system.
I suggest to revisit this decision in the context of UEFI boot.
How best to implement this depends on the preferred way of mounting the
system partition. Arguably, the system partition should be /boot, since
that's the point. In that case, one could ship the kernel image beneath
/lib in the package and copy it to /boot from postinst.
Another popular option is to have /boot on the root file system and the
system partition on /boot/efi. In that case, it would be fine to leave
the kernel image in the package as it is now, but the package should
offer to always keep copies of the kernel and the initrd in /boot/efi.
Reply to: