cio_ignore blacklist is no longer active after installation

Bug #1571561 reported by bugproxy on 2016-04-18
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Release Notes for Ubuntu
Ubuntu on IBM z Systems
zipl-installer (Ubuntu)
Skipper Bug Screeners

Bug Description

Problem Description
I am installing in a LPAR environment with access to many devices. I want to restrict the access with a cio_ignore device blacklist and provide such a list via the parmfile.

While the blacklist is active during the installation itself, it is not propagated to the installation target: After IPLing the freshly installed system, it has full access to all devices of the LPAR as no cio_ignore blacklist is active.

== Comment: #3 - Thorsten Diehl <email address hidden> - 2016-04-15 09:14:43 ==
Dimitri, when fixing things for Bug 139866 - LP 1564475 and Bug 140369 - LP1570775, please consider also this issue here. Install.log will follow.

== Comment: #4 - Christoph Arenz <email address hidden> - 2016-04-15 10:15:22 ==
I currently don't have a test LPAR at hand, so I provide data from a z/VM guest, but the symptoms are the same.
I blacklisted devices explicitely, like so: cio_ignore=100-5ff
However, after IPLing the installed system, these DASDs are visible and no cio_ignore list is active.

I am not sure where the 'installation log' can be found, but suspect you mean the file /var/log/installer/syslog.
If you want another file attached, please let me know.

Default Comment by Bridge

tags: added: architecture-s39064 bugnameltc-140325 severity-medium targetmilestone-inin1610
Changed in ubuntu:
assignee: nobody → Skipper Bug Screeners (skipper-screen-team)
Dimitri John Ledkov (xnox) wrote :

The usually behaviour is to copy certain parameters to the installed system, things after --- (this way one can differentiate between install time only parameters, and things that should be copied to the installed system too). However cio_ignore is simply to lift and store with cio_ignore tool. Imho this is one more candidate for the zipl.conf generator request.

affects: ubuntu → zipl-installer (Ubuntu)
Changed in zipl-installer (Ubuntu):
status: New → Triaged
importance: Undecided → Medium
bugproxy (bugproxy) on 2016-04-20
tags: added: targetmilestone-inin16041
removed: targetmilestone-inin1610
Changed in ubuntu-release-notes:
status: New → In Progress
Dimitri John Ledkov (xnox) wrote :
Changed in ubuntu-release-notes:
status: In Progress → Fix Released
dann frazier (dannf) on 2016-04-26
Changed in ubuntu-z-systems:
status: New → Triaged
importance: Undecided → Medium
Frank Heimes (fheimes) on 2016-05-23
Changed in ubuntu-z-systems:
status: Triaged → Fix Released
status: Fix Released → Triaged
Dimitri John Ledkov (xnox) wrote :

This is trivial to develop, as soon as we have automated testing of the installer in HMC.

For that we need HMC remote API call to be available for Load from FTP source.

Please, release patch to HMC exposing Load from FTP source API endpoint.

Changed in zipl-installer (Ubuntu):
milestone: none → later

------- Comment From <email address hidden> 2016-12-14 08:13 EDT-------
Changed target to 17.04 after discussion with Canonical

tags: added: targetmilestone-inin1704
removed: targetmilestone-inin16041
bugproxy (bugproxy) wrote :

------- Comment From <email address hidden> 2017-10-16 08:05 EDT-------
Moved to 18.04. Will not make it in time for 17.10.... First the rereq, has to be provided mentionend within the bug

tags: added: targetmilestone-inin1804
removed: targetmilestone-inin1704
Frank Heimes (fheimes) wrote :

closed after discussing with IBM

Changed in ubuntu-z-systems:
status: Triaged → Invalid
Changed in zipl-installer (Ubuntu):
status: Triaged → Invalid
bugproxy (bugproxy) wrote :

------- Comment From <email address hidden> 2017-11-17 05:09 EDT-------
Bugzilla status -> closed, documented by Canonical

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

Other bug subscribers