Re: fdisk behavior on a gpt partitioned disks

["Mike M. Volokhov" <mishka%NetBSD.org@localhost>]

On Fri, 29 May 2009 06:26:07 -0700 (PDT) Paul Goyette wrote:
> On Fri, 29 May 2009, Joerg Sonnenberger wrote:
> 
> > On Fri, May 29, 2009 at 06:05:55AM -0700, Paul Goyette wrote:
> >> On Fri, 29 May 2009, Mike M. Volokhov wrote:
> >>
> >>> The patch implements the following logic:
> >>>
> >>> - always warn if disk have GPT
> >>>
> >>> - in interactive mode: explicitly warn that any change to MBR will
> >>>  result in GPT removal, ask for confirmation, and remove GPT
> >>>
> >>> - in non-interactive mode: remove GPT and explicitly note this fact
> >>
> >> Wouldn't it be more reasonable to have a new command-line option to
> >> remove the GPT?  In non-interactive mode without the new option, if the
> >> GPT exists the command should fail with a non-zero exit status (and an
> >> appropriate error message).
> >
> > I basically want it to do the right thing for sysinst. As long as that
> > works automatically, I don't mind.
> 
> Shouldn't sysinst check for existence of the GPT and ask the user if it 
> should really be removed?  If the user says "Y" then sysinst can use the 
> new option flag to force removal.

It's already asks. Something "all your data will be destroyed. Continue?"
Please also note that MBR table and GPT are somewhat incompatible, i.e.
you can't create any MBR partition because GPT allocates all space by
it's protective MBR.

> I just don't like doing irreversible damage without making certain that 
> that is what the user intended.  Yes, we can give the user enough rope 
> to hang him/herself, but we don't necessarily need to have the hangman's 
> noose already tied, ready to slip around the user's neck!  :)

To be honest, the fdisk patch will delete GPT headers only, leaving
GUID tables intact. So, it should be possible to reconstruct GPT
partitioning back :)

--
M.