Thank you, that clears it up quite a bit for me!
Assuming your image is setup to do a normal device-registration flow on first boot to obtain a serial assertion then that data (brand, model, serial) is the ID used for active device metrics.
That’s exactly the thing our image is not set up for right now – mainly because we don’t have the proper infrastructure for device-registration on our servers yet (small OSS project with currently one developer – me). I really should’ve left this extra tidbit from my initial draft in the post
Given a devices has no valid serial assertion: Does it count towards the store metric at all? If so, which help metric is used to differentiate devices (e.g. IP addresses which may be inherently error-prone, ofc)?
I’m not sure if that matters in this context, but there are two things to consider in our release flow regarding registration:
- We “pre-boot” the generated
ubuntu-image on a Raspberry Pi, because the initial boot and setup takes well over 10 minutes on a Pi 3B – I know that the main reason for this is out of Canonical’s direct control. During this boot, the screen shows our boot logo until
mir-kiosk is installed, a black screen afterwards, and we need to reboot once so that network-manager can take command of the ethernet interface. All not great first impressions, and most users are rather impatient when trying out new stuff (let alone they read “get a coffee during first boot, don’t cut power, takes some time” ).
- When they flash our pre-booted image and start it up, the Raspberry Pi does not have internet connectivity until they configure credentials for their home WiFi (or set the device to LAN access) through a setup WiFi provided by the Pi. I guess the
register-device hook will retry later when it fails due to missing connectivity at first boot, but I haven’t had the time to tinker with it anyway.