[FEAT] Provide zfcpdump-infrastructure with Ubuntu 16.04

[bugproxy]

== 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

[dann frazier (dannf)]

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

[bugproxy (bugproxy)]

------- 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)]

------- 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.

[dann frazier (dannf)]

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.

[bugproxy (bugproxy)]

------- 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)]

------- 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 !

[Dimitri John Ledkov (xnox)]

/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.

[bugproxy (bugproxy)]

------- 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)]

------- 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.

[Dimitri John Ledkov (xnox)]

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.

[bugproxy (bugproxy)]

------- 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.

[bugproxy (bugproxy)]

------- 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

[Dimitri John Ledkov (xnox)]

https://wiki.ubuntu.com/XenialXerus/ReleaseNotes#IBM_z_Systems_and_LinuxONE_specific_known_issues

[Launchpad Janitor (janitor)]

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

[Dimitri John Ledkov (xnox)]

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

[Dimitri John Ledkov (xnox)]

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?

[Dimitri John Ledkov (xnox)]

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

[bugproxy (bugproxy)]

------- 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)]

------- 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 (fheimes)]

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

[Steve Langasek (vorlon)]

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!

[Dimitri John Ledkov (xnox)]

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

[Launchpad Janitor (janitor)]

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

[Brian Murray (brian-murray)]

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.

[bugproxy (bugproxy)]

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