[FEAT] Provide zfcpdump-infrastructure with Ubuntu 16.04

Bug #1565841 reported by bugproxy on 2016-04-04
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Release Notes for Ubuntu
Undecided
Unassigned
Ubuntu on IBM z Systems
Critical
Unassigned
zfcpdump-kernel (Ubuntu)
High
Andy Whitcroft
Xenial
Medium
Andy Whitcroft
Yakkety
High
Andy Whitcroft

Bug Description

== SRU TEMPLATE ==

Impact: without this package in place z-series systems cannot use zfcdump to take crashdumps.

Test Case: install this package, confirm that zfcpdump is able to add the kernel to the dump disk. Crash the kernel to confirm a dump is taken.

Regression Potential: this is a new package and only used for this one specific purpose. There should be no regression potential.

Other Info: this has been tested previously in PPA by ~xnox, who is also able to test this when it is in -proposed.

===

== Comment: #0 - Heinz-Werner Seeck - 2016-04-04 10:59:10 ==
Please provide the zfcpdump infrastructure to Ubuntu 16.04 , to enhance RAS capabilities and better Service enablement

bugproxy (bugproxy) on 2016-04-04
tags: added: architecture-s39064 bugnameltc-139974 severity-high targetmilestone-inin1604
Changed in ubuntu:
assignee: nobody → Skipper Bug Screeners (skipper-screen-team)
Kevin W. Rudd (kevinr) on 2016-04-04
affects: ubuntu → s390-tools (Ubuntu)
dann frazier (dannf) wrote :

I believe this requires a separate kernel build in Ubuntu to function, is that correct?

Changed in s390-tools (Ubuntu):
assignee: Skipper Bug Screeners (skipper-screen-team) → Dimitri John Ledkov (xnox)

