Hi,
the only think i do not like is the hardcoded RHEL name detection. Do we have any way how to pass arguments/flags in the .discinfo or some similarfile?
and before you start asking questions, I already have some answers from discussion with Jeremy:
First of all, I still have strong reservations about this as I really don't like the hard-coded, something called by this name getting used and would much prefer it being explicitly specified...
Me too, but we can't just drop the feature now, because Dell will scream.. again..
We really need to stop polluting the flags namespace and come up with a better way of passing this around. If we're going to do it, it could at least be in the anaconda class instead
Right now we do not have any other "information object" to store this kind of information
We use actual mount(8) now instead of calling mount(2). This means that we can just do 'mount LABEL=foo /bar' and don't need any of the blkid bits.
We do, because there might be more driverdiscs with the same "oemdrv" label
As I said in the intro, I really don't want auto-mounting code -- we should instead just use dd=LABEL=foo and let them pass that...
I agree with you, but the problem is Dell, they think that passing arguments is "bad customer experience". We tried very hard to avoid it.. and the only compromise we were able to negotiate was that, this will be disabled by default in Fedora.
... at which point, this can just flow into being the regular driver disk code.
The dlabel is now official feature in RHEL5, sorry but I'm not going through the discussion again now, I've spent half a year in trying to persuade Dell, that this is bad idea.. and if they do not see this in RHEL6, they will be at my throat again...
if self.anaconda.id.extraModules:
if self.anaconda.id.extraModules or flags.dlabel:
It is the second RFE they have, sometimes their driverdisc doesn't contain any modules, so extraModules is empty, but the repository on the driverdisc is not. And they want to install some stuff using it. Again without any user interaction and without kickstart.
We were at least able to tell them a way, which didn't need any code chnages, except this one (using comps.xml file in the repo). Look at #316631.
Just a reminder, that this functionality is needed for RHEL6 too. And I still have no review..
----- "Martin Sivak" msivak@redhat.com wrote:
Hi,
the only think i do not like is the hardcoded RHEL name detection. Do we have any way how to pass arguments/flags in the .discinfo or some similarfile?
and before you start asking questions, I already have some answers from discussion with Jeremy:
First of all, I still have strong reservations about this as I
really
don't like the hard-coded, something called by this name getting
used
and would much prefer it being explicitly specified...
Me too, but we can't just drop the feature now, because Dell will scream.. again..
We really need to stop polluting the flags namespace and come up
with a
better way of passing this around. If we're going to do it, it
could at
least be in the anaconda class instead
Right now we do not have any other "information object" to store this kind of information
We use actual mount(8) now instead of calling mount(2). This means
that
we can just do 'mount LABEL=foo /bar' and don't need any of the
blkid
bits.
We do, because there might be more driverdiscs with the same "oemdrv" label
As I said in the intro, I really don't want auto-mounting code --
we
should instead just use dd=LABEL=foo and let them pass that...
I agree with you, but the problem is Dell, they think that passing arguments is "bad customer experience". We tried very hard to avoid it.. and the only compromise we were able to negotiate was that, this will be disabled by default in Fedora.
... at which point, this can just flow into being the regular driver
disk code.
The dlabel is now official feature in RHEL5, sorry but I'm not going through the discussion again now, I've spent half a year in trying to persuade Dell, that this is bad idea.. and if they do not see this in RHEL6, they will be at my throat again...
if self.anaconda.id.extraModules:
if self.anaconda.id.extraModules or flags.dlabel:It is the second RFE they have, sometimes their driverdisc doesn't contain any modules, so extraModules is empty, but the repository on the driverdisc is not. And they want to install some stuff using it. Again without any user interaction and without kickstart.
We were at least able to tell them a way, which didn't need any code chnages, except this one (using comps.xml file in the repo). Look at #316631.
Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
the only think i do not like is the hardcoded RHEL name detection. Do we have any way how to pass arguments/flags in the .discinfo or some similarfile?
Well, the only way to get product information at this stage of anaconda is to look in the .discinfo file, but it's a completely unstructured file so we don't want to go adding more stuff in there unless it's absolutely necessary to the survival of the human race.
Once we're in stage2 we can look at .treeinfo or use an installclass. Of course, it's entirely too late at that point. And I'm certainly not going to suggest we come up with some loader installclass mechanism using libdl. That's just sick.
First of all, I still have strong reservations about this as I really don't like the hard-coded, something called by this name getting used and would much prefer it being explicitly specified...
Me too, but we can't just drop the feature now, because Dell will scream.. again..
Yeah, sigh.
We really need to stop polluting the flags namespace and come up with a better way of passing this around. If we're going to do it, it could at least be in the anaconda class instead
Right now we do not have any other "information object" to store this kind of information
But you're not using the dlabel value anywhere where we don't also have a reference to the anaconda object, so I think you can get away with not putting it into flags. The line between flags and the anaconda object is definitely blurred these days.
We use actual mount(8) now instead of calling mount(2). This means that we can just do 'mount LABEL=foo /bar' and don't need any of the blkid bits.
We do, because there might be more driverdiscs with the same "oemdrv" label
I don't think we're likely to ever run into this case. However, just to be safe I suppose we should keep the blkid method.
As I said in the intro, I really don't want auto-mounting code -- we should instead just use dd=LABEL=foo and let them pass that...
I agree with you, but the problem is Dell, they think that passing arguments is "bad customer experience". We tried very hard to avoid it.. and the only compromise we were able to negotiate was that, this will be disabled by default in Fedora.
As much as I'd like to say that we should just have it defaulted to disabled always since it's Fedora and we don't care, I know this means we will forget to defaulting it to on when it comes time to make a new RHEL. I guess I don't know what to do here.
if self.anaconda.id.extraModules:
if self.anaconda.id.extraModules or flags.dlabel:It is the second RFE they have, sometimes their driverdisc doesn't contain any modules, so extraModules is empty, but the repository on the driverdisc is not. And they want to install some stuff using it. Again without any user interaction and without kickstart.
We were at least able to tell them a way, which didn't need any code chnages, except this one (using comps.xml file in the repo). Look at #316631.
Yeah I remember this discussion and grudgingly agree.
- Chris
anaconda-devel@lists.fedoraproject.org
-
Chris Lumens -
Martin Sivak