Re: bin/49510: gpt(8) fails w/o drvctl and breaks sysinst

[John Nemeth <jnemeth%cue.bc.ca@localhost>]

The following reply was made to PR bin/49510; it has been noted by GNATS.

From: John Nemeth <jnemeth%cue.bc.ca@localhost>
To: Martin Husemann <martin%duskware.de@localhost>, gnats-bugs%NetBSD.org@localhost
Cc: gnats-admin%NetBSD.org@localhost, netbsd-bugs%NetBSD.org@localhost, martin%NetBSD.org@localhost
Subject: Re: bin/49510: gpt(8) fails w/o drvctl and breaks sysinst
Date: Mon, 29 Dec 2014 02:43:43 -0800

 On Dec 29, 10:57am, Martin Husemann wrote:
 } On Mon, Dec 29, 2014 at 02:05:01AM +0000, John Nemeth wrote:
 } >       I disagree that this is a bug in gpt(8).  Every INSTALL kernel
 } >  where gpt(8) is going to be used should have drvctl, or gpt(8)
 } >  shouldn't be used.
 } 
 } Yes, sysinst should not try to find out wether a disk has a GPT by invoking
 } gpt(8), as that tool is obviously not up to the task.
 
      It obviously is up to the task.  Politics do not belong in a PR!
 
 } I would change it to just open the disk, read a few kb and check the GPT
 } (master copy) signature, but others claim this would violate the UEFI
 } spec that forces us to check the backup copy.
 
      This would be a terrible idea.  You could end up accidentally
 trashing a disk.  Or, you could set it up to be trashed later when
 a properly functioning tool finds the backup copy and restores it.
 
      BTW, GPT headers are guaranteed to be in the second block and
 the last block.  Finding the last block of the disk would leave
 you in the same place as gpt(8).
 
 }-- End of excerpt from Martin Husemann