Pc-kernel

Where does one find the kernel and snapcraft file for the kernel that is used in the generic X86 kernel snap (pc-kernel=18).

I would like to use it as a basis for a custom kernel but I am not having much luck finding it.

the ubuntu kernel trees ship a snapcraft.yaml inside, so cloning it you can just run snapcraft in the top-level of the checked out tree.

if you just want to use the ubuntu source as a base you can use an external snapcraft.yaml and adjust the source: and source-tag entries like:

If you use a completely foreign tree you want to make sure the correct config options are set, i tend to use a patch like:

with a kdefconfig: line like:

(take a look at override-pull: how the patch is applied) …

1 Like

Thanks for the response Oliver, I appreciate it. I had previously found all of your work and tried a lot of different combinations as well as kernels and builds and combinations from A LOT of other places on Github and the internet (I should have made that clear).

One of the problems with your repo and then just referencing the Ubunt kernel repos is that they are devoid of the snappy config parts you use in kdefconfig. So that’s confusing.

Ultimately Friday I did manage to get the Bionic kernel booting in Core 18 with the kernel snap I built.

If anyone else comes a long with this problem I found this to be especially helpful:

https://github.com/muthiahn/ant-kernel-n/blob/5a7af7fcc64f68cb260991a7372a7adb7e83c5b1/snapcraft.yaml

I find the board enablement section of the docs for Ubuntu Core to be pretty inadequate for DIY. But maybe that’s the point? Board enablement is a big ticket service item. :wink:

1 Like

kdefconfig is the option to use if you merge multiple configs, the configs patch is split into multiple parts because this is how the official reference kernel trees used to be and it goes hand in hand with the (outdated, but still relevant) documentation at:

if you dont use multiple config files because you added all the hard-required options to your defconfig manually you can indeed use kconfigflavour and just point to your boards defconfig.

keeping the configs separate it is simply easier to make sure all feature bits needed by Ubuntu Core userspace in the kernel are enabled and you can still keep the upstream board config untouched this way.

2 Likes

Then this is a documentation accessibility problem! Thanks for that link! It is very helpful. You should put a link to that directly on the Board Enablement page or incorporate a lot of that text directly in the docs. The link from Board Enablement takes you to like the 3.10 branch where the README is the default kernel one.

In general the Ubuntu Core documentation, the stuff you find with Google, DuckDuckGo, etc., is very light on details. It was my experience (take that for what you will) that I had to rely on Github searches A LOT to make the pictures clearer in my head about exactly what I needed to do.

It also (by examples alone) seems to be heavily weighted toward the ARM enablement side of things and less so toward the x86 side. Perhaps this is just a reflection of the market.

At any rate, thanks for that link!

it is less a reflection of the market than of architectural design …

the pc-kernel simply just works on the most x86 systems out of the box so there is usually no porting work needed.
it is using exactly the same “generic” config the ubuntu server and desktop kernels use …

on arm you often enough have vendor kernels that come with a gazillion of patches and extra knobs you need to push to make it boot (even our rapberry pi kernel, which is an officially supported kernel is using quite a few forward-ported patches from the rpi fundation that are not yet upstream)…

Ah, you’re right about the kernel/ hardware situation in the ARM space.

Thanks for the clarification!

Just a note to @degville when back that while a bit of work and probably needs to be queued behind other things more pressing right now, we should try to write an updated guide for building kernel snaps to prevent folks from running into the same problems here

3 Likes

Thanks Ian. Yes, I agree. It would be good to clearly document this process - I’ll add it to the list, try and build one myself, and create/share the doc.

1 Like

If you do this and want someone who was complaining about it to give feedback, feel free to ping me about it.

Thanks.