IBM is signed up to deliver the code, test and provide feedback.

How is this different from RH BZ 432416 (Anaconda reboot after s390x install)?  With that patch, anaconda already reIPLs from the ccw device (dasd) containing the root file system.

(In reply to comment #6)
> How is this different from RH BZ 432416 (Anaconda reboot after s390x install)?
> With that patch, anaconda already reIPLs from the ccw device (dasd) containing
> the root file system.

Hi Brad,

this proposed implementation of reipl support in anaconda supports all types of reipl that are sensible as installation target, i.e. DASD and FCP, while RH BZ 432416 (the code of which seems to be in RHEL5.3) only supports DASD [1]. Also, we're discussing on how to best provide user feedback for those cases where an automatic reipl is not possible [2]. Such feedback was missing from 432416 but would be very helpful for the user [3].

Steffen

References:

[1]
https://www.redhat.com/archives/anaconda-devel-list/2008-July/msg00095.html:
<quote>
A less feature complete installer support for reipl has already been
done before by Brad Hinson, David Cantrell, and Jan Glauber:
https://bugzilla.redhat.com/show_bug.cgi?id=432416
referenced at the end of
http://kbase.redhat.com/faq/FAQ_49_12902
The code can already be found in anaconda.git.
However, this code does not support reipl from FCP SCSI and also misses
to check if the reipl configuration worked and do a shutdown instead of
reboot if it didn't work, to prevent an endless loop rebooting the
installation image over and over again.

One more detail: If reipl configuration (i.e. writing values into the
sysfs entries) fails, a Linux reboot will happen from the device it has
previously booted from (see /sys/firmware/ipl/). Such a failure in
configuration happens if the version of either the hardware or the
software (z/VM) does not support an automatic reipl from the requested
device, e.g. from FCP. In such a case, the manual ipl by the user after
a shutdown of the Linux install image still works perfectly and is the
way to go (as it used to be before there was reipl support in the
installer).
</quote>

[2]
On 09/12/2008 09:24 PM, David Cantrell wrote:
> I would prefer to make the s390 installation process appear visually as
> close to the other platforms as possible.  Right now, Reboot after
> installation is the default.  On the last screen in anaconda, the Next
> button changes to say 'Reboot' indicating that once the user clicks it,
> the system will reboot.  The final screen also explains the system will
> reboot and you should remove the installation media, if any.
>
> Here's my thoughts on what we should do for s390:
>
> 1) If reIPL succeeds and we are able to set that up properly, keep the
> screen as it is on other platforms.  The button will say Reboot.  We can
> probably filter the text a bit since there is no media that needs to be
> removed.
> 2) If the reIPL operation fails in anaconda, change the text of the
> final button to read Shutdown and change the text of the final screen to
> show the message you indicated above where the user will have to
> manually IPL the boot device.
> This requires modification to iw/congrats_gui.py and
> textw/complete_text.py a bit.  There's already some code in there to
> filter out messages if we are on s390.  What we want to do is change the
> text label for the button to read Reboot or Shutdown depending on
> whether or not we set up reipl successfully.

[3]
Donald A. Norman, The Design of Everyday Things, Basic Books, 2002, ISBN 978-0465067107.

Ok, thanks for clarifying.

Since we'll support FCP reipl, which has a dependency on firmware/hypervisor version, the reIPL patch should consider version info provided in /proc/service_levels, which is being added in this BZ for RHEL 5.4:

RH BZ 475570
[LTC 5.4 FEAT] Provide service levels of HW & Hypervisor in Linux [201753]
https://bugzilla.redhat.com/show_bug.cgi?id=475570

(In reply to comment #8)
> Since we'll support FCP reipl, which has a dependency on firmware/hypervisor
> version, the reIPL patch should consider version info provided in
> /proc/service_levels, which is being added in this BZ for RHEL 5.4:
>
> RH BZ 475570
> [LTC 5.4 FEAT] Provide service levels of HW & Hypervisor in Linux [201753]
> https://bugzilla.redhat.com/show_bug.cgi?id=475570

As far as I understood the kernel code for reipl it figures out itself whether the environment supports the reipl type requested by a user. In cases where the user asks for something not supported, the sysfs attribut just won't accept the write and keep its previous value. In our reipl support implementation for anaconda we check this by verifying if the value for each requested sysfs attribute can be read identically after writing. If not, reipl is not supported, otherwise everything is fine. In other words, we do handle the dependencies on firmware/hypervisor already.

I don't think we should duplicate the detection code which is already inside the reipl kernel code by checking for service levels in user space again. It might get out of sync. We'd have two places to maintain the same functionality.

Hi Red Hat, IBM has a working patch for a clean install, and Red Hat wants both clean install and an upgrade install option.  IBM is suggesting that Red Hat take the clean install code that works, and IBM create a new patch for the second request. Can you please provide feedback on whether or not you agree with this approach in light of the 01/26 code delivery date? Thanks.

Created attachment 330004 [details]
anaconda-11.1.2.168.reipl.patch

Per discussion with Jon Jarvis, Red Hat agrees with IBM's proposal: IBM is suggesting that Red Hat take the clean install code that works, and IBM create a new patch for the second request.

Created attachment 330619 [details]
anaconda-11.1.2.168.reipl.patch

Created attachment 331674 [details]
anaconda-11.1.2.168.reipl.patch



This patch has been successfully function tested in an environment with RHEL 5.3 RC2 (interactive/kickstart, TUI/GUI, install/upgrade, DASD/FCP, z/VM 5.2/z/VM 5.3).

In contrast to the first patch version, this one includes support for upgrade (besides fresh install).

In contrast to the second patch version, this one improves the adjustments to the user interface in both text and graphical mode as discussed with David Cantrell. Additionally, two small bugs have been fixed preventively which might have occured in some situations.

Please apply this patch instead of the previous ones.
Sorry for any inconvenience.
Thank you for your support.

* After integration of this feature, the following parts of the
installation guide should be updated: *

<quote src="RHEL 5.3 installation guide, part III, section 17.21. 'Installation Complete'" url="http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5.3/html/Installation_Guide/s1-complete-s390.html">
The installation program prompts you to prepare your system for reboot.

Once the installation is complete, you must IPL (boot) from either the
DASD or SCSI LUN where the /boot partition for Red Hat Enterprise
Linux has been installed.

...

For LPAR-based installations, the HMC console may be used to issue a
load command to the LPAR, specifying the particular DASD or SCSI LUN
and zFCP WWPN where the /boot partition is located.

...

Following IPLing the installed Red Hat Enterprise Linux OS, you may
log on to the system via ssh.
</quote>

* I suggest adapting it to the now existing automatic reboot as
follows: *

<suggestion>
In most cases, the installation program automatically reboots into the
installed system.

Known exceptions to this are installations, where the /boot partition
resides on an FCP device in environments with LPAR on a machine older
than z9 or with z/VM older than release 5.3. In such cases, the
installation program shows information from which device to do an IPL
(boot). Accept the shutdown option and after shutdown, IPL from either
the DASD or SCSI LUN where the /boot partition for Red Hat Enterprise
Linux has been installed.

...

For LPAR-based installations, the HMC console may be used to issue a
load command to the LPAR, specifying the particular DASD or FCP
adapter, SCSI LUN, and zFCP WWPN where the /boot partition is located.

...

Following the automatic reboot or the manual IPL of the installed Red
Hat Enterprise Linux OS, you may log on to the system via ssh.
</suggestion>

Thank you for your support!

Release note added. If any revisions are required, please set the 
"requires_release_notes" flag to "?" and edit the "Release Notes" field accordingly.
All revisions will be proofread by the Engineering Content Services team.

New Contents:
Don, Ryan, see comment 11 - an Installation Guide update is needed for this. Didn't have a good way to specify that so I set the relnote flag.

From a QA perspective, to limit scope and feature creep, I'd really prefer to see a reference implementation first in Fedora before considering this for 5.4 ... if all the pieces are already identified, can we establish a roadmap for getting this included and tested in Fedora first?

------- Comment From MAIER.com 2009-03-25 13:31 EDT-------
(In reply to comment #19)
> From a QA perspective, to limit scope and feature creep, I'd really prefer to
> see a reference implementation first in Fedora before considering this for 5.4
> ... if all the pieces are already identified, can we establish a roadmap for
> getting this included and tested in Fedora first?

Hi Brock,

this implementation done under RHEL 5.3 *is* the reference implementation since lacking Fedora on s390 this was our major software platform to develop and test this.
If you wish, we could provide you with an initrd and updates.img just as I did with my rewrite of the initial network configuration in linuxrc.s390 (see [1]). Then you could see yourself that it works perfectly and is a great improvement.

Anyway, we also did upstream development and it is already included in anaconda. Please see LTC Bug 48467 / RH bug 464180. As soon as the Fedora on s390 build has gotten far enough to start booting and installing, we will assure that reipl works in Fedora.

Please correct me if I'm wrong, from my point of view we already addressed everything.

Regards,
Steffen.

[1] LTC bug 50126 / RIT 242791, LTC Bug 50342 / RH bug 475346, LTC Bug 50343 / RH bug 475350, LTC Bug 50344 / RH bug 475345.

Hi Steffen,

I always appreciate and am thankful for your quality efforts, but I think we have a chicken-and-egg problem if we are not prioritizing new features through fedora ... our major technical road map discussions for the past two years have been about improving the engineering efficiencies of scale for s390x, and working new features through fedora is a cornerstone for that ... we had feature scope creep with specific items in 5.3 that were uncomfortable, without a fedora reference implementation (for example, LUKS feature pulled from fedora for 5.3), I'm concerned we may simply repeat history again with features that bypass the improvement process Red Hat and IBM have invested in ...

Brock

Quality Engineering Management has reviewed and declined this request.  You may
appeal this decision by reopening this request.

IBM would like to escalate this rejection.  Per discussion with John Jarvis, Red Hat agrees with IBM proposal: IBM is suggesting that Red Hat take the clean install code that works, and IBM crate a new patch for the second request.

Any discussion or agreement on which patch to take is contingent on the feature getting all of its ACKs and does not override it.  In this case I was pressed to give early feedback before the feature had gone through the full review process and this is the risk.

------- Comment From sglass.com 2009-05-04 11:39 EDT-------
This code is in Fedora for RHEL 6.  I don't understand how we could have two different bases of code in one Fedora release.  Also, this feature is an extension of already existing but functionally incomplete reipl support (for DASD only) in RHEL 5.3.  So can you please explain the comment of feature scope creep?

Hi Stephanie,

I was thinking of some examples of "feature creep" in previous RHEL5 issues, like:

1) firstboot packages for s390x
2) cio_ignore feature in generic.ins

