RFC: handling kernel cmdline options in gadget snaps

[Ben Howard]

What about making /etc/default/grub.d a writable path? Then a user would
simply need to provide a config with
GRUB_CMDLINE_LINUX_DEFAULT="console=tty1".

But I think that this highlights the need for providing a simple way for
users to populate the writable paths at build time. As I have been
building Cloud Images, its a PITA to populate the writable paths. I
think that having a "--writable <tarball>" option that takes <tarball>
and populates /writable with the contents could solve a lot of pain.
Having this feature would mean that instead of having to support the
never-ending whack-a-mole requirements of "--<whatever>", users could
use "--writable <tarball>".

~Ben

On 07/06/2015 09:56 AM, Oliver Grawert wrote:
> 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
>
>
>
>
> --
> Ben Howard
> utlemming at ubuntu.com
> GPG ID 0x5406A866
> --
>
>
> Ben Howard
> ben.howard at ubuntu.com
> Canonical
> GPG ID 0x5406A866

-- 


Ben Howard
ben.howard at canonical.com
Canonical
GPG ID 0x5406A866



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/snappy-devel/attachments/20150707/19bab776/attachment.pgp>