Red Hat Bugzilla – Bug 633398
[6.1 FEAT] Intuitive dump device configuration workflow and dialogue
Last modified: 2011-12-23 12:15:45 EST
1. Feature Overview:
Feature Id: 
a. Name of Feature: [6.1 FEAT] Intuitive dump device configuration workflow and dialogue
b. Feature Description
Distribution configuration tools need to provide a dialog to prepare I/O devices for dump, during
the installation and post-installation. The dialog needs to meet the following requirements: -
intuitive, i.e. follow the expectation of the user - guided, i.e. online help texts should be
available for each input field - undoable, i.e. customer should be able to correct mistakes.
Hello Red Hat,
please find detailed documentation and scripts in the following three attachments:
1st attachment: Distribution Installer Support for Linux on System z dump tools
2nd attachment: Example perl script showing mechanism to configure dump on DASD
3rd attachment: Example perl script showing mechanism to configure dump on SCSI
Maybe the section
Clear the disk of fs labels, lvm formatting, mdadm formatting, etc. This is
important to prevent the disk from being automatically used for something other
than as dump device.
tune2fs -L '' /dev/dasdd1
after setting the dump device online and before preparing the device for dumps in
http://kbase.redhat.com/faq/docs/DOC-9768 might also be helpful to prevent known issues. Otherwise
attachment 42258 [details] should take precedence.
Further details can be found in:
"Using the Dump Tools - SC33-8290-02"
and if necessary also in the sections on fdasd and zipl of
"Device Drivers, Features, and Commands - SC33-8289-04"
2. Feature Details:
Architectures: zSeries - 64 native,
Arch Specificity: purely arch specific code
Affects Kernel Modules: Field does not exist
Delivery Mechanism: LDP Deliverable
Request Type: Installer - Enhancement from Distributor
d. Upstream Acceptance: Field does not exist
Sponsor Priority P1
f. Severity: ship issue
IBM Confidential: No
Code Contribution: no
g. Component Version Target:---
3. Business Case
The customer will have a dump disk ready to use if any problem occurs without having troubles to
configure it, which will result on a better serviceability, and in result improve the customer
4. Primary contact at Red Hat:
John Jarvis firstname.lastname@example.org
5. Primary contacts at Partner:
Project Management Contact:
Hans-Georg Markgraf, email@example.com
Gonzalo Muelas Serrano, firstname.lastname@example.org
------- Comment From email@example.com 2010-10-04 11:24 EDT-------
Code Upstream Status: Pending
This feature needs to be implemented in Fedora first and then considered for
backport to RHEL. Given where the schedules are and the other work committed
to for 6.1, development management does not see this making it in time. Moving to the 6.2 planning list.
------- Comment From firstname.lastname@example.org 2010-12-13 12:15 EDT-------
Accept reject for R 6.1 - will request this for R 6.2 again
New and extended product functionality as well as new features for this component must be implemented by IBM and accepted upstream before consideration for a RHEL backport can be made. For your convenience, this bug has been cloned to the same component under Fedora, which serves as the upstream development area for RHEL.
Development Management has reviewed and declined this request. You may appeal
this decision by reopening this request.
Appeal this decision -> re-open this request
See comment #9. Bug #707034 exists to track the upstream contributions for this feature request.
The Installer is the value-added code from Red Hat.
- Red Hat have to maintain this differentiator for RHEL
- System z cannot take ownership for the installer
For sure System z will offer help like in the past.
If you want to track this via Fedora - fine but that makes no difference
Although its obvious I re-call
- it is very important that the installer get improved for our customers
------- Comment From email@example.com 2011-08-24 15:37 EDT-------
Per discussion with John
I assign this feature to the RHEL 6.3 tracking list
This also get discussed in Fedora via ticket 707034
The process of mirroring from/to Fedora is actually in discussion
1) assign this feature BZ to the Fedora ticket
when Fedora is resolved re-assign to R 6.3
2) create reverse mirror of the Fedora ticket and have parallel tracking
Just so we are clear, the Fedora version of this feature is waiting on IBM code contribution and activity and will make no progress without this. This 6.3 BZ is set as being dependent on the Fedora BZ and so this feature will make no progress without active IBM engagement on the Fedora BZ.
Created attachment 521851 [details]
RHEL 6 install description
------- Comment (attachment only) From firstname.lastname@example.org 2011-09-07 08:02 EDT-------
Created attachment 521852 [details]
perl sample script for DASD
------- Comment (attachment only) From email@example.com 2011-09-07 08:04 EDT-------
Created attachment 521853 [details]
perl sample script for SCSI
------- Comment (attachment only) From firstname.lastname@example.org 2011-09-07 08:05 EDT-------
Created attachment 522922 [details]
------- Comment on attachment From email@example.com 2011-09-13 08:48 EDT-------
Update for RHEL6
Created attachment 522923 [details]
------- Comment on attachment From firstname.lastname@example.org 2011-09-13 08:49 EDT-------
Update for RHEL6
These patches need to be posted in RHBZ 707034 for Fedora rather than in this BZ as this BZ is not being worked at all. All development work should be done in the Fedora BZ. This and all other s390x-specific installer feature requests will be closed on September 14 as they only seem to cause continued confusion. Please assure any links that need to be updated are updated before these are closed.
Closing as NOTABUG. This feature needs to be implemented in Fedora before it
will be consider for RHEL inclusion.
As per RH Bug 707034, firstboot has been implemented for z. Reopening this bug to pick back up the discussion of this feature.
We have to work this feature request on the Fedora side. See bug #707034. Marking this one as CLOSED UPSTREAM since Fedora constitutes the upstream for anaconda and firstboot development and we already have feature requests filed there.