I have a custom version of the pi-gadget snap (https://github.com/snapcore/pi-gadget) which is part of our Brand Store. Previously I have made change to the config files in the config directory and the changes took effect when I re-imaged my device. However if I make a change to one of the files in the config directory, and push a new build of the gadget snap to the store and release it, should these changes take effect on any devices that refresh to that latest revision? Or do the config files only get migrated on first boot?
Yes I did that and after a refresh it looked like the config.txt has all the required entries. Then the device did a scheduled reboot which I presume was for the config.txt changes to take effect. However the bad news is that the device failed to reboot. Maybe I didn’t do enough, I just added the update lines to the ubuntu-seed structure as follows:
bootloader: piboot
structure:
- name: ubuntu-seed
role: system-seed
filesystem: vfat
type: 0C
size: 1200M
update:
edition: 2
content:
- source: $kernel:dtbs/dtbs/broadcom/
target: /
- source: $kernel:dtbs/dtbs/overlays/
target: /overlays
- source: boot-assets/
target: /
- name: ubuntu-boot
role: system-boot
filesystem: vfat
type: 0C
# whats the appropriate size?I have returned to look at this problem again.
Would it be correct to say that unless my very first version of the gadget snap used in the image has a update:edition section then I cannot update the boot assets in the field after that. So for example having a device with a gadget snap in place without the update:edition lines cannot be expected to update correctly when there is a new version of the gadget snap with update:edition:2.
I am trying to figure out why after an update of the gadget snap from the store, then the subsequent reboot, the device now will not boot.
I’m pretty sure if you have no edition entry and add one with a new revision that is considered as “different” and the original implementation discussion mentions boot asset updates happen when a difference is detected…
I also think gadget updates do not necessarily trigger a reboot unless the edition has changed, so that indicates the update has worked, but failed to boot due to some incompatibility.
Did you actually only change config.txt, are you sure no other bootloader bits got updated during your rebuild?
Yes I am sure that only config.txt changed. I am building from a GitHub project and nothing else changed except the yaml files and one of the config files.
The gadget.yaml that I am using is from the pi-gadget snap arm64 branch. There are 4 defined structures: ubuntu-seed, ubuntu-boot, ubuntu-save and ubuntu-data. I put the update:edition lines at the end of the ubuntu-seed section only? So should I have put those lines at am outer level so the update applies to all structures?
Should I have been using the preserve keyword also? I am not.
This is my only change: ubuntu@build:~/GITHUB/epi-pi-gadget$ git diff gadget.yaml diff --git a/gadget.yaml b/gadget.yaml index 6570179…f595500 100644 — a/gadget.yaml +++ b/gadget.yaml @@ -15,6 +15,8 @@ volumes: target: /overlays - source: boot-assets/ target: /
-
update: -
edition: 2 - name: ubuntu-boot role: system-boot filesystem: vfat
I’m pretty sure your initial snapcraft.yaml above is fine (i.e. only adding it to the ubuntu-seed structure as you did)… i dont think building from a local git tree prevents you from getting updated stage packages (i.e. the bootloader binaries themselves) from the archive though… this is what i meant in my last paragraph above.
ok I understand and obviously that is very concerning for me.
I think I can rule that out by building a version of my gadget snap with whatever new updated snap packages are pulled in and using that version to image a new device. That could prove that everything else was ok and my problem was just with the updating/edition stuff.
Right, worst case you can just use unsquashfs the existing snap, change config.txt and add the edition entry and call snap pack in that dir
1 Like
I have built a version of my pi-gadget snap with just my change to the config file. So assuming it has all the latest bootloader binaries etc). I then prepared an image to include this version of epi-pi and then imaged a device with this image. It boots correctly and the config file change is as expected. So I think this means my previous problems were caused by the update:edition attempt.
1 Like
@mborzecki1 do you remember if the above is supposed to work (original gadget has no update edition entry, new gadget does) to update a gadgets boot assets ?
Yes, when no edition is specified, it’s value is implicitly 0. Note, that the edition number in new update must be higher than one in currently installed gadget.
1 Like
After the snap refresh which pulls down the updated gadget snap I can see that the config.txt is updated as expected. And I managed to capture sime of the system logs before the shudown:
episensor@episensor-e45f01e7e50c:~$ sudo journalctl --no-pager -l -u snapd Jan 19 09:22:47 episensor-e45f01e7e50c systemd[1]: Starting Snap Daemon… Jan 19 09:22:49 episensor-e45f01e7e50c snapd[2125]: overlord.go:271: Acquiring state lock file Jan 19 09:22:49 episensor-e45f01e7e50c snapd[2125]: overlord.go:276: Acquired state lock file Jan 19 09:22:50 episensor-e45f01e7e50c snapd[2125]: daemon.go:247: started snapd/2.61.1 (series 16) ubuntu-core/22 (arm64) linux/5.15.0-1044-raspi. Jan 19 09:22:50 episensor-e45f01e7e50c snapd[2125]: daemon.go:340: adjusting startup timeout by 1m20s (pessimistic estimate of 30s plus 5s per snap) Jan 19 09:22:50 episensor-e45f01e7e50c snapd[2125]: backends.go:58: AppArmor status: apparmor is enabled and all features are available (using snapd provided apparmor_parser) Jan 19 09:22:53 episensor-e45f01e7e50c snapd[2125]: devicemgr.go:338: save already mounted under /var/lib/snapd/save Jan 19 09:22:53 episensor-e45f01e7e50c systemd[1]: Started Snap Daemon. Jan 19 09:22:56 episensor-e45f01e7e50c snapd[2125]: hotplug.go:200: hotplug device add event ignored, enable experimental.hotplug Jan 19 09:22:56 episensor-e45f01e7e50c snapd[2125]: hotplug.go:200: hotplug device add event ignored, enable experimental.hotplug Jan 19 09:22:56 episensor-e45f01e7e50c snapd[2125]: hotplug.go:200: hotplug device add event ignored, enable experimental.hotplug Jan 19 09:22:56 episensor-e45f01e7e50c snapd[2125]: hotplug.go:200: hotplug device add event ignored, enable experimental.hotplug Jan 19 09:22:56 episensor-e45f01e7e50c snapd[2125]: hotplug.go:200: hotplug device add event ignored, enable experimental.hotplug Jan 19 09:22:56 episensor-e45f01e7e50c snapd[2125]: hotplug.go:200: hotplug device add event ignored, enable experimental.hotplug Jan 19 09:53:10 episensor-e45f01e7e50c snapd[2125]: access.go:60: polkit error: The name org.freedesktop.PolicyKit1 was not provided by any .service files Jan 19 09:53:45 episensor-e45f01e7e50c snapd[2125]: daemon.go:519: gracefully waiting for running hooks Jan 19 09:53:45 episensor-e45f01e7e50c snapd[2125]: daemon.go:521: done waiting for running hooks Jan 19 09:53:47 episensor-e45f01e7e50c snapd[2125]: overlord.go:515: Released state lock file Jan 19 09:53:48 episensor-e45f01e7e50c snapd[2125]: daemon.go:644: Waiting for system reboot
Just a thought, could I use the preserve files keyword to exclude everything except config.txt and see if that helps?
I think we have found at least part of our problem. After the snap refresh the os_prefix file is blank in the new config.txt. So that probably explains how after a shutdown my device no longer boots?
I have read that there is a snap prepare-image step but does this only apply to newly imaged devices? How is it supposed to work when the config.txt changes as a part of a refresh? What could we be doing wrong?
As a conclusion, it seems that it is not possible to achieve this, that is updating config.txt through a snap refresh.
If you overwrite the full config.txt you also overwrite os_prefix, that must point to the currently active kernel, for instance. As it would be difficult to match what is put in the new config.txt with the kernel in each active device, updating directly via the gadget is not really an option.
1 Like
You might be able to use a post-refresh hook to sed through the file though… to apppend to it or change values.
1 Like