Bionic/Xenial minimal cloud image: failed to apply load kernel module

apport information

apport information

apport information

apport information

apport information

apport information

apport information

This bug is missing log files that will aid in diagnosing the problem. While running an Ubuntu kernel (not a mainline or third-party kernel) please enter the following command in a terminal window:

apport-collect 1888000

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

Apport info was collected and attached... moving to confirmed.

This might be the same problem as reported and fix in this earlier but: https://bugs.launchpad.net/ubuntu/+source/open-iscsi/+bug/1566468

Could someone check the disposition of ib_iser.ko in either linux-modules or linux-modules-extra.

From linux-modules-4.15.0-112-generic_4.15.0-112.113_amd64.deb :

drwxr-xr-x root/root 0 2020-07-09 19:13 ./lib/modules/4.15.0-112-generic/kernel/drivers/infiniband/ulp/
drwxr-xr-x root/root 0 2020-07-09 19:13 ./lib/modules/4.15.0-112-generic/kernel/drivers/infiniband/ulp/iser/
-rw-r--r-- root/root 75089 2020-07-09 19:13 ./lib/modules/4.15.0-112-generic/kernel/drivers/infiniband/ulp/iser/ib_iser.ko
drwxr-xr-x root/root 0 2020-07-09 19:13 ./lib/modules/4.15.0-112-generic/kernel/drivers/infiniband/ulp/isert/
-rw-r--r-- root/root 72401 2020-07-09 19:13 ./lib/modules/4.15.0-112-generic/kernel/drivers/infiniband/ulp/isert/ib_isert.ko

(Ignore comment #12, that was for the master kernel not -kvm)

To clarify: linux-modules-4.15.0-1069-kvm_4.15.0-1069.70_amd64.deb does *not* contain the ib_iser.ko module.

I don't think it was actually removed from that kernel recently though. Nothing has changed in that area as far as I know

This may not be a new problem. Running the test case against a bionic image from June shows similar behavior:

$ multipass launch 'https://cloud-images.ubuntu.com/minimal/releases/bionic/release-20200610/ubuntu-18.04-minimal-cloudimg-amd64.img'
Launched: main-gnu
$ multipass exec main-gnu -- sudo systemctl list-units --failed --no-legend
cloud-config.service loaded failed failed Apply the settings specified in cloud-config
systemd-modules-load.service loaded failed failed Load Kernel Modules
$ multipass exec main-gnu -- cat /etc/cloud/build.info
build_name: minimal
serial: 20200610

We have determined nothing has changed in those kernels from last cycle or this cycle. We think something changed in the CPC environment that might have triggered what we think might be an old bug. But we need to CPC help to identify the "last good kernel" and the "first bad kernel". Once we can isolate, we can have a more useful investigation

We have determined that ib_iser.ko is not in 4.15.0-1069-kvm but it wasn't there in the previous cycle's kernel and is not in the current proposed 4.15.0-1071.72 cycle either. I don't think we should try to make a change, re-spin, then ask the CPC team to test, especially since we never made the breaking-change in the first place (as far as we know at least). Once we know what changed we can make the right choice.

Hopefully this is a reasonable approach

Thanks for the review, it turns out that this failure has always been present.

Going back to the Bionic 20180705 and Xenial 20180705, which were the first releases of minimal, also showed that the system "Failed to find module 'ib_iser'".

Is this something that could be fixed in order to prevent us from shipping with failed systemd units?

This is a bug in the open-iscsi package in xenial and bionic. That package installs this file: /lib/modules-load.d/open-iscsi.conf

Which contains the following:
iscsi_tcp
ib_iser

This causes systemd to always try and load the iscsi_tcp and ib_iser modules on boot. In eoan, the open-iscsi package doesn't do this; there's no /lib/modules-load.d/open-iscsi.conf file in the eoan cloud image. An update to xenial/bionic open-iscsi packages to match the behavior of eoan's open-iscsi package should resolve this I think.

Based on the update above, #17, I am adding the open-iscsi package task.

I think this is basically a duplicate of LP: #1833586. SRUing the fix was discussed there but vorlon was not positive about it, see comment #6 there.

I'm marking the open-iscsi task as Triaged, but if stick with Steve's opinion then this is to be considered a Won't Fix.

Xenial has reached end of standard support.

Hi,
I'm coming by cleaning old open bugs to ensure nothing gets forgotten for too long and or clutters the view to the remaining issues.

This case here - as Paride outlined almost two years ago - is already covered and discussed in bug 1833586 . We won't/can't SRU it and there was no further input/discussion here.

Setting Bionic to Won't Fix - and from latter releases it is already fine.