On Sun, 2014-01-12 at 21:16 +0100, Karsten Merker wrote: > On Sun, Jan 12, 2014 at 07:01:36PM +0000, Ian Campbell wrote: > > On Sun, 2014-01-12 at 19:24 +0100, Karsten Merker wrote: > > > On Sun, Jan 12, 2014 at 06:00:24PM +0000, Ben Hutchings wrote: > > > > On Sun, 2014-01-12 at 18:34 +0100, Karsten Merker wrote: > > > > > > > > The attached patch adds Raspberry Pi support to flash-kernel. > > > [SNIP] > > > > So the boot partition is mounted at /boot? Doesn't that make it > > > > impossible to install packaged kernels (as dpkg needs to create hard > > > > links)? > > > > > > Installing a kernel package (locally built using make-kpkg) with > > > a VFAT /boot does not show any problems here: > > > > The normal way of dealing with this is to not have the bootloader > > partition mounted on boot, this is described in flash-kernel via the > > Boot-Device field. I think this should be honoured for Rpi too. > > Rpi-ConfigTxt-Path would then be relative to this device. > > Having the vfat boot partition as /boot is the standard way in > Raspbian (Debian/armhf rebuild for the Pi/armv6, "official" OS > distribution for the Pi) and is described this way in all user > documentation for the Pi. This is also expected by other > software, in particular the firmware update mechanism, which > expects the firmware image to be at > /boot/bootcode.bin, as well as by the Raspberry Pi foundation's > kernel updates (which do not come as a Debian kernel package).
Then I'm not sure what the point of this change is. Unpackaged kernel updates, aside from being generally a Bad Thing, presumably won't automatically call flash-kernel. > Not mounting the vfat boot partition at /boot would of course be > technically possible, but nobody actually does that on a Pi > and it would pose several problems: > > - The firmware update mechanism would have to be changed. This is > outside the scope of Debian and as installing firmware updates > is something that happens rather frequently on the Pi, that > must work without problems. ln -s boot/bootcode.bin /boot/bootcode.bin ? > - All the Pi user documentation would have to be changed, which > is also outside the scope of Debian. > > - In case the vfat boot partition is not mounted at /boot, > the firmware cannot anymore directly boot the /boot/vmlinuz-* > and /boot/initrd.img-* files from the kernel package. > That would therefore require copying the files from /boot > to the actual vfat boot partition. > > As having the vfat boot partition mounted on /boot is the > actual default case, flash-kernel would have to handle this as > well. This means either special handling depending on whether > the vfat partition is at /boot or not, or generally copying the > kernel to the vfat partition under another name. This sounds fairly easy to do and a sensible way to handle the transition. > The latter > would in the case vfat-at-/boot result in having the kernel and > initrd twice on the already quite small system vfat partition, > which is a route I would like to avoid. > > All things taken together I think that we should simply > accept that the vfat boot partition gets mounted at /boot > on the Pi and use it this way. There is obvious precedent for systems with firmware that boots from a VFAT partition. On EFI systems, starting with ia64 around 10 years ago, GNU/Linux usually mounts the firmware-supported boot partition at /boot/efi rather than /boot. Ben. -- Ben Hutchings Quantity is no substitute for quality, but it's the only one we've got.
signature.asc
Description: This is a digitally signed message part
