-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Sat, 10 Oct 2009, Steffen Maier wrote:
On 10/10/2009 12:27 AM, David Cantrell wrote:
how to write a kernel parameter for themselves. The catch with dasd is
that all of those parameters need to be combined in to a single dasd=
parameter.
This is true for the dasd= parameter of the dasd_mod device driver
module. However, I'd like us to be aware, that it is just the current
simple dracut implementation which exposes the same syntax and hence
catch to anaconda. In general, this doesn't have to be. Dracut could
activate each DASD by itself just like linuxrc.s390 now does -- and like
dracut does for zFCP LUNs. That would require a little more code in
dracut since it could then no longer just pass the parameters string
untouched to the module by means of writing it to modprobe.conf. I'm
starting to think we should really discuss this with Harald.
I like this idea. It certainly sounds cleaner and hopefully less prone to
failures later. Let's talk to Harald about this.
I've tried to keep the code as generic and flexible as possible. The
list of dicts returned by dracutSetupData:
Each kernel parameter (e.g., 'acpi=off') is a dict. A dracutSetupData
method can return multiple kernel parameters, hence the list of dicts.
This, I only understood when I saw your sketch in patch 2/8. More
comments on the dicts in this other mail.
Another catch with DASD is the need for *all* DASD bus IDs to be included
in the dasd= parameter, regardless of whether or not they are used by the
root device.
This is not because of DASD but because there is currently no initscript
that can activate non-root DASDs on boot. That could be repaired and I
think that would be the right solution now that you follow the clean
path for dracutSetupData with DASD in anaconda (instead of my proposed
one-string fits all quick hack).
Let's do the init script then. Should probably be part of the s390utils
package. We'd need to define some sort of control file where anaconda can
write data to telling the init script what DASDs should be activated, but this
doesn't sound too hard.
This would really simplify things a lot.
If you don't include them all, the administrator will have
to bring them up manually. To get around this problem, I added a property
called forceDracut in storage/devices.py. It's False for everything
except DASDDevice. Set it to True for force inclusion of dracutSetupData
even if the device isn't used by the root device.
Jumping through hoops in anaconda to abuse dracut to activate all DASDs
seems wrong to me. We should really have an initscript for activating
all non-root DASDs and have anaconda tell dracut to only activate the
root devices. Isn't dracut supposed to only bring up the root fs?
Agreed. Let's work on the dasd bring up init script.
(There will only be more than one root DASD, if parallel access volume
(PAV) is used, of which I don't know if that is supported of anaconda
and if it is even needed for installation since it is a performance
feature for e.g. data disks and I don't expect the root disk to be under
heavy load during installation and afterwards. Without PAV, we only have
exactly one root DASD to tell dracut.)
We're not doing anything special for PAV that I know of.
Specific to DASD: During the 'Finding devices...' step in anaconda is when
the kernel parameter information is collected. Values are read directly
from sysfs. While we don't expose any method in anaconda for changing these
settings now, users could theoretically change things using a %pre script in
a kickstart file and this code would still pick up the user's settings. In
I really like this approach.
Excellent.
the future I hope we can add an overwhelming and super confusing screen to
let people configure the DASD parameters.
Let's just come up with an easy to use and nice small dialog. I have
ideas and a glade mockup already. However, the mockup without code that
fills in at least some example data is not very meaningful right now.
Same thing goes for activation and deactivation(yes I'm serious here) of
zFCP LUNs. But that is future work and I don't intend to formulate any
expectations here.
Sure, we'll get on the UI elements later.
Also, kickstart methods for
changing those settings might be helpful. I don't know. But at least we
Considering the DASD= option of parm/conf file as a legacy hack,
kickstart methods for activating DASDs to install to would indeed be
helpful. It's implemented for zFCP LUNs already.
I'll look at what we do for zFCP later.
* DASD value filtering method.
We can get aroung the whole combination and filtering, if we go away
from the single (legacy) module string. In the light of trying to solve
this whole thing right, doing away with the legacy string seems like the
consequence to me. However, we cannot decide on this ourselves.
I'm all for this.
* Kernel parameter ordering. Does this ever matter?
I cannot think of any example where it would matter right now.
Good.
* DASD global options such as nopav and nofcx, but that's a question
for IBM. And by IBM, I mean Steffen.
That just cannot be me. Seriously, probably we don't need them. But then
again it would be nice if we could hand them over to dracut so they can
be effective when the DASD driver module gets loaded in initramfs. That
is the only way I know of to pass these options to the module. There is
no sysfs interface to do that later on dynamically.
We may have to deal with those options later. I'm not sure what they even
entail with regards to anaconda impact.
* Another one for IBM: Do we ever care about the autodetect or
probeonly dasd parameters? My guess is no.
No, we don't care. In fact, we do not even want to have them available
for the user. Probeonly is only useful for device driver debugging.
Autodetect is evil and linuxrc has always correctly recommended not to
use it. Using autodetect, you don't know what disks get activated with
what options and in an LPAR with four thousand disks you do not want
them all activated because of memory usage (this multiplies by the
number of virtual machines and then it starts to really hurt!), sensing
time and user space deamons getting hickups with that many devices, and
also because of security issues (you don't want your z/OS operator to
discover that Linux touched and modified some disk it must not).
Excellent, just wanted to make sure.
- --
David Cantrell <dcantrell@xxxxxxxxxx>
Red Hat / Honolulu, HI
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkrP3UwACgkQ5hsjjIy1VknzuQCcCLGYfPNvDfPvzjJOObLLOEXD
u+8AniEzZqKW492wXJ4fmY2uW3kSOJGi
=DtOW
-----END PGP SIGNATURE-----
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
