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. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121005220622.26164.63492.report...@antares.zumstrull.net
