Jeremy Katz wrote:
On Tue, 2008-04-15 at 12:19 +0200, Joel Andres Granados wrote:
Jeremy Katz wrote:
What's actually trying to be solved by adding this?
ignore swap.
Ignore it how? Just don't use it during install? Don't add it to the
fstab? What's the use case.
Ignoring on install time. It becomes relative when the installer sees swap partitions that are being used. Might have a disk thats only swap partitions for virtual hosts. If you include that disk in an installation, anaconda will use all the swaps. see 70477.
What do you think about having --ignoreuuid. This would be really usefull as a
way of ignoring whatever has a uuid. It could be a fall back method. when the
--ignoredisk cant be used.
And what happens if someone puts in the uuid of a random partition?
What are the semantics of ignoring it -- do we not ever delete the
partition? What happens if they try to use it with ondisk? How does it
interact with zerombr?
ignoredisk is nice and simple -- we remove the disk from the ones we
look and and do anything to. Ignoring just a partition feels far less
obvious to me
Its not obvious. And to be honest, havent really thought about the interactions with the rest of the ks commands. I would assume that it would have precedence over any of the "modify partitions" options. Thing is, that we would have to check the uuid each time something is being preformed on a storage element. Have to spend some more time pondering that one :)
We could also code it into the storage classes. So when some partition is ignored, it will have certain behavior that prevents any changes to be done to the underlying structure, but allows data information to be returned to whoever needs it. Then again, it would maybe be asking too much of the storage structure.
I guess I'm just trying to find a way of telling anaconda not to touch certain things.
Darn partitioning code. :)
I totally agree with you on the complexity, thats the reason for the patch only touches swap related stuff for now. maybe going back to my oritinal --ignoreswap idea is best. :(
--
Joel Andres Granados
Red Hat / Brno, Czech Republic
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
