Re: [PATCH 3/5] Check for and offer to format unformatted DASD devices (#560702).

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

> 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


[Index of Archives]     [Kickstart]     [Fedora Users]     [Fedora Legacy List]     [Fedora Maintainers]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]
  Powered by Linux