------- Comment From <email address hidden> 2016-04-05 02:59 EDT-------
(In reply to comment #6)
> I believe this requires a separate kernel build in Ubuntu to function, is
> that correct?

It would make sense because this helps to better control the memory footprint. AFAIK, and Michael should correct if I am wrong, the zfcpdump environment has 32MB of RAM available.

bugproxy (bugproxy) wrote :

------- Comment From <email address hidden> 2016-04-05 07:43 EDT-------
(In reply to comment #7)
> (In reply to comment #6)
> > I believe this requires a separate kernel build in Ubuntu to function, is
> > that correct?
>
> It would make sense because this helps to better control the memory
> footprint. AFAIK, and Michael should correct if I am wrong, the zfcpdump
> environment has 32MB of RAM available.

Almost correct: Since z196 we have 64 MB. Machines before had 32 MB.

On Tue, Apr 5, 2016 at 1:09 AM, bugproxy <email address hidden> wrote:
> ------- Comment From <email address hidden> 2016-04-05 02:59 EDT-------
> (In reply to comment #6)
>> I believe this requires a separate kernel build in Ubuntu to function, is
>> that correct?
>
> It would make sense because this helps to better control the memory
> footprint. AFAIK, and Michael should correct if I am wrong, the zfcpdump
> environment has 32MB of RAM available.

OK. I was just trying to figure out if we'd need kernel support
*before* we could use the bits in s390-tools. Sounds like it's not a
hard requirement, so I'll leave this bug as affecting s390-tools only.

------- Comment From <email address hidden> 2016-04-05 11:02 EDT-------
(In reply to comment #9)
> On Tue, Apr 5, 2016 at 1:09 AM, bugproxy <email address hidden> wrote:
> > (In reply to comment #6)
> >> I believe this requires a separate kernel build in Ubuntu to function, is
> >> that correct?
> >
> > It would make sense because this helps to better control the memory
> > footprint. AFAIK, and Michael should correct if I am wrong, the zfcpdump
> > environment has 32MB of RAM available.
>
> OK. I was just trying to figure out if we'd need kernel support
> *before* we could use the bits in s390-tools. Sounds like it's not a
> hard requirement, so I'll leave this bug as affecting s390-tools only.

It is not a hard requirement but the preferred solution.

bugproxy (bugproxy) wrote :

------- Comment From <email address hidden> 2016-04-07 06:19 EDT-------
Canonical, this is important RAS feature for fullfill service requests. Therefore I increased the severity from high-> ship issue... For your attention !

tags: added: severity-critical
removed: severity-high

/lib/s390-tools/zfcpdump/zfcpdump_part.rd

is already provided.

I'm not sure if that is the same as the required /lib/s390-tools/zfcpdump/zfcpdump.rd or not.

/lib/s390-tools/zfcpdump/zfcpdump.image is not created yet, but we are working with kernel team on it. The kernel for release has frozen however, thus this will come in as an SRU unless we can get that in via other means.

Changed in linux (Ubuntu Xenial):
assignee: nobody → Andy Whitcroft (apw)

------- Comment From <email address hidden> 2016-04-07 13:06 EDT-------
(In reply to comment #12)
> /lib/s390-tools/zfcpdump/zfcpdump_part.rd
>
> is already provided.
>
> I'm not sure if that is the same as the required
> /lib/s390-tools/zfcpdump/zfcpdump.rd or not.

I would assume that it is the correct one. It is built by s390-tools ("zfcpdump" directory) and contains the statically linked "zfcpdump_part" user space application.

bugproxy (bugproxy) wrote :

------- Comment From <email address hidden> 2016-04-07 13:19 EDT-------
(In reply to comment #12)
> > >> I believe this requires a separate kernel build in Ubuntu to function, is
> > >> that correct?
> > >
> > > It would make sense because this helps to better control the memory
> > > footprint. AFAIK, and Michael should correct if I am wrong, the zfcpdump
> > > environment has 32MB of RAM available.
> >
> > OK. I was just trying to figure out if we'd need kernel support
> > *before* we could use the bits in s390-tools. Sounds like it's not a
> > hard requirement, so I'll leave this bug as affecting s390-tools only.
>
> It is not a hard requirement but the preferred solution.

One problem is that the "zfcpdump_part.rd" initramfs from s390-tools only contains the "zfcpdump_part" executable that is used as init process. We don't include any kernel modules.

AFAIK your "generic" kernel has no built-in SCSI / ZFCP support. Therefore if you would like to use this kernel, you somehow had to include the kernel modules in the zfcpdump initramfs.

Right, we also understand that our generic kernel will (a) use more than available 32MB of ram (b) doesn't have the scsi/zfcp modules built in. Even if we built-in scsi/zfcp modules, we are guessing it will still be no good. Hence we really must get a zfcpdump.image building. At the moment we are debating to build it as a standalone source and binary package, based on the ubuntu linux-source package, which is only rebuild infrequently (e.g. once per ga) and not rebuild on avery kernel update, as any kernel base should be sufficient for zfcpdump. Does zfcdump.image must match the crashed kernel image? On Ubuntu one can have multiple kernels installed, and it's not possible to know which one is currently active one - or rather it's not possible to make sure that zfcdump.image on disk is a matching kernel as the currently running (crashed) standard kernel.

------- Comment From <email address hidden> 2016-04-08 04:13 EDT-------
(In reply to comment #15)
> Does zfcdump.image must match the crashed kernel
> image?

No, "zfcpdump.image" can be a different kernel version than the crashed kernel.

dann frazier (dannf) on 2016-04-08
Changed in ubuntu-z-systems:
importance: Undecided → Critical
bugproxy (bugproxy) wrote :

------- Comment From <email address hidden> 2016-04-15 02:59 EDT-------
Changed TargetMilestone from 16.04 -> 16.10. Will not make GA of 16.04

tags: added: targetmilestone-inin1610
removed: targetmilestone-inin1604
bugproxy (bugproxy) on 2016-04-20
tags: added: targetmilestone-inin16041
removed: targetmilestone-inin1610
Changed in ubuntu-release-notes:
status: New → In Progress
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in linux (Ubuntu Xenial):
status: New → Confirmed
Changed in linux (Ubuntu):
status: New → Confirmed
Changed in s390-tools (Ubuntu Xenial):
status: New → Confirmed
Changed in s390-tools (Ubuntu):
status: New → Confirmed
dann frazier (dannf) on 2016-04-26
Changed in ubuntu-z-systems:
status: New → Confirmed
summary: - Provide zfcpdump-infrastructure with Ubuntu 16.04
+ [FEAT] Provide zfcpdump-infrastructure with Ubuntu 16.04
Andy Whitcroft (apw) on 2016-07-04
Changed in linux (Ubuntu Yakkety):
status: Confirmed → In Progress
Dimitri John Ledkov (xnox) wrote :

zfcpdump-kernel (4.4-0ubuntu1) yakkety; urgency=low

  * zfcpdump kernel initial upload. (LP: #1565841)

 -- Andy Whitcroft <email address hidden> Wed, 10 Aug 2016 21:35:32 +0100

Changed in zfcpdump-kernel (Ubuntu Yakkety):
status: New → Fix Released
Changed in zfcpdump-kernel (Ubuntu Xenial):
importance: Undecided → Medium
milestone: none → xenial-updates
status: New → Confirmed
Changed in zfcpdump-kernel (Ubuntu Yakkety):
assignee: nobody → Andy Whitcroft (apw)
Changed in zfcpdump-kernel (Ubuntu Xenial):
assignee: nobody → Andy Whitcroft (apw)
no longer affects: linux (Ubuntu)
no longer affects: linux (Ubuntu Xenial)
no longer affects: linux (Ubuntu Yakkety)
Changed in s390-tools (Ubuntu Yakkety):
status: Confirmed → Fix Committed
Dimitri John Ledkov (xnox) wrote :

zfcpdump-kernel is available in yakkety, after installing that zfcpdump was performed successfully.

Outstanding task is to backport that to xenial.

@bugproxy / reporter - could you please test zfcpdumping with yakkety (16.10) release to make sure it meets your requirements?

Changed in s390-tools (Ubuntu Yakkety):
status: Fix Committed → Fix Released
Dimitri John Ledkov (xnox) wrote :

no changes to s390-tools package required in xenial. zfcpdup-kernel/xenial is the remaining outstanding task.

Changed in s390-tools (Ubuntu Xenial):
status: Confirmed → Fix Released

------- Comment From <email address hidden> 2016-10-20 07:03 EDT-------
Verification was successful on Yakkety/16.10!

0) # apt install zfcpdump-kernel
1) Adding of a SCSI/LUN device(with multipath)
2) Creating a partition on that SCSI/LUN device
3) Install the dump tool by using the "zipl -d /dev/mapper/<scsi-device-partition>"
4) Edit /etc/zipl.conf to add the following lines:
[scsidump]
dumpto=/dev/mapper/<scsi-device-partition>
5) Run "zipl scsidump"
6) Run dump using the following in the zVM-Console:
- "#cp set dumpdev portname <8-digit-of-wwpn_part1> <8-digit-of-wwpn_part2> lun <8-digit-of-lun_part1> <8-digit-of-lun_part2>
- #cp ipl <no-of-zfcp-adaptor> dump
7) Start system normal again
8) Get dump with "zgetdump /dev/mapper/<scsi-device-partition> > dump.elf"
9) Checking for a valid SCSI dump and printing the dump header:

