-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Tue, 27 Oct 2009, Steffen Maier wrote:
Sorry, I forgot one thing on my initial reply.
On 10/27/2009 05:24 PM, Steffen Maier wrote:
On 10/27/2009 03:07 AM, David Cantrell wrote:
Before the device tree is built in the storage code, run through the
DASD devices on the system and format any with a status of
'unformatted'. We have to run dasdfmt on these devices before we can
partition them.
Under RHEL-5, this process was serial and the user had to click Yes for
each unformatted DASD found, which could take a really long time if
you had thousands of DASDs.
The idea now is that if the DASD is seen by anaconda, we want to use it
for installation. The stage 1 device initialization routines as well as
the CMS conf file provided at boot time allow the user to restrict the
range of devices we see during installation. If any of the devices we
see are unformatted, run dasdfmt before building the devicetree.
This process is implemented in a DASD class that works similar to the
iscsi and zfcp classes. That is, devices may need to be started or
brought in to a working state before the anaconda storage code can use
them.
---
storage/__init__.py | 3 +
storage/dasd.py | 167 +++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 170 insertions(+), 0 deletions(-)
create mode 100644 storage/dasd.py
diff --git a/storage/dasd.py b/storage/dasd.py
new file mode 100644
index 0000000..f4df8ca
--- /dev/null
+++ b/storage/dasd.py
@@ -0,0 +1,167 @@
+ log.info(" %s is an unformatted DASD" % (device,))
+ self._dasdlist.append(device)
+
+ if not len(self._dasdlist):
+ log.info(" no unformatted DASD devices found")
+ return
+
+ if intf:
+ c = len(self._dasdlist)
+
+ title = P_("Unformatted DASD Device Found",
+ "Unformatted DASD Devices Found", c)
+ msg = P_("Format uninitialized DASD device?\n\n"
+ "There is %d uninitialized DASD device on this "
+ "system. To continue installation, the device must "
+ "be formatted. Formatting will remove any data on "
+ "this device. If you are unsure of your DASD "
+ "configuration, select No to exit the installer." % c,
+ "Format uninitialized DASD devices?\n\n"
+ "There are %d uninitialized DASD devices on this "
+ "system. To continue installation, the devices must "
+ "be formatted. Formatting will remove any data on "
+ "these devices. If you are unsure of your DASD "
+ "configuration, select No to exit the installer." % c,
+ c)
+
+ rc = intf.messageWindow(title, msg,
+ custom_icon="error", type="yesno")
+ if rc == 0:
+ sys.exit(0)
IIRC, with RHEL5 the user could just ignore unprepared DASDs and
continue with whatever disks would then be left. Since some of the
user-specified DASDs may already be prepared (or zFCP LUNs may be
available), this seems like a valid and user-friendly choice to me.
Could we change the exit into an early return from this method, so the
user could happily continue with installation, if he does not want to
touch the unprepared DASDs?
That becomes more difficult and I question whether or not it's even necessary.
The problem with returning here rather than exiting is that storage code will
then go and build its devicetree and unformatted DASDs will raise exceptions.
Of course, we could work around that with a return value from startup() that
then gets handed to the devicetree building so we know to ignore unformatted
DASDs (or some other implementation, I don't care, but I really think that's
unnecessary.
We give users plenty of ways to construct a DASD range they want to use for
the VM. The linuxrc.s390 rewrite you did and the conf file that's passed in
and the cio_ignore parameter and other kernel boot parameters. By the time
we actually get to where we can run anaconda, is it not reasonable to say
"we should be able to use all DASDs that are visible"? I think policy should
be the DASD range you configure in stage 1 should be authoritative from stage
2's perspective. If a user does not want to format any unformatted DASDs,
they need to edit the CMS conf file, kernel boot parameters, or give different
answers to linuxrc.s390 questions.
And even if that's not the case, we're dealing with the scope of installation
here. So if there's going to be some weird case where a user will want a DASD
visible in Linux, but not have it run through dasdfmt, I say that's best set
up after anaconda installs and you have a workable system.
- --
David Cantrell <dcantrell@xxxxxxxxxx>
Red Hat / Honolulu, HI
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkrnaYsACgkQ5hsjjIy1VkmkDwCg1ll1Hoh1NXluZPem3ZNVbSvo
zdoAoM5useftCZnO0Jw5Uo6BFxZw8mAy
=gahV
-----END PGP SIGNATURE-----
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
