Using built pc kernel snap

Is there anything that needs to be dont besides calling ‘snapcraft’ to build the pc-kernel snap? I am attempting to build a kernel snap based off the pc-kernel snap with just a couple drivers added during the build. But I am not able get the built kernel snap to work without any modification. The pc eventually loads into initramfs and is unresponsive to the keyboard.

Error messages on the console prior to loading to initramfs are.

mkdir: can’t create directory ‘/root/writable’ : Read only file system
mount: mounting tmpfs on ‘/root/run’ failed: No such file or directory
mount: mounting /tmpmnt_writable on ‘/root/writable’ failed: No such file or directory
/init: line 9: can’t create /root/etc/fstab: nonexistant directory
mkdir: can’t create directory ‘/root/writable’ : Read only file system
mount: mounting root/writable/sysetm-data/etc/systemd/system on /root/etc/systemd/system failed: No such file or directory
run-init: opening console: No such file or directory
Target filesystem doesn’t have requested /lib/system/systemd/
run-init: opening console: No such file or directory
run-init: opening console: No such file or directory
run-init: opening console: No such file or directory
run-init: opening console: No such file or directory
run-init: opening console: No such file or directory
No init found. Try passing init= bootarg.

I have used the repo git://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux-snap/+git/xenial on the pc branch without modifications and succesfully build a kernel snap, pc-kernel_4.4.0-79.100_amd64.snap. debootsrap requires running as root, could this be causing permissions issues in the snap when built?

In generating the core image I use the command sudo ubuntu-image -O bar_truck -c beta bar_truck.model --extra-snaps …/xenial/pc-kernel_4.4.0-79.100_amd64.snap with the json file:

{
“type”: “model”,
“series”: “16”,
“model”: “truck”,
“architecture”: “amd64”,
“gadget”: “pc”,
“kernel”: “pc-kernel”,
“authority-id”: “XXX”,
“brand-id”: “XXX”,
“timestamp”: “2017-06-10T15:06:08+00:00”
}

I’m not familiar with that repo, but I have had success building straight out of git://kernel.ubuntu.com/ubuntu/ubuntu-xenial.git . Have you taken a look at that?

1 Like

The pc-kernel snap is rather special, to support secure boot it needs to be signed by the ubuntu archive key (which requires a deb package and a build inside the ubuntu build infrastructure) this build is using the content of the linux-generic deb package.

If you look at the snapcraft.yaml in the tree you see it points to https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux-snap/+git/xenial/tree/ which contains a Makefile that simply extracts the binaries from the deb in the archive. Your added drivers wouldnt end up in there since nothing is actually built from source.

Try https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/xenial the snapcraft.yaml in there actually does a build from source.

1 Like

Am I able to build the pc-kernel locally at all then if I don’t have the archive key, or will secure boot just not be possible?

Will adding a driver require a new branch with the driver added directly to the kernel if the kernel snap is special? I was attempting to have the driver built as a separate part since it is from another repo and have it added to the system in the correct place after build. Which at least correctly placed the driver in the kernel snaps filesystem, but possibly not properly initialized as I can’t get the system to boot with or without it.

I attempted to use each of the repos suggested by kyrofa and ogra, when I attempted to use kernels built in this manner I had different results. When booting the partition labelled writable is not found, though it is found on my laptop when I attach the drive to a running Ubuntu system. This was with both a sata ssd and sd card.

That rings a bell actually: I was testing the kernel I built in VirtualBox, and I had the same thing happen. I ended up having to change my HD type from SATA to IDE in the VM’s settings before it would boot. @ogra do you have any idea what’s happening there?

the latter …

this is totally up to you, if you have a binary driver that you built and linked against the archive kernel i assume you could hack up the Makefile to simply copy it in place and call depmod to update modules.dep and go on using that kernel snap base … or you could build completely from source and modify the snapcraft.yaml in a way that it syncs your driver branch in before building…

this is most likely some module for the disk controller that is missing in the initrd …

@cratliff should take a look at the demo snapcraft.yaml at https://github.com/snapcore/snapcraft/blob/master/demos/96boards-kernel/snap/snapcraft.yaml … specifically at kernel-initrd-modules and kernel-initrd-firmware …

my guess is “ahci” is the module you want here…

I was able to get the kernel snap working with just a couple modifications to the snapcraft file. Thanks for the help ogra and kyrofa. In addition to ahci being added to the kernel-initrd-modules the squashfs module needed to be built and added to the kernel-initrd-modules.

Below is what the snapcraft.yaml file looks like now.

name: ubuntu-generic-kernel
version: 4.4.0
summary: The generic kernel for snappy
description: This is a generic snapped kernel, based off the xenial src and config
type: kernel

parts:
  kernel:
    plugin: kernel
    source: .
    source-type: git
    kdefconfig: ['--makefile=debian/snapcraft.mk', 'branch=master','flavour=generic', 'config']
    kconfigs:
      - CONFIG_LOCALVERSION="-xenial_generic"
      - CONFIG_DEBUG_INFO=n
      - CONFIG_SQUASHFS=m
    kernel-initrd-modules:
      - squashfs
      - ahci
    kernel-image-target: bzImage

Ah ha! Thank you for sharing!

@ogra why aren’t those included by default… ?

They are added at initrd build time to the pc-kernel snap we bild from binaries, but the kernel build from source starts from a completely generic initrd with no hardware related bits … your boad might not have an ahci contoller at all and your from-source build might need to be most minimal, so we dont enforce anything in the source kernel builds …

note that the split initrd impementation (where the kernel will ship a modules.img file and the core snap the actual initrd.img that we then merge into one while loading in the bootloader) will actually fix that.

I can add ‘ahci’ to the initrd, but why do you need ‘CONFIG_SQUASHFS=m’
since it’s already built-in?


CONFIG_SQUASHFS=y

CONFIG_SQUASHFS_FILE_CACHE is not set

CONFIG_SQUASHFS_FILE_DIRECT=y
CONFIG_SQUASHFS_DECOMP_SINGLE=y

CONFIG_SQUASHFS_DECOMP_MULTI is not set

CONFIG_SQUASHFS_DECOMP_MULTI_PERCPU is not set

CONFIG_SQUASHFS_XATTR=y
CONFIG_SQUASHFS_ZLIB=y
CONFIG_SQUASHFS_LZ4=y
CONFIG_SQUASHFS_LZO=y
CONFIG_SQUASHFS_XZ=y

1 Like

I think specifically in IoT you will have many boards using SD cards or USB based stroage where ahci would simply be useless, so i think the current behaviour is ok …

adding a more descriptive error message (and detection code) to the initrd that hints you to the fact like:

“no disk device could be found, does your kernel support the necessary controllers and filesystems ?”

would be a lot more helpful than: [quote=“cratliff, post:1, topic:993”] mkdir: can’t create directory ‘/root/writable’ : Read only file system [/quote]

but this is true in general for the ubuntu initrd across all installation variants :slight_smile:

You are right, I don’t need it.

I had an error at one point when building that that said squashfs could not be found when building initrd and included it in snapcraft.yaml to remove that error. I can’t reproduce it now, it may have been in a different repo or branch that I initially tried.