[NOTE: I am still working a lot on this code, but I wanted to send a
first draft of patches to the list to get feedback from people. I am
able to do installs of x86_64 rawhide with these changes.
I do not have the DASD filter method done either, but you can see how
that code is hooked up within the dracutSetupData stuff.]
I've expanded the dracutSetupString code in anaconda to offer some more
flexibility for picky kernel modules as well as adding in some support
for option-specific data mangling if we need it. Many thanks to Hans for
what he'd already implemented. It made expanding things quite easy.
First, I've renamed dracutSetupString() to dracutSetupData(). These
methods are now returning a list of dicts instead of just a string. The
main motivation behind this is the complexities involved with the dasd
kernel modules. We have device classes in storage/devices.py that know
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.
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.
The dict for each kernel parameter at a minimum must contain two keys.
The 'option' and 'value' keys. Pretty self explanatory. By storing
the information this way, we avoid having to reparse strings later,
which makes life easy for the combining step described below.
The dicts may also store optional keys:
combine If this exists and is True, booty will take all
kernel parameters for this key (e.g., 'dasd') and
combine the values in to one string. Use of this
key requires the next key.
delimiter A string holding the delimiter to use when combining
all the values in to a single string. e.g., ","
filter A callback function taking a list of values. If
this key exists and combine is True, booty will call
the filter function and pass it a list of all the
values before they are combined in to a single
string. This function needs to return a list of
values. Use this to implement device-specific option
filtering. For DASD, I am using this to reduce the
list of DASD bus IDs to a range specification. DASD
needs this to avoid incredibly long dasd= parameters
when systems have thousands of DASDs configured.
The way I've implemented the filter calls allows you
to have multiple filters per kernel parameter.
In booty/bootloaderInfo.py, you'll find the code that calls dracutSetupData
and does all of the above. Each dracutSetupData method knows how to build
the list of dicts so that booty can then act on it appropriately.
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. 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.
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
the future I hope we can add an overwhelming and super confusing screen to
let people configure the DASD parameters. Also, kickstart methods for
changing those settings might be helpful. I don't know. But at least we
can pick up the settings as they exist during installation and send them to
dracut.
Things remaining:
* DASD value filtering method.
* Patch for system-config-keyboard to change dracutSetupString to
dracutSetupData like the other methods.
That about covers these changes. Questions or comments are appreciated.
Ideas I have thought about but didn't do anything about:
* Kernel parameter ordering. Does this ever matter?
* DASD global options such as nopav and nofcx, but that's a question
for IBM. And by IBM, I mean Steffen.
* Another one for IBM: Do we ever care about the autodetect or
probeonly dasd parameters? My guess is no.
--
David Cantrell <dcantrell@xxxxxxxxxx>
Red Hat / Honolulu, HI
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
