zfcpdump-kernels later than v4.9 fail to boot / fail to find initramfs

Bug #1722735 reported by Dimitri John Ledkov on 2017-10-11
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Ubuntu on IBM z Systems
Medium
bugproxy
zfcpdump-kernel (Ubuntu)
Undecided
Unassigned

Bug Description

Currently, zfcpdump-kernel in ubuntu is on-par with v4.9 sources, and it does successfully complete SCSI dump of Ubuntu 17.10 which itself uses v4.13.

Our kernel team has attempted to upgrade zfcpdump-kernel to v4.13 sources, however such a kernel fails to complete the SCSI dump. (see attached operating systems messages)

With v4.9 based zfcpdump-kernel the kernel dmesg are cleared very quickly, and zfcpdump programme starts executing from the zfcpdump initrd pretty much instantly.

You can check v4.13 build-log & package at https://launchpad.net/~canonical-kernel-team/+archive/ubuntu/bootstrap/+build/13538881

Direct URL to download the v4.13 zfcpdump-kernel is:
$ wget https://launchpad.net/~canonical-kernel-team/+archive/ubuntu/bootstrap/+build/13538881/+files/zfcpdump-kernel_4.13-0ubuntu1~rc2_s390x.deb
$ apt install ./zfcpdump-kernel_4.13-0ubuntu1~rc2_s390x.deb

After that use zipl to prepare a drive for a dump as usual, and perform the dump.

We have also tried v4.10 based on zesty (17.04) release, compiled with zesty toolchain, and similar failure was observed.

Are there any new measure that we should be taking to configure, compile, and successfully create a zfcpdump compatible kernel, based on upstream v4.10 or later kernels?

bugproxy (bugproxy) on 2017-10-11
tags: added: architecture-s39064 bugnameltc-159968 severity-high targetmilestone-inin1710
Frank Heimes (fheimes) on 2017-10-11
Changed in ubuntu-z-systems:
assignee: nobody → bugproxy (bugproxy)
importance: Undecided → Medium
Dimitri John Ledkov (xnox) wrote :

>> Please see
>> https://bugs.launchpad.net/ubuntu/+source/zfcpdump-kernel/+bug/1722735 which
>> has been requested for reverse-proxy.
>
> We looked into the report: It looks like the initramfs with the zfcpdump
> user space is not detected for some reason.

We believe this maybe a regression in the upstream kernel in v4.10 and later.
Exactly the same unchanged zfcpdump initrd is detected correctly by the v4.09 kernel.
Note that the zfcpdump initrd is shipped by s390-tools package, whilst the kernel image is shipped separately by the zfcpdump-kernel package. Therefore the initrd is good and is loadable by v4.09 kernel but not v4.10 kernel.
Or vice versa, v4.09 and earlier are more graceful and are loading the buggy zfcpdump initrd, but v4.10+ doesn't.

Could there be some config options, or configurations missing from the zfcpdump config?
We are using z13 mainframe - does kernel try to use hw accel compression? but the kernel or the LPAR are misconfigured?
Can you commit any kernel engineers to debug this further to find a root cause?

Dimitri John Ledkov (xnox) wrote :

CONFIG_BLK_DEV_RAM=y is missing, yet needed, as zipl generates root=/dev/ram0 kernel cmdline.

Dimitri John Ledkov (xnox) wrote :

Default Comment by Bridge

Dimitri John Ledkov (xnox) wrote :
tags: added: patch
Dimitri John Ledkov (xnox) wrote :

zfcpdump-kernel (4.13-0ubuntu1) artful; urgency=medium

  * [Config] enable CONFIG_DEBUG_FS=y (LP: #1719290)
  * [Config] enable CONFIG_BLK_DEV_RAM=y (LP: #1719290)
  * switch to 4.13 base
  * gbp.conf: fix tag format

 -- Andy Whitcroft <email address hidden> Thu, 12 Oct 2017 15:48:13 +0100

Changed in zfcpdump-kernel (Ubuntu):
status: New → Fix Released
Changed in ubuntu-z-systems:
status: New → Fix Released

------- Comment From <email address hidden> 2017-10-16 07:50 EDT-------
IBM Bugzilla status -> closed, Fix Released by Canonical

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers