pc-kernel.snap missing drivers necessary for Hyper-v

[Scott Moser]

In testing, I tried to get a cloud image going on azure, but the initramfs can't find the root device.

The needed modules are:
   hv_netvsc,hv_utils, hv_storvsc, hid_hyperv, hv_vmbus

There is a larger issue over all of the very small set of kernel modules included. There are currently 50 kernel modules included, 30 of which are for graphics devices, and many of those are not remotely current (r128.ko for example).

However, this bug is specifically asking for the block and network devices for hyper_v listed above.

[Scott Moser (smoser)]

I'm not sure if this is filed right, I know the source code that builds this is lp:pc-kernel-snap (https://code.launchpad.net/~snappy-dev/pc-kernel-snap/trunk), but did not see a way to file a bug against that.

[Oliver Grawert (ogra)]

yeah, there are sadly some package dependencies that pull in some modules, technically *only* modules to find the rootfs (controller, and possibly filesystems (but these are compiled in in the core kernels anyway)) should be included by default.

this will all be solved in the next-gen initrd where we will split out a separate modules img file and load the initrd in a two step process so the kernel snap can define them a bit more dynamic.

i will take care for the hyper_v bits but this needs a bit of code since we need to avoid having tehm by default in i.e. ARM images. i should have something in the daily builds from the edge channel for you before EOW.

i'm curious why nobody complained about this before the final GA release though, have azure images not been tested ?

[Oliver Grawert (ogra)]

two other things:

- what for do you need network drivers inside the initrd (we do not support any form of netboot yet in the code and once we will this will likely be via a specific netboot initrd) ?
i assume it is enough to have the storage ones included to find your rootfs (there is no initrd code at all in core that could do anything with networking anyway atm).

- filing all image related bugs against the snappy umbrella project is the right way :)

[Scott Moser (smoser)]

The initramfs with block devices only are fine.
But I'd like to point out in case that you're not aware, the only drivers you have are below. That is probably only going to work for kvm and probably not all the virtual devices it can present as root. I doubt almost any hardware system would boot.

   kernel/fs/nls/nls_iso8859-1.ko
   kernel/ubuntu/i915/i915_bpo.ko
   kernel/drivers/platform/x86/intel_ips.ko
   kernel/drivers/platform/x86/mxm-wmi.ko
   kernel/drivers/platform/x86/wmi.ko
   kernel/drivers/i2c/algos/i2c-algo-bit.ko
   kernel/drivers/scsi/virtio_scsi.ko
   kernel/drivers/char/agp/sis-agp.ko
   kernel/drivers/iommu/amd_iommu_v2.ko
   kernel/drivers/video/vgastate.ko
   kernel/drivers/video/fbdev/core/syscopyarea.ko
   kernel/drivers/video/fbdev/core/fb_sys_fops.ko
   kernel/drivers/video/fbdev/core/sysfillrect.ko
   kernel/drivers/video/fbdev/core/sysimgblt.ko
   kernel/drivers/video/fbdev/vga16fb.ko
   kernel/drivers/video/fbdev/sis/sisfb.ko
   kernel/drivers/mmc/card/mmc_block.ko
   kernel/drivers/mmc/host/sdhci.ko
   kernel/drivers/mmc/host/sdhci-acpi.ko
   kernel/drivers/mmc/host/sdhci-pci.ko
   kernel/drivers/gpu/drm/nouveau/nouveau.ko
   kernel/drivers/gpu/drm/i2c/sil164.ko
   kernel/drivers/gpu/drm/i2c/tda998x.ko
   kernel/drivers/gpu/drm/i2c/ch7006.ko
   kernel/drivers/gpu/drm/amd/amdkfd/amdkfd.ko
   kernel/drivers/gpu/drm/amd/amdgpu/amdgpu.ko
   kernel/drivers/gpu/drm/qxl/qxl.ko
   kernel/drivers/gpu/drm/r128/r128.ko
   kernel/drivers/gpu/drm/via/via.ko
   kernel/drivers/gpu/drm/gma500/gma500_gfx.ko
   kernel/drivers/gpu/drm/i810/i810.ko
   kernel/drivers/gpu/drm/radeon/radeon.ko
   kernel/drivers/gpu/drm/cirrus/cirrus.ko
   kernel/drivers/gpu/drm/vmwgfx/vmwgfx.ko
   kernel/drivers/gpu/drm/virtio/virtio-gpu.ko
   kernel/drivers/gpu/drm/vgem/vgem.ko
   kernel/drivers/gpu/drm/drm_kms_helper.ko
   kernel/drivers/gpu/drm/tdfx/tdfx.ko
   kernel/drivers/gpu/drm/udl/udl.ko
   kernel/drivers/gpu/drm/ttm/ttm.ko
   kernel/drivers/gpu/drm/mga/mga.ko
   kernel/drivers/gpu/drm/drm.ko
   kernel/drivers/gpu/drm/savage/savage.ko
   kernel/drivers/gpu/drm/i915/i915.ko
   kernel/drivers/gpu/drm/sis/sis.ko
   kernel/drivers/gpu/drm/ast/ast.ko
   kernel/drivers/ata/ahci.ko
   kernel/drivers/ata/libahci.ko
   kernel/drivers/acpi/video.ko
   kernel/drivers/usb/storage/usb-storage.ko

[Oliver Grawert (ogra)]

