RFC: handling kernel cmdline options in gadget snaps

[Oliver Grawert]

hi,

we are currently facing a problem of having hardcoded console= options
on the kernel commandline ... 

(grub images currently default to: "console=ttyS0 console=tty0" (the
first option applies to kernel while the second sets the output console
for userspace) while u-boot images default to whatever serial console
device an embedded board uses)

to change your console= option you theoretically would have to build
your own gadget snap just for that one option modified ... 
... or we would have one gadget snap per possible option in the store so
the user can pick the "amd64-serial-console.snap" for his serial snappy
project ... this would indeed make us end up with tons of identical
snaps that only have a single option changed ...

i would like us to find a way how we can set the console option
dynamically at image creation time for this case ... 
technically grub based images do not need a console= option set by
default (they will resort to tty0 which is fine for VM as well as for
real hardware) but you might want to use some x86 based embedded board
that only offers serial ports for debugging or logging in ... u-boot
images should default to whatever the HW requires. but while i do not
expect us to use a beaglebone for any graphical images (since it is
simply not designed for this), i expect that RPi2 users will likely want
to be able to use graphical consoles (and a boot splash etc) in case
they run some desktop or some media playback tool on their snappy
install.

while we technically could use "snappy config" to adjust this, this is
practically only possible after you booted ... so you would have to boot
blind to an invisible console to change the default setting ...

the only sane option i see is to add some option to ubuntu-device-flash
so this value can be modified at image creation time before the first
boot ... but this seems to be unwanted either (u-d-f already has a
plethora of options and slowly gets crowded with them)

since i don't see an easy path out of this dilemma, i was wondering if
anyone else has any good idea what we can do here ...

ciao
	oli