-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, 15 Apr 2010, Steffen Maier wrote:
So that looks like the quick hack solution: Before even showing the storage selection screen, check for unformatted DASDs and after user confirmation either format all unformatted or abort installation. However, with the storage selection screen we now get a selection UI for free. If this screen also showed unformatted DASDs (and I do not understand why it doesn't even though they are valid block devices), the user might select a set of DASDs, some of them formatted some of them maybe unformatted. Only on hitting next, we could perform the handling of unformatted DASDs, namely of those unformatted in the selected disk set. That would be so much more usable and doesn't seem like much more effort. What do you think?
The big driver for the way it works now was that before we had an individual confirmation dialog for each unformatted DASD, which just didn't work well when you had a lot of DASDs. Given that linuxrc.s390 provides DASD discovery and supports turning on DASDs by specific device ID or device ID ranges or just scanning, I viewed doing the same steps in anaconda somewhat redundant. By the time anaconda is running, we should be able to treat the list of DASDs we are seeing as what the user wants because they were able to restrict that list before we started anaconda. In an effort to keep things simple in the installer, looking for all unformatted DASDs at once and asking the user if they want to format them was the least invasive. What you're suggesting is to allow further DASD device specification in anaconda when we've already provided that in linuxrc.s390. I'm not really a big fan of having it in both places because it basically ends up being a duplication of code. If you want it to happen when anaconda is running, that's fine, but we should dump all the crap from linuxrc.s390 that looks for DASDs and handles the DASD= parameter. The policy I've been working under is that linuxrc.s390 is what allows users to specify the exact DASD range they want to use for installation. anaconda should treat that range as entirely usable and offer to format any and all unformatted DASDs before continuing installation.
On 04/14/2010 10:08 PM, David Cantrell wrote:On Wed, 14 Apr 2010, Hans de Goede wrote:Nack! This won't work as the dasd object currently is not a singleton. To make it a singleton using the same design pattern as iscsi / zfcp / fcoe add: # So that users can write DASD() to get the singleton instance def __call__(self): return self To the DASD class, and the following to the end of dasd.py: # Create DASD singleton DASD = DASD()Good catch, thanks a lot, Hans. I wouldn't have noticed even though we had the same issue recently with zfcp.py.Updated. New patch: diff --git a/iw/filter_gui.py b/iw/filter_gui.py index 64b8700..63c834e 100644 - --- a/iw/filter_gui.py +++ b/iw/filter_gui.py @@ -35,6 +35,7 @@ from flags import flags import storage.iscsi import storage.fcoe import storage.zfcp +import storage.dasd import gettext _ = lambda x: gettext.ldgettext("anaconda", x) @@ -550,8 +551,7 @@ class FilterWindow(InstallWindow): storage.iscsi.iscsi().startup(anaconda.intf) storage.fcoe.fcoe().startup(anaconda.intf) storage.zfcp.ZFCP().startup() - - # Note we do NOT call dasd.startup() here, that does not online drives, - - # but only checks if they need formatting. + storage.dasd.DASD().startup(anaconda.intf) disks = filter(udev_device_is_disk, udev_get_block_devices()) (singlepaths, mpaths, partitions) = identifyMultipaths(disks) diff --git a/storage/dasd.py b/storage/dasd.py index 591dde0..b69be35 100644 - --- a/storage/dasd.py +++ b/storage/dasd.py @@ -49,6 +49,9 @@ class DASD: self._maxFormatJobs = 0 self.started = False + def __call__(self): + return self + def startup(self, *args, **kwargs): """ Look for any unformatted DASDs in the system and offer the user the option for format them with dasdfmt or exit the installer. @@ -200,4 +203,7 @@ class DASD: return self._totalCylinders +# Create DASD singleton +DASD = DASD() + # vim:tw=78:ts=4:et:sw=4Steffen Linux on System z Development IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter Geschäftsführung: Dirk Wittkopp 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
- -- David Cantrell <dcantrell@xxxxxxxxxx>
Red Hat / Honolulu, HI -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkvHIJMACgkQ5hsjjIy1Vknt6wCfXyyg7J5A8CD00EDPV/L4N6mr GckAoL8BStYPQVu3lCxKOtCv53TVmPXA =he1m -----END PGP SIGNATURE-----
_______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