# zgetdump -i /dev/mapper/mpatha-part1
General dump info:
Dump format........: elf
Version............: 1
UTS node name......: s8330024
UTS kernel release.: 4.8.0-26-generic
UTS kernel version.: #28-Ubuntu SMP Tue Oct 18 14:44:48 UTC 2016
System arch........: s390x (64 bit)
CPU count (online).: 1
Dump memory range..: 1024 MB
Memory map:
0000000000000000 - 000000003fffffff (1024 MB)

bugproxy (bugproxy) wrote :

------- Comment From <email address hidden> 2016-10-20 08:39 EDT-------
(In reply to comment #23)
> Verification was successful on Yakkety/16.10!

Very cool! A big "thank you" to Canonical and our test team!
Michael

Frank Heimes (frank-heimes) wrote :

https://launchpad.net/~canonical-kernel-team/+archive/ubuntu/bootstrap/+packages
has the zfcpdump-kernel proposed SRU for xenial
in case you want to test

Andy Whitcroft (apw) on 2016-10-27
description: updated
Changed in zfcpdump-kernel (Ubuntu Yakkety):
importance: Undecided → High
Changed in zfcpdump-kernel (Ubuntu):
importance: Undecided → High
Changed in zfcpdump-kernel (Ubuntu Xenial):
status: Confirmed → In Progress

Hello bugproxy, or anyone else affected,

Accepted zfcpdump-kernel into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/zfcpdump-kernel/4.4-0ubuntu0.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in zfcpdump-kernel (Ubuntu Xenial):
status: In Progress → Fix Committed
tags: added: verification-needed
Changed in ubuntu-z-systems:
status: Confirmed → Fix Committed
Dimitri John Ledkov (xnox) wrote :

Completed zfcpdump of xenial system, using zfcpdump kernel from xenial-proposed. Validated that the dump is correct/complete.

tags: added: verification-done
removed: verification-needed
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package zfcpdump-kernel - 4.4-0ubuntu0.1

---------------
zfcpdump-kernel (4.4-0ubuntu0.1) xenial; urgency=low

  * Backport to xenial. (LP: #1565841)

 -- Andy Whitcroft <email address hidden> Thu, 06 Oct 2016 16:18:40 +0100

Changed in zfcpdump-kernel (Ubuntu Xenial):
status: Fix Committed → Fix Released

The verification of the Stable Release Update for zfcpdump-kernel has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

Changed in ubuntu-z-systems:
status: Fix Committed → Fix Released

------- Comment From <email address hidden> 2017-01-11 03:36 EDT-------
IBM Bugzilla -> closed

no longer affects: s390-tools (Ubuntu)
no longer affects: s390-tools (Ubuntu Xenial)
no longer affects: s390-tools (Ubuntu Yakkety)
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers