Thank you for confirming this.
What worries me here is that we silently expand the list of mandatory kernel features with this and not all involved parties (see @jdstrand response above) seem to be aligned on this.
Note that this is an experiment, this is not even in master yet. We originally had planned to use tmpfs and bind-mount farm but this approach is much more complex to correctly process and undo. Still, I’m also worried that 3.4 is something that we must work with officially. Last time I heard about 3.4 it was not a production kernel but a pre-production prototype but perhaps that was a different device. It would be good to have more formal specification of snapd kernel requirements so that problems like this could be avoided in the future.
What aboout the possible impact on application snaps here ? i.e. docker only supports running on top of it in a few certain versions, lxd does not support using it at all … will such mapping underneath the app snaps not break them too ?
Agreed. Something like GitHub - mer-hybris/mer-kernel-check: Scripts to check kernel CONFIG_ values used by Mer would be helpful or a snap check-kernel.
the snapcraft kernel plugin has such a feature AFAIK, it parses the config and makes sure all required options are set … @ppisati should be able to point to the code …
The automation and the checks are fine but a document that say “this is roughly what we require”, ideally present on the forum would be great to have.
And on that topic, we should also plan on how those requirements can change. Once 18.04 is around can we depend on something new?
How would 18.04 change anything if snapd stays as a rolling release cycle?
depends if you want to re-define the kernel requirements and how much you want to make it harder for (commercial) porters, a majority of boards out there will still use android based BSP kernel sources, which will still be 3.4 or 3.10 based (android only starts requiring 4.4 with oreo AFAIK and the majority of BSPs wont be based on that for a while)
Also: you’d introduce a hard-lock between the 18.04 base snap and the kernel snap (which is what we are just working hard to remove between gadget and kernel currently (see raspberry pi))
Thank you for the insight @ogra. If 18 is too soon for a more strict baseline kernel then maybe we can revisit this in 20. In either case I think that we must be able to move forward, let’s make our plans clear and everyone will align on that:
- snapd developers know what they can and cannot rely on
- kernel maintainers clearly know what is required
- product owners can choose the appropriate hardware and kernel
- products get predictable EOL or partial feature support
Actually this is a completely different discussion as this affects how long certain things are supported. The current state is that all kernels down to 3.10 (+ patches) are supported and snapd has a rolling release cycle with no option for anyone to diverge from it. If there are plans to change this there should be a discussion on a separate topic as this affects product cycles, support, possible enablements etc.
Do we know what those patches contain and what is the set of enabled configuration options?
Well, I thought that has been defined in plenty sprint discussions over the last year’s and there has always been agreement that overlayfs can not be used because of the tech reasons with porting, apparmor and also with app snaps like lxd. Like @jdstrand I’m rather surprised that this is suddenly considered an option again without even a discussion ( there would have been a good opportunity to discuss this topic (once again) at the NYC sprint with all affected parties involved).
Again, for clarification. I’m not proposing a wide-open overlayfs, just a very specifically scoped one that may be safe wrt apparmor (assuming the kernel supports it at all).
Check GitHub - canonical/sample-kernels: Sample kernels for system images
However note that these are only sample kernels and actual used kernels by customers may have diverged from this quite a bit.
This repository was horribly outdated last time I looked. Is this really maintained and representative?
It serves as a reference point for people who start looking at enabling snapd on devices. There is nowhere being mentioned that the patches are incomplete or outdated. It’s also referenced from our official Ubuntu Core documentation here.
If it is outdated we should either bring it back into sync with what is necessary or deprecate it.
I know they are incomplete because they don’t seem to contain any fixes that were made to the apparmor code. That is just an example but I’m looking for something authoritative and not another vague indirect specification of what is required.
As I understand this, this would still require all devices which have a kernel snap out there today to give a respin to have all necessary patches included, correct?
Then someone should definitely look into getting them up to date. I know that people having older kernels in their BSPs take these as reference points and consume patches from there.
I am not that much involved in that level of enablement. Maybe @ogra or @ondra can share some other references.
1 Like
well, the reference is still the README.md from the master tree of the above branch …
For my personal projects i usually use our linux-generic tree directly, but that is because I only enabled boards yet that are in the list of the ~500 supported boards this kernel can run on by default (by simply pointing to the right devicetree).
all commercial boards i have seen yet were either to new to be used by this kernel (based on what mainline supports at the given version) and using something around 3.4 or 3.10 (i.e. the 96boards devices …) for their BSP trees … @ppisati is really the person to talk about any other mandatory things than the sample-kernels stuff above but i think this is still our authoritative place (and i dont see why it would be outdated), it should use the apparmor patchsets as they are distributed with the 16.04.3 isos (which is our minimal base for this set AFAIK)