Comment 19 for bug 1564475

Revision history for this message
bugproxy (bugproxy) wrote : Comment bridged from LTC Bugzilla

------- Comment From <email address hidden> 2016-04-15 05:15 EDT-------
(In reply to comment #25)
> @thorsten
>
> If I understand correctly cio_ignore command needs to be on the running
> instance that is about to crash, rather than on the re-exec kernel. Thus it

@Dimitri,
that's not correct. The LPAR kdump would also work fine, if the zipl.conf has NO cio_ignore statement, just the KDUMP_CMDLINE_APPEND= statement.

> needs to be computed and added to e.g. /etc/zipl.conf. At the moment we do
> not generate/update /etc/zipl.conf in an automated way, but the more I think
> about it the better it sounds to e.g. able to specify all crashdump
> parameters, computed cio_ignore, correct root= argument, and generate menu
> items for every installed ubuntu kernel (rather than just the last one), and
> recovery stanzas too. I'll open a wishlist bug about that.

That sounds reasonable.

> BTW, does it make sense to compute and use `cio_ignore -k -u` generated
> command line by default? on one hand kernel will use less memory, on the
> other hand `lszdev` will be quite empty and one will have a harder time to
> discover additional devices one can bring online.

Exactly, that is the conflict. From performance point of view, it is appreciable to have cio_ignore enabled, since an LPAR boot with thousands of devices takes a little bit longer. For our Test LPARs with many shared resources we prefer and recommend to have cio_ignore enabled. In a resonably set up customer environment the disadvantage of the more inconvenient device handling is more relevant than the benfits of cio_ignore. Feel free to hear other opinions on that topic, e.g. from your z Systems experts Frank and Christian ;-)
But for the KDUMP_CMDLINE_APPEND= statement is does NOT harm, and I recommend to add this automatically upon every restart of kdump-tools.service

> I have, for now, added things to https://wiki.ubuntu.com/S390X -> feel free
> to edit and/or improve that. And I will open a new bug report to get those
> updates into the Ubuntu Server Guide.

That reads good and is sufficient to close this bug. Thank you!