UC 20 pi-gadget questions

Hey guys.

Multiple questions about new gadget snap.

  1. As I mentioned here - Issues with custom pi-gadget for UC20 there is no splash screen shown. Is it supposed to work?

  2. –disable-console-conf does not work with uc 20 for ubuntu-image. If I remember correctly I should be able to disable it in the gadget snap? Can it be done?

  3. Gadget defaults: we have a bunch of settings we set up via this id - 99T7MUlRhtI3U0QFgl5mXXESAiSwt776 it’s the one for core snap. Should id of core 20 snap used on UC 20?

  4. Another question about defaults - we have settings set for network-manager in the gadget snap as well. Will they work correctly given that network-manager is installed in this new run mode?

  5. We had some scripts that installed memory limits to /etc/systemd/… How can this be done in UC 20?

  6. We need to disable power save for wifi on pi. Was done in a similar way by dropping files to writable partition /etc/udev… How to this now?

  7. While I can’t get the splash screen to work for now - a question for the future. On the first boot I was checking if /root/writable/system-data/var/lib/snapd/state.json exists. If it did not I would show a message that first boot initialization is being performed. How can I detect now that it’s in the install mode, and ideally in the state when it’s now running but still did not install our snaps?

As @ijohnson indicated in Disabling console-conf from gadget or core config option you can use:

defaults:
  system:
    service:
      console-conf:
        disable: true

You should be able to set those on system (similarly to console conf):

defaults:
  system:
    <your-settings-here>

Feel free to raise it in the forum If a particular setting you need is missing,

When were those scripts executed? Were part of a snap?

How was this achieved before? We can surely look into exposing more pi configuration knobs.

AFAIK you can list the snap as present only in a particular mode inside the model:

snaps:
   ...
   - name: mysnap-that-does-init
     modes: [ run ]

Alternatively, you can look at /proc/cmdline to check for snapd_recovery_mode=run

Thanks for taking the time to answer.

Regarding power saving, memory limits, and first boot message they all were in psplash/initrd/scripts/init-bottom.
Power savings were disabled like this

 - [ -e "$RULESDIR/10-wlan0-power.rules" ] || \
    echo "KERNEL==\"wlan0\", ACTION==\"add\", RUN+=\"/sbin/iw dev wlan0 set power_save off\"" > "$RULESDIR/10-wlan0-power.rules"

Memory limits were done similarly in the same scripts.

The first boot message was written there as well via psplash-write.
It was super simple to achieve before 20 with something like this.
[ -e “/root/writable/system-data/var/lib/snapd/state.json” ] ||
/bin/psplash-write “MSG …”

All snaps are installed in run mode and won’t run by default in install mode. We will be working on adding support for services/snaps that can execute hooks, etc. during install mode, but that work is not yet complete, so for now all of your snaps will be installed during run mode normally without any additional action.

A better thing to check for would be snap get system seed.loaded which will either not be present or will be false until all snaps have finished seeding. The state.json file will appear during install mode but it will not be useful to anything inside install mode since that state.json file is deleted and disappears and is re-created fresh during run mode. Additionally, the state.json file will appear far before any snap service has actually started, so you may have a gap between when the state.json file appears and when your actual snap service starts running (though this is device dependent).

AFAICT, this snippet is just run whenever there is a /dev/wlan0 device added to the system, but if I’m not mistaken you could also run this from userspace from a snap service that just calls the same iw command too, with a oneshot service that runs once on boot. Have you tried this at all?

I think that @waveform and @xnox are working (or will work on) psplash support for the uc20 pi gadgets at some point in the future, perhaps they can comment on the current status of that work or if there is some way to build this currently.

Got it. Did not try wlan related stuff. I think we added it pretty early in 16 days.

One more question - did anything change about how the device is supposed to be registered? I directly ported over the script to register the device from 16. Added it to hooks. It did not work though. Should I dig deeper into that or did something related to it change?

if you’re referring to the registration with a brand store, no that shouldn’t have changed. If you want to start a bug or new forum topic about issues you have with that and logs of the issue (sanitized since you wouldn’t want to include your api key, etc.) we can help you figure out what is going wrong there