-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Thu, 15 Apr 2010, 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.
This last line is key to my whole point from the previous message. All DASDs
that anaconda sees should be treated as usable for installation. Users should
not online an unformatted DASD they do not wish to use. With all the
cio_ignore stuff in place and the thousands of lines in linuxrc.s390, we have
enough ways for users to finegrain the DASD list *before* they get in to
anaconda. Once you get to anaconda, we know that any DASD we see is one the
user wants to use for installation. Unformatted DASDs should then be
formatted. Formatting then fills out the sysfs attributes for the unformatted
DASDs, which then lets the rest of our storage code work.
Additionally, the tools in the s390utils are pretty difficult to work with,
which is why I would like to avoid doing more in anaconda with DASDs. Half
are shell scripts, the other half are compiled command line programs. That
doesn't matter so much as the fact that there are TOO MANY tools in s390utils.
Which is related to the problems I have with some of the IBM requests. You
[IBM] seem to want multiple ways to do the same thing, when we [anaconda]
actively try to simplify things as much as possible and make fewer ways to do
things.
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.
So long as we need to keep that functionality in linuxrc.s390, I would prefer
to delegate device filtering of DASDs to linuxrc.s390 rather than having it in
both linuxrc.s390 and the anaconda code.
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
- --
David Cantrell <dcantrell@xxxxxxxxxx>
Red Hat / Honolulu, HI
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iEUEARECAAYFAkvHUsUACgkQ5hsjjIy1VklBtwCfUBF8qEoUqGWWF72ehVK6tu2M
3qUAmIHS+a/01ytIAU8YKPRg+phxvk4=
=GgGZ
-----END PGP SIGNATURE-----
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