In both cases, an originally small specific technical change was initially proposed, but later, after the initial technical change was accepted, the "feature creep" came in in the form of additional requirements ("moving target") needed to accommodate the general business case that developed after the planing phase and during the testing campaign itself ... a fedora "reference implementation" should bypass that danger, two specific examples of recent features to RHEL5 that were proposed in fedora, planned, implemented and tested in a reference form in fedora first, then manage ably brought into RHEL5 include:

* ext4 fs support
* LUKS support in installer

Regards,

Brock

------- Comment From mgrf.com 2009-05-05 09:48 EDT-------
Hello Red Hat, Hello Brook,

As I understand your cautiousness
here is the status for this features code

1.) full function implemented and tested on the target code base, which is RHEL5
=> there will be no "feature creep" since it is already done and good
functionality that only affects very few and well understood places in the
installer
=> not comparable to the two examples firstboot and cio_ignore
2.) same function with almost identical code base is upstream in Fedora
=> this is all that can currently be done

That is exactly what Red Hat wants to see isn't it?

Quality Engineering Management has reviewed and declined this request.  You may
appeal this decision by reopening this request.

(In reply to comment #12)

> Don, Ryan, see comment 11 - an Installation Guide update is needed for this.
> Didn't have a good way to specify that so I set the relnote flag.  

Denise, I've inserted the suggested changes into the Installation Guide; they will become visible the next time that we republish the guide.

> Denise, I've inserted the suggested changes into the Installation Guide; they
> will become visible the next time that we republish the guide.  

Sorry -- no they won't; this came to me from a list of "needs Release Notes", and I failed to notice the WONTFIX. I've reverted my changes.

------- Comment From  2011-02-22 04:30 EDT-------
We are reviewing this as a part of backlog bug clean up activity.
As per last comment closing this as WILL_NOT_FIX.
Please feel free to reopen once you have any valid update.

Thanks
Muni