we explicitly seed usb-storage, ahci, virtio and all the emmc drivers, that should really cover most of the x86 based IoT SoCs out there.

the drm and framebuffer drivers should really not be there, thats the issue i mentioned above earlier.

[Michael Vogt (mvo)]

This got uploaded as https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+sourcepub/7175245/+listing-archive-extra - please note that as ogra suggested this includes only minimal support for booting (i.e. hv_storvsc, hv_vmbus). If this is not sufficient please let us know (I have no idea if hv_utils is needed or not for example).

[Ryan Harper (raharper)]

On Wed, Nov 30, 2016 at 3:53 AM, Michael Vogt <email address hidden>
wrote:

> This got uploaded as https://launchpad.net/~snappy-
> dev/+archive/ubuntu/image/+sourcepub/7175245/+listing-archive-extra -
> please note that as ogra suggested this includes only minimal support
> for booting (i.e. hv_storvsc, hv_vmbus). If this is not sufficient
> please let us know (I have no idea if hv_utils is needed or not for
> example).
>

I rebuilt a core snap earlier today, which included the above version of
the tools:

https://code.launchpad.net/~raharper/+snap/core/+build/12105
https://launchpadlibrarian.net/295583933/core_16.04.1_amd64.manifest

However, it's not clear to me that this resolves the issue of getting the
hv_* drivers
into the initramfs which is part of the kernel snap.

I downloaded the latest (edge) pc-kernel snap (_40.snap) and while it
contains the
some of the hv modules:

% find . -name 'hv*.ko'
./squashfs-root/modules/4.4.0-47-generic/kernel/drivers/net/hyperv/hv_netvsc.ko
./squashfs-root/modules/4.4.0-47-generic/kernel/drivers/scsi/hv_storvsc.ko
./squashfs-root/modules/4.4.0-47-generic/kernel/drivers/hv/hv_balloon.ko
./squashfs-root/modules/4.4.0-47-generic/kernel/drivers/hv/hv_utils.ko
./squashfs-root/modules/4.4.0-47-generic/kernel/drivers/hv/hv_vmbus.ko

The initramfs containes none of those.

 % xzcat -f squashfs-root/initrd.img | cpio -t | grep .ko$ | grep scsi
68251 blocks
lib/modules/4.4.0-47-generic/kernel/drivers/scsi/virtio_scsi.ko

--
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1639878
>
> Title:
> pc-kernel.snap missing drivers necessary for Hyper-v
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/snappy/+bug/1639878/+subscriptions
>

[Oliver Grawert (ogra)]

you need to rebuild the kernel snap, not the core snap (which adds the modules to the initrd)

[Oliver Grawert (ogra)]

there should be a new pc-kernel snap in the edge channel in a few mins now, including these modules, sorry for the delay

[Ryan Harper (raharper)]

% xzcat -f squashfs-root/initrd.img | cpio -t | grep .ko$ | grep scsi
68707 blocks
lib/modules/4.4.0-51-generic/kernel/drivers/scsi/hv_storvsc.ko
lib/modules/4.4.0-51-generic/kernel/drivers/scsi/scsi_transport_fc.ko
lib/modules/4.4.0-51-generic/kernel/drivers/scsi/virtio_scsi.ko

\o/

I'll pull together an image for Azure testing using the edge kernel.

What's the candence for when edge kernel would move to beta/stable?

On Thu, Dec 1, 2016 at 6:08 AM, Oliver Grawert <email address hidden> wrote:

> there should be a new pc-kernel snap in the edge channel in a few mins
> now, including these modules, sorry for the delay
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1639878
>
> Title:
> pc-kernel.snap missing drivers necessary for Hyper-v
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/snappy/+bug/1639878/+subscriptions
>

[Robert Collins (lifeless)]

Any pointers on how I can test this? (Since I'm brand new to the snappy tooling...)

[Oliver Grawert (ogra)]

in general to test an update from the edge channel for an installed snap:

sudo snap refresh --edge $snapname

in this case you can just refresh to the latest stable though, the kernel snap with the fix is long in the stable channel already.

[Oliver Grawert (ogra)]

oh ... and i forgot ... @ryan:

the official kernel snap follows exactly the SRU process of the linux-generic kernel deb.
snap and deb are released alongside, so if a new kernel hits -updates or -security there should be a new stable snap as well.

[Robert Collins (lifeless)]

@oliver - problem is, that I can't boot into http://releases.ubuntu.com/ubuntu-core/16/ubuntu-core-16-amd64.img.xz because its missing drivers - are there builds that include this patch already out there somewhere?

[Robert Collins (lifeless)]

mwhudson pointed me at http://people.canonical.com/~ogra/snappy/all-snaps/daily/current/ubuntu-core-16-amd64.img.xz which boots fine - it would be great to link those somewhere more discoverable.

[Mark Shuttleworth (sabdfl)]

We're also working on a hyper-v optimised kernel which will boot much
faster for virtual gadgets that know they are going to be on that
hypervisor.

Mark

[Oliver Grawert (ogra)]

@robert - foundations is working on producing proper dailies that will be provided on cdimage.ubuntu.com and we will also soon have a new stable image release with the updates included. note that the dailies above are built from the edge channel which i would not recommend for production use.

i have set up a daily-stable build now that includes the newer kernel (and a newer core snap) from the stable channel under http://people.canonical.com/~ogra/snappy/all-snaps/daily-stable/current/ubuntu-core-16-amd64.img.xz which should be fine for production use.