little reply to myself On 04/15/2010 05:36 PM, Steffen Maier wrote: > On 04/15/2010 04:20 PM, David Cantrell wrote: >> 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. > > Exactly and back then when I reviewed the code, I didn't yet know how > Chris' new device filtering and the corresponding storage selection > screen works and that we could just reuse its functionality. > >> 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. > > No my suggestion is not a duplication of code. I suggest to actually use > Chris' device filtering also for deciding which unformatted DASDs to > consider for formatting. The user already has to select DASDs in the > storage device selection screen before continuing, so why not just > ignore all unformatted DASDs which were not even selected as > installation targets? > Anaconda does not need to prepare unformatted DASDs it does not even > install to. Granted, I currently do not know if we could even display a DASD size for unformatted disks. That would only be known after clicking next and the dasdfmt but then the user is already in the next wizard screen. He can go back of course, but that's not obviously intuitive. >> 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. > > I disagree. The long term goal is to have DASD activation in anaconda > similar to FCP already just more user-friendly. However, that is a whole > different story (onlining) to what we're discussing here (formatting). > > But even then, we still need means for users to activate DASDs early in > linuxrc or loader to enable installations from local hard disks. Such > disks have to be activated early in order to be able to load stage2 from > such disks. This also means, that we would eventually need early FCP LUN > activation in linuxrc or loader to support install from FCP LUN. That > said, such early device activation would most probably always be > minimalistic and not very user-friendly, just like what we currently > have with DASD in linuxrc. The main device activation for the > installation targets would happen with all user-friendly bells and > whistles in anaconda GUI. > > All that would be for the future. > >> 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: > >>>> diff --git a/iw/filter_gui.py b/iw/filter_gui.py > >>>> @@ -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) Steffen 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
