On 10/27/2009 08:46 PM, David Cantrell wrote: > On Tue, 27 Oct 2009, Steffen Maier wrote: >> On 10/27/2009 03:07 AM, David Cantrell wrote: >> We should show the list of DASDs to be formatted to the user and not >> just how many. Otherwise he can hardly make a decision whether to > A string listing all of the /dev/disk/by-path/ entries for the unformatted > DASDs could be too large. The only thing I think is reasonable here is to > introduce a scrolling listbox and add the /dev/disk/by-path/ entries there. Having a scrolling listbox sounds perfect. >>> + >>> + rc = intf.messageWindow(title, msg, >>> + custom_icon="error", type="yesno") >>> + if rc == 0: >>> + sys.exit(0) >> >> I would like to see an else case here when there is no UI. As Hans >> already pointed out, silently low-level formatting DASDs which do not >> have any known format, is a bit hard. Suppose such DASD has an unknown >> format with important data on it. Then we should not silently format it >> and loose the data. A kickstart command as suggested by Hans sounds good. >> How was this case handled with RHEL5? > > I agree with Chris here, we can just make use of 'clearpart --initlabel' > rather than introducing a new kickstart command. Would this kill all potential partitions on DASDs that were already both low-level formatted as well as already having partitions? That would mean whenever the user had one or more DASDs yet to be low-level formatted, he would have to recreate all existing partitioning on other DASDs which had been in use and thus prepared before. How was this handled with RHEL5 in order not to introduce regressions? >>> + def _updateProgressWindow(self, data, callback_data=None): >>> + """ Reads progress output from dasdfmt and collects the >>> number of >>> + cylinders completed so the progress window can update. >>> + """ >>> + if not callback_data: >>> + return >>> + >>> + if data == '\n': >>> + # each newline we see in this output means one more >>> cylinder done >> >> Are you sure that dasdfmt only ever prints a newline if one cylinder has >> been formatted but in no other cases? If so, then this is OK. Otherwise >> I would have expected to parse self._progressBuffer for a regex or the >> like which matches one line of real progress output of dasdfmt. > > Yes, with the -P option (and without -v), a newline means another cylinder > has been formatted. Originally I was parsing self._progressBuffer, but > deemed > that unnecessary. In fact, the self._progressBuffer lines shouldn't > even be > there anymore, as well as the else block that appends to > self._progressBuffer. OK, that's cool. 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
