Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   Debian Kernel (http://www.linux-archive.org/debian-kernel/)
-   -   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 (http://www.linux-archive.org/debian-kernel/709968-bug-689753-linux-image-3-5-trunk-amd64-please-support-boot-being-vfat-another-way-having-kernel-efi-system-partition.html)

Maik Zumstrull 10-05-2012 10:06 PM

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.


--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20121005220622.26164.63492.reportbug@antares.zumst rull.net">http://lists.debian.org/20121005220622.26164.63492.reportbug@antares.zumst rull.net

Ben Hutchings 10-06-2012 12:44 AM

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
 
On Sat, 2012-10-06 at 00:06 +0200, Maik Zumstrull wrote:
> 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.

No boot loader... just a boot loader? I suppose you're trying to say
that the EFI operating system removes much of the need for the GRUB
operating system. :-)

> 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.

There are at least 4 independent implementations of .deb kernel packages
(Debian linux source package, Ubuntu linux source package,
kernel-package and upstream 'make deb-dpkg'). All of these install
directly in /boot and all would need to be changed to support this.

> Another popular option is to have /boot on the root file system and the
> system partition on /boot/efi.

The use of /boot/efi is fairly well-established, and not just in Debian.

> 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.

Believe it or not, you can actually make the Debian packages install the
kernel image there already:

# /etc/kernel-img.conf
image_dest = /boot/efi
do_symlinks = no
no_symlinks = yes

However it will always be installed as vmlinuz (with older versions
named vmlinuz.~1~ etc). And the initramfs is another matter.

Ben.

--
Ben Hutchings
For every complex problem
there is a solution that is simple, neat, and wrong.


All times are GMT. The time now is 06:42 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.