Re: [PATCH 2/2] Find and format any unformatted DASD devices (#528386).

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On 10/28/2009 02:25 PM, Chris Lumens wrote:
Would this kill all potential partitions on DASDs that were already both
low-level formatted as well as already having partitions?
That would mean whenever the user had one or more DASDs yet to be
low-level formatted, he would have to recreate all existing partitioning
on other DASDs which had been in use and thus prepared before.
How was this handled with RHEL5 in order not to introduce regressions?

Hmm, yeah that could be a problem.  I'm going to save the kickstart handling
for another patch.  I want to talk to clumens and see what, if anything,
exists in kickstart that we could define/use for unformatted DASDs.

Actually, what I meant to suggest was the zerombr command, which
reinitializes any invalid partition tables it finds.  We overload this
to do the same with LVM metadata.  I suggest we further overload it to
do the same for unformatted DASDs.

I can't overstate my opposition to adding any new options or commands to
the clearpart/zerombr disaster, as that can only make things even more
complicated and introduce even more corner cases we don't test for.


Weren't we going to fixup the kickstart syntax for RHEL6 ?

We currently have 4 things hidden under 2 commands:
zerombr: boolean, wether or not to ask before overwriting invalid disklabels
         with a fresh one, applies to all disks
clearpart --initlabel boolean, wether or not to give disks a fresh
         disklabel independent of what is there, only clears disks
         listed in the clearpart command
clearpart --linux / --all control an enum, which controls which sort
         of partitions to remove for preserved disklabels, only removes
         partitions listed in the clearpart command
clearpart list-of-disks-to-clear, see the other 2 clearpart commands

Now we could keep clearpart as is, it aint pretty, but it is ok-ish, but
zerombr should really be renamed to something like
confirm_destructive_actions yes / no

As that is what it does, esp as we've already overloaded it with clearing
invalid / incomplete lvm metadata, and the current zerombr name makes
people think it does what --initlabel actually does.

Regards,

Hans

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

[Index of Archives]     [Kickstart]     [Fedora Users]     [Fedora Legacy List]     [Fedora Maintainers]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]
  Powered by Linux