May I also say that I’m all up-to-date on all my machines and BIOS (because updates are infrequent).
Still I agree. Let’s work on the reference platforms and see what does it mean to update gadget snaps there. I also wonder if we support UEFI boot on amd64 (and soon arm64).
@ogra can you please tell us what lives in the pi2/3 gadget snap and what would be the correct way to determine that we need to rewrite some files / raw partitions and the correct sequence of doing that? Ideally we’d do the same for the dragonboard as well as (AFAIR) it has way more “interesting” partitions and other magic.
yes, the pi is completely boring regarding the setup, all files simply sit on the vfat partition, OTOH i dont see a reason to update the dragonboard bootloader files (i doubt qualcomm has even changed them since the board was released).
if we just want to have a target for a complex update exercise the dragonboard is definitely the right device though.
regarding the changes … the pi does all the HW initialization in the first stage bootloader blob and also ships additional features …
is a very good example where power management features were changed …
additionally the pi boot firmware also requires updating for major kernel version bumps and, given that the bootloader is actually the graphics driver, there can be driver related fixes too that you need to update for. specifically on the pi’s the bootloader blob files are way more than a BIOS, while on other boards the BIOS comparison is actually true. in general, the update process here is simply “copy”.
for UEFI we actually ship all bits and pieces from the fwupdate setup we also use on the normal ubuntu images, the process there should be identical and is AFAIK actually used on the dell gateways (which also use secureboot)
so how about we provide an opt-in upgrade feature for bootloader bits …
i.e. the feature is there by default but you need to explicitly enable it through a core setting, via a snap command or through a gadget setting. that leaves us the wiggle room to actually warn about the risks with power outages etc when the user enables it on a device that does not have it by default and gives vendors the ability to turn it on by default via a gadget setting on images for devices they know will be always on and never suffer from potential power loss.
this still doesnt bring us rollback but sounds like it would cause the least surprises for all sides.
Yes, having a setting inside the gadget which allows the publisher to explicitly state updating of resources is intended in that particular gadget seems like a good idea.
Adding an additional comment here for posterity and searchability since AIUI this is being worked on with priority.
I’m told that this topic is what is preventing ARM kernels like the pi2-kernel snap from getting updates to the stable channel. Obviously, this is not great because users of those kernels aren’t getting security updates or bug fixes. One bug that is fixed in recent kernels but broken in the pi2-kernel in the stable channel is that AppArmor complain mode (what we use with devmode) doesn’t always work correctly. This manifested itself with apt-secure not working properly within the classic snap. See https://bugs.launchpad.net/snappy/+bug/1670475/comments/13 for details.
I am wondering whether grub.cfg would be updated as part of this. What would happen to, say, custom modifications to the kernel command line? I think that a mechanism like the one in classic images, where you have scripts in /etc/grub.d/ that are run after upgrading grub should be in place so custom modifications can take place after gadget snap updates.
In the meanwhile, what options do I have to update the kernel in my raspi3 with Ubuntu core? Make and installation from scratch using the daily version as @ogra suggested?
I’d like to know if there are any updates about this issue with the release of Ubuntu Core 18. Is it possible to update the kernel in the RPi 3 or is it still impossible to do it? Are @ogra’s images able to do so?
Thanks for your replies. I deeply appreciate your help.
the kernel could always be updated, but parts of the gadget snap still can not, if a gadget gets updated only the meta-data will be updated … i.e. gadget.yaml and snapcraft.yaml, so you can add/remove config defaults and interfaces, but you will i.e. not be able to update the u-boot binary or the Pi bootloader firmware, snapd will ignore these bits.
