[Raspbian-devel] Raspbian / Boot-Partition / Flash-Kernel
peter green
plugwash at p10link.net
Sun Jan 26 15:42:18 UTC 2014
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
>
More information about the Raspbian-devel
mailing list