core20
core20 copied to clipboard
snapcore
Drop consoleconf from the core snap
Drop consoleconf from the core snap
All production devices disable consoleconf, and thus it is dead weight.
Consoleconf is only used on dev-mode devices effectevely
Imho consoleconf should be a standalone snap, not part of core, and included on devmode models only.
-1. The fact that all current production devices disable consoleconf doesn't change that it is the supported way to take ownership of devices after they've been shipped and should be part of the core experience, not a separate snap.
"Dead weight" - what is it weighing on?
The issue is that they disable it incorrectly; it still is trigger on boot; and people have opened devices and connected serial console to a port on the motherboard to hack into the device.
No, taking ownership of the device after they've been shipped is not part of the core experience for those models, because devices in the field are operated by users who are not device owners and must to be able to become one.
So here is my stawman:
- remove consoleconf binaries from core20 snap
- ship consoleconf binaries (innert) in a consoleconf snap
- make the core snap tty1 script call into /snap/consoleconf/current if available
This way on core20 devices, where all snaps that are seeded are part of the model, one can unseed consoleconf and thus fully disable and remove consoleconf.
This way, default reference canonical models will have consoleconf seeded and will operate as normal.
And production devices, can choose to not ship consoleconf whats-so-ever, without any ability to trick core20 snap into launching consoleconf.
@ogra1 @kubiko @vorlonofportland @mvo5 what do you think?
sounds like an awesome idea (and in fact we were promised a snapped console-conf for core18 to be able to unseed it, but it fell off the prio list back then, which is why we need hacks to disable it today on core 16 and 18)
is it clear who is doing that console-conf snap ? i.e. removing it before the snap exists would create a feature gap indeed.
I will build split core20+consoleconf snaps, and will build two sample images with seeded/unseeded consoleconf for people to try out for a spin.
And only then will try to land this safely with feature flags, if we agree. (something like making core20 snap preffer stand-alone consoleconf, then built-in one, then not fail; such that publishing consoleconf / resigning model / dropping consoleconf from inside core20 can all be done out of order without breaking things)
Console-conf has been released as a snap starting from UC24. This will not be backported to anything before UC24. Closing this issue.
