On 10/27/2009 10:43 PM, David Cantrell wrote: > On Tue, 27 Oct 2009, Steffen Maier wrote: >> On 10/27/2009 05:24 PM, Steffen Maier wrote: >>> On 10/27/2009 03:07 AM, David Cantrell wrote: >>>> diff --git a/storage/dasd.py b/storage/dasd.py >>>> new file mode 100644 >>>> index 0000000..f4df8ca >>>> --- /dev/null >>>> +++ b/storage/dasd.py >>>> @@ -0,0 +1,167 @@ >>>> + if intf: >>>> + rc = intf.messageWindow(title, msg, >>>> + custom_icon="error", type="yesno") >>>> + if rc == 0: >>>> + sys.exit(0) >> >> IIRC, with RHEL5 the user could just ignore unprepared DASDs and >> continue with whatever disks would then be left. Since some of the >> user-specified DASDs may already be prepared (or zFCP LUNs may be >> available), this seems like a valid and user-friendly choice to me. >> Could we change the exit into an early return from this method, so the >> user could happily continue with installation, if he does not want to >> touch the unprepared DASDs? > That becomes more difficult and I question whether or not it's even > necessary. The problem with returning here rather than exiting is > that storage code will then go and build its devicetree and > unformatted DASDs will raise exceptions. Of course, we could work > around that with a return value from startup() that then gets handed > to the devicetree building so we know to ignore unformatted DASDs (or > some other implementation, I don't care, but I really think that's > unnecessary. > > We give users plenty of ways to construct a DASD range they want to > use for the VM. The linuxrc.s390 rewrite you did and the conf file > that's passed in and the cio_ignore parameter and other kernel boot > parameters. By the time we actually get to where we can run > anaconda, is it not reasonable to say "we should be able to use all > DASDs that are visible"? I think policy should be the DASD range you > configure in stage 1 should be authoritative from stage 2's > perspective. If a user does not want to format any unformatted > DASDs, they need to edit the CMS conf file, kernel boot parameters, > or give different answers to linuxrc.s390 questions. > > And even if that's not the case, we're dealing with the scope of > installation here. So if there's going to be some weird case where a > user will want a DASD visible in Linux, but not have it run through > dasdfmt, I say that's best set up after anaconda installs and you > have a workable system. Oh, right, I forgot about having to ignore those DASDs then. What you say sounds reasonable and thinking of a future DASD dialog, where the user would only enable and prepare(! ;-)) the DASDs he really wants to use I also come the the conclusion that we can just leave the installer exit as you designed it. Steffen Linux on System z Development IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter Geschäftsführung: Erich Baier Sitz der Gesellschaft: Böblingen Registergericht: Amtsgericht Stuttgart, HRB 243294 _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
