[Raspbian-devel] Raspbian / Boot-Partition / Flash-Kernel

[peter green]

Karsten Merker wrote:
> Hello,
>
> I have tried to add support for the Raspberry Pi to the Debian
> flash-kernel package and stumbled over some issues which I would
> like to ask your opinion about.
>   
Ok

I've put a few people on CC for their opinions on this matter. I've also 
put raspbian-devel on cc so this is on the record.
> I had written a set of patches for flash-kernel (submitted to the
> BTS as #735092 and #735093) which implement a function to
> automatically adjust the kernel and initramfs entries in
> /boot/config.txt upon installation and removal of Debian kernel
> packages.  This should allow parallel installation of multiple
> kernel packages and easy removal of kernel packages while making
> sure that the system is always bootable.
>   
Thanks.

BTW does flash-kernel allow one to choose older versions of kernels 
nowadays? last I tangled with it it explicitly refused to allow me to 
choose a kernel version other than the newest one I had installed.
> While this works ok on installation and deinstallation of kernel
> packages, Ben Hutchings (Debian kernel package maintainer) has
> brought to my attention that I had overlooked the fact that while
> installation and removal work without problems, upgrades to a
> newer Debian revision of the same kernel package do not work due
> to dpkg not being able to create links on the VFAT /boot
> partition during the upgrade.
>   
The raspbian kernel packages ontain a workaround for this. Specifically 
I divert the files off the fat partition in preinst and undivert them in 
postinst. It's messy and dpkg still throws up some warnings but it works.
> General opinion of the people discussing my wishlist bug seems to
> be that having /boot on VFAT is not and probably will never be
> officially supported in Debian.  VFAT firmware partitions should
> be mounted into a subdirectory of /boot like it is done with
> /boot/efi for ia64 and amd64 EFI systems.  I would like to ask
> your opinion on the topic.  Would you perhaps be willing to
> change the Raspbian setup to something similar to
> /boot/efi for Jessie?
>   
Unfortunately this gets to the murky area where raspbian meets the 
raspberry pi foundation :/

When raspbian first started the kernel and firmware were not packaged at 
all. Later the raspberry pi foundation packaged their firmware and 
kernel (in the same package annoyingly) and used it in their images. At 
about the same time I started trying to build debian-based kernel packages.

I tried and failed to persude the raspberry pi foundation to change 
their practices regarding mountpoint for the boot partition at arround 
this time and I did not consider it practical push users of my kernel 
packages to use a different setup from everyone else hence I ended up 
divising the workarround mentioned above (which the raspberry pi 
foundation also ended up using in their kernel/firmware packages).
> This would of course also require changed paths in rpi-update,
> but from what I see in the rpi-sources, 
One would also have the consider users of the packaged firmware and how 
that would behave in the event of an update.

And one would need to consider how to support both layouts and/or how to 
migrate systems systems from the old layout to the new layout.
> this should be doable
> with just a change of the BOOT_PATH variable. This is a change
> that would need to be done upstream as rpi-update updates itself
> upon use and has removed my local changes during the self-update.
>   
I presume it wouldn't be too hard to change where the self-update 
feature grabs it's updates from at least during development of the new 
feature.
> To test possible migration paths I have done some
> experiments with mounting /dev/mmcblk0p1 on /boot/firmware
> instead of /boot and just symlinking everthing from
> /boot/firmware to /boot, but there seems to be
> one case which I have not been able to reliably reproduce where
> running rpi-update does not follow the symlinks but instead
> removes the symlink and replaces it with a file, giving the
> following result:
>
> -rw-r--r-- 1 root root   17824 Jan 25 18:49 bootcode.bin
> lrwxrwxrwx 1 root root      20 Jan 25 18:40 cmdline.txt -> firmware/cmdline.txt
> lrwxrwxrwx 1 root root      19 Jan 25 18:40 config.txt -> firmware/config.txt
> drwxr-xr-x 2 root root   16384 Jan  1  1970 firmware
> lrwxrwxrwx 1 root root      21 Jan 25 18:40 fixup_cd.dat -> firmware/fixup_cd.dat
> lrwxrwxrwx 1 root root      18 Jan 25 18:40 fixup.dat -> firmware/fixup.dat
> lrwxrwxrwx 1 root root      20 Jan 25 18:40 fixup_x.dat -> firmware/fixup_x.dat
> lrwxrwxrwx 1 root root      18 Jan 25 18:40 issue.txt -> firmware/issue.txt
> lrwxrwxrwx 1 root root      29 Jan 25 18:40 kernel_emergency.img -> firmware/kernel_emergency.img
> lrwxrwxrwx 1 root root      19 Jan 25 18:40 kernel.img -> firmware/kernel.img
> lrwxrwxrwx 1 root root      23 Jan 25 18:40 LICENSE.oracle -> firmware/LICENSE.oracle
> -rw-r--r-- 1 root root  480952 Jan 25 18:49 start_cd.elf
> -rw-r--r-- 1 root root 2514392 Jan 25 18:49 start.elf
> -rw-r--r-- 1 root root 3478216 Jan 25 18:49 start_x.elf
>
> where bootcode.bin, start_cd.elf, start.elf and start_x.elf had been
> symlinks to /boot/firmware beforehand. In other tests, following
> the symlinks has worked and I currently cannot pinpoint why the
> behaviour is sometimes different.
>   
I have no idea, I don't use rpi-update myself.
> I would very much appreciate your input on the whole topic.
>
> Kind regards,
> Karsten
>