On Thu, Apr 23, 2009 at 01:59:20PM -0500, David Lehman wrote: > On Thu, 2009-04-23 at 20:52 +0200, Hans de Goede wrote: > > This whole thing seems so ineffective to me. I don't understand why we > remove devices from the device tree for this. If we find a broken VG, we We remove it from the tree so it can be ignored. If its not in the tree then it does not exist for all the calculations we do after the probe phase. And, IMO, we _need_ to do the asking to differentiate between two situations: 1. The user has a setup that we don't understand and he wants the installer to ignore certain parts of it. And 2. The user has leftover metadata from previous installs that he does not understand and want the installer to overwrite them. > should simply remove the VG and and LV devices from the device tree, > blacklist the VG's name, and carry on. No prompting, no special ok, but without ignoring device or blacklisting partitions the user might erase his partition. Moreover the calculations that anaconda does for autopartitioning might erroneously include the ignored partition in its calculations. I might have misunderstood you here as you specified what to do with the LV and VG but not the underlying device or partition. I think the question might be why blacklist the partition but remove the device?. The answer, IMO, is that the partition can hold one stacked element, as opposed to the device, that can hold lots of stacked elements (namely partitions). So if a PV is on a device, ignoring the device wont affect other parts of the stacked tree. But if we ignored the device that holds the partition where the PV is on, then we will most likely disrupt other stacked elements (this is why we should just black list the partition). This, I think, is the reason for treating them differently. > handling. If it's broken, ignore it. Same for mdraid. > > > > > On 04/23/2009 05:41 PM, David Lehman wrote: > > > On Thu, 2009-04-23 at 17:01 +0200, Hans de Goede wrote: > > >> When a PV partition is part of an inconsistent VG, and the user chooses > > >> to ignore it we currently remove it from the devicetree, but since > > >> partition_gui.py populate() uses parted on the disk to find out about > > >> the partitions, it will still see it and then backtrace when it cannot > > >> find it in the devicetree. > > > > > > I've forgotten why we can't just ignore partitions we find that aren't > > > in the device tree. Other than FREESPACE partitions, I can't think of a > > > reason why we'd want to do anything with such a partition, unless it > > > involves our naming shenanigans with new partitions. > > > > > > > Well, if we just plain ignore it, then it won't show in the stripe, nor > > in the list, and the user might get mightely confused that he has a 100 gig > > disk with 75 gigs of partitions on it and he cannot create anymore due to > > lack of space. > > > > >> This patch fixes this by instead making the partition immutable. Note > > >> that I've put the reason for it being immutable in the new immutableDevices > > >> array, so that if we have similar cases in the future we can use > > >> immutableDevices for that too. We might even want to move some of our > > >> existing cases there. > > > > > > We could also just add a check in Storage/deviceImmutable to see if it's > > > listed/marked as part of a broken VG. > > > > > > > That feels wrong, I thing we should simplify Storage/deviceImmutable, not > > complicate it. > > > > The real problem here is I cannot use protectedPartitions, because > > the reason shown to the user for a partition being in protectedPartitions > > is hardcoded. > > > > To me the real solution would be to remove protectedPartitions (why is it > > an array anyways, it never has more then one member), and add the hd media > > holding partition to an immutableDevices array (as my patch creates), which > > holds both an identifier (for example the device name) and the reason why > > the device is immutable, this to me feels as a much more generic solution > > then all the special casing inside Storage/deviceImmutable > > > > Regards, > > > > Hans > > > > _______________________________________________ > > Anaconda-devel-list mailing list > > Anaconda-devel-list@xxxxxxxxxx > > https://www.redhat.com/mailman/listinfo/anaconda-devel-list > > _______________________________________________ > Anaconda-devel-list mailing list > Anaconda-devel-list@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/anaconda-devel-list -- Joel Andres Granados Brno, Czech Republic, Red Hat. _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
