NetBSD Problem Report #49510

From martin@duskware.de  Sun Dec 28 18:51:33 2014
Return-Path: <martin@duskware.de>
Received: from mail.netbsd.org (mail.netbsd.org [149.20.53.66])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.netbsd.org", Issuer "Postmaster NetBSD.org" (verified OK))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 28DC0A5832
	for <gnats-bugs@gnats.NetBSD.org>; Sun, 28 Dec 2014 18:51:33 +0000 (UTC)
Date: Sun, 28 Dec 2014 19:51:30 CET
From: martin@NetBSD.org
Reply-To: martin@NetBSD.org
To: gnats-bugs@NetBSD.org
Subject: gpt(8) fails w/o drvctl and breaks sysinst
X-Send-Pr-Version: 3.95

>Number:         49510
>Category:       bin
>Synopsis:       gpt(8) fails w/o drvctl and breaks sysinst
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    bin-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Dec 28 18:55:00 +0000 2014
>Last-Modified:  Thu Jan 01 20:50:00 +0000 2015
>Originator:     Martin Husemann
>Release:        NetBSD 7.99.2
>Organization:
The NetBSD Foundation, Inc.
>Environment:
System: NetBSD night-owl.duskware.de 7.99.2 NetBSD 7.99.2 (NIGHT-OWL) #290: Mon Dec 1 12:37:01 CET 2014 martin@night-owl.duskware.de:/usr/src/sys/arch/amd64/compile/NIGHT-OWL amd64
Architecture: x86_64
Machine: amd64
>Description:

During install sysinst tries to decide wether a disk already has a GPT or
not. It basically invokes something like:

  gpt show sd1

but on kernels which do not have pseudo-device drvctl this fails in very
unintuitive ways:

gpt: drvctl: /dev/drvctl: Device not configured
gpt: unable to open device 'rsd1c': Device not configured

We need this operation to silently complete (in case of an absent GPT), or
add a new "does it exist" check operation which does - or teach sysinst to
check for a GPT "manually" by just looking at the start of the disk.

>How-To-Repeat:

Boot e.g. a VAX GENERIC kernel and do:

gpt sd0 show

>Fix:
n/a

>Audit-Trail:
From: mlelstv@serpens.de (Michael van Elst)
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: bin/49510: gpt(8) fails w/o drvctl and breaks sysinst
Date: Sun, 28 Dec 2014 21:08:58 +0000 (UTC)

 martin@NetBSD.org writes:

 >but on kernels which do not have pseudo-device drvctl this fails in very
 >unintuitive ways:

 >gpt: drvctl: /dev/drvctl: Device not configured
 >gpt: unable to open device 'rsd1c': Device not configured

 We could also make drvctl mandatory or define ioctls that return
 disk geometry without being limited to 32bit numbers.


From: John Nemeth <jnemeth@cue.bc.ca>
To: gnats-bugs@NetBSD.org, gnats-admin@NetBSD.org, netbsd-bugs@NetBSD.org,
        martin@NetBSD.org
Cc: 
Subject: Re: bin/49510: gpt(8) fails w/o drvctl and breaks sysinst
Date: Sun, 28 Dec 2014 18:14:08 -0800

 On Dec 28,  9:10pm, Michael van Elst wrote:
 }
 } The following reply was made to PR bin/49510; it has been noted by GNATS.
 } 
 } From: mlelstv@serpens.de (Michael van Elst)
 } To: gnats-bugs@netbsd.org
 } Cc: 
 } Subject: Re: bin/49510: gpt(8) fails w/o drvctl and breaks sysinst
 } Date: Sun, 28 Dec 2014 21:08:58 +0000 (UTC)
 } 
 }  martin@NetBSD.org writes:
 }  
 }  >but on kernels which do not have pseudo-device drvctl this fails in very
 }  >unintuitive ways:
 }  
 }  >gpt: drvctl: /dev/drvctl: Device not configured
 }  >gpt: unable to open device 'rsd1c': Device not configured
 }  
 }  We could also make drvctl mandatory or define ioctls that return
 }  disk geometry without being limited to 32bit numbers.

      I'm going to agree with this.  gpt(8) shouldn't be getting
 mangled every time some external item has an issue.  Also, drvctl
 is handy for a lot of things and really should be in pretty much
 every modern kernel.

      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.

 }-- End of excerpt from Michael van Elst

From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@NetBSD.org
Cc: gnats-admin@netbsd.org, netbsd-bugs@netbsd.org, martin@NetBSD.org
Subject: Re: bin/49510: gpt(8) fails w/o drvctl and breaks sysinst
Date: Mon, 29 Dec 2014 10:57:43 +0100

 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.

 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.

 Martin

From: John Nemeth <jnemeth@cue.bc.ca>
To: Martin Husemann <martin@duskware.de>, gnats-bugs@NetBSD.org
Cc: gnats-admin@NetBSD.org, netbsd-bugs@NetBSD.org, martin@NetBSD.org
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

From: Robert Elz <kre@munnari.OZ.AU>
To: John Nemeth <jnemeth@cue.bc.ca>
Cc: Martin Husemann <martin@duskware.de>, gnats-bugs@NetBSD.org,
        gnats-admin@NetBSD.org, netbsd-bugs@NetBSD.org, martin@NetBSD.org
Subject: Re: bin/49510: gpt(8) fails w/o drvctl and breaks sysinst
Date: Mon, 29 Dec 2014 18:52:41 +0700

     Date:        Mon, 29 Dec 2014 02:43:43 -0800
     From:        John Nemeth <jnemeth@cue.bc.ca>
     Message-ID:  <201412291043.sBTAhhOA007511@server.CornerstoneService.ca>

   | Finding the last block of the disk would leave
   | you in the same place as gpt(8).

 If
 	lseek(disk_fd, (off_t)-BLOCKSZE, SEEK_END);

 doesn't work to do that, then it (the drivers etc) should be fixed
 so that it does.

 kre

From: mlelstv@serpens.de (Michael van Elst)
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: bin/49510: gpt(8) fails w/o drvctl and breaks sysinst
Date: Mon, 29 Dec 2014 12:09:15 +0000 (UTC)

 kre@munnari.OZ.AU (Robert Elz) writes:

 >    Date:        Mon, 29 Dec 2014 02:43:43 -0800
 >    From:        John Nemeth <jnemeth@cue.bc.ca>
 >    Message-ID:  <201412291043.sBTAhhOA007511@server.CornerstoneService.ca>

 >  | Finding the last block of the disk would leave
 >  | you in the same place as gpt(8).

 >If
 >	lseek(disk_fd, (off_t)-BLOCKSZE, SEEK_END);

 >doesn't work to do that, then it (the drivers etc) should be fixed
 >so that it does.


 That's a specfs issue.

 -- 
 -- 
                                 Michael van Elst
 Internet: mlelstv@serpens.de
                                 "A potential Snark may lurk in every tree."

From: John Nemeth <jnemeth@cue.bc.ca>
To: Robert Elz <kre@munnari.OZ.AU>, John Nemeth <jnemeth@cue.bc.ca>
Cc: Martin Husemann <martin@duskware.de>, gnats-bugs@NetBSD.org,
        gnats-admin@NetBSD.org, netbsd-bugs@NetBSD.org, martin@NetBSD.org
Subject: Re: bin/49510: gpt(8) fails w/o drvctl and breaks sysinst
Date: Mon, 29 Dec 2014 04:39:35 -0800

 On Dec 29,  6:52pm, Robert Elz wrote:
 }
 }     Date:        Mon, 29 Dec 2014 02:43:43 -0800
 }     From:        John Nemeth <jnemeth@cue.bc.ca>
 }     Message-ID:  <201412291043.sBTAhhOA007511@server.CornerstoneService.ca>
 } 
 }   | Finding the last block of the disk would leave
 }   | you in the same place as gpt(8).
 } 
 } If
 } 	lseek(disk_fd, (off_t)-BLOCKSZE, SEEK_END);
 } 
 } doesn't work to do that, then it (the drivers etc) should be fixed
 } so that it does.

      That leaves you with the issue of how to find the BLOCKSIZE.
 Which is currently done using the same methods used to find the
 size of the disk (i.e. both pieces of information come from the
 same place).

 }-- End of excerpt from Robert Elz

From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: bin/49510: gpt(8) fails w/o drvctl and breaks sysinst
Date: Mon, 29 Dec 2014 20:52:19 +0000

 On Mon, Dec 29, 2014 at 12:00:00PM +0000, Robert Elz wrote:
  >    | Finding the last block of the disk would leave
  >    | you in the same place as gpt(8).
  >  
  >  If
  >  	lseek(disk_fd, (off_t)-BLOCKSZE, SEEK_END);
  >  
  >  doesn't work to do that, then it (the drivers etc) should be fixed
  >  so that it does.

 AIUI, it doesn't, same as stat(2) doesn't return the disk size. I
 consider this a bug.

 -- 
 David A. Holland
 dholland@netbsd.org

From: christos@zoulas.com (Christos Zoulas)
To: gnats-bugs@NetBSD.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org, 
	martin@NetBSD.org
Cc: 
Subject: Re: bin/49510: gpt(8) fails w/o drvctl and breaks sysinst
Date: Mon, 29 Dec 2014 16:03:50 -0500

 On Dec 29,  8:55pm, dholland-bugs@netbsd.org (David Holland) wrote:
 -- Subject: Re: bin/49510: gpt(8) fails w/o drvctl and breaks sysinst

 |  AIUI, it doesn't, same as stat(2) doesn't return the disk size. I
 |  consider this a bug.

 Consider stat'ing /dev/nrst0. Do you really want it to return the
 size? Or /dev/rcd0a, what's the size? Is it the capacity? Or the
 current amount of data written? What if it's unformatted? Or even
 on regular disks, the size can be iffy... If you return sectors *
 secperunit, are you sure you can write that many bytes (what about
 bad sectors)?

 christos

From: Masao Uebayashi <uebayasi@gmail.com>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: bin/49510: gpt(8) fails w/o drvctl and breaks sysinst
Date: Tue, 30 Dec 2014 13:59:08 +0900

 On Tue, Dec 30, 2014 at 6:03 AM, Christos Zoulas <christos@zoulas.com> wrote:
 > Consider stat'ing /dev/nrst0. Do you really want it to return the
 > size?

 I'd expect it to return the physical disk size in bytes.

 > Or /dev/rcd0a, what's the size? Is it the capacity? Or the
 > current amount of data written? What if it's unformatted? Or even
 > on regular disks, the size can be iffy... If you return sectors *
 > secperunit, are you sure you can write that many bytes (what about
 > bad sectors)?

 I'd expect it to return the physical partition size in bytes, no
 matter if it's impossible to write that many bytes.

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

 On Dec 30,  5:00am, Masao Uebayashi wrote:
 }
 } The following reply was made to PR bin/49510; it has been noted by GNATS.
 } 
 } From: Masao Uebayashi <uebayasi@gmail.com>
 } To: gnats-bugs@netbsd.org
 } Cc: 
 } Subject: Re: bin/49510: gpt(8) fails w/o drvctl and breaks sysinst
 } Date: Tue, 30 Dec 2014 13:59:08 +0900
 } 
 }  On Tue, Dec 30, 2014 at 6:03 AM, Christos Zoulas <christos@zoulas.com> wrote:
 }  > Consider stat'ing /dev/nrst0. Do you really want it to return the
 }  > size?
 }  
 }  I'd expect it to return the physical disk size in bytes.

      That's a tape, not a disk.  And, if you say you want the
 capacity, how are you going to determine it?

 }  > Or /dev/rcd0a, what's the size? Is it the capacity? Or the
 }  > current amount of data written? What if it's unformatted? Or even
 }  > on regular disks, the size can be iffy... If you return sectors *
 }  > secperunit, are you sure you can write that many bytes (what about
 }  > bad sectors)?
 }  
 }  I'd expect it to return the physical partition size in bytes, no
 }  matter if it's impossible to write that many bytes.

      For a disk, I would agree.  A CD though is different.  Do you
 return the full capacity, or the amount currently.  How do you
 handle a CD-RW versus a CD-R?  For the latter, is the result
 different if it's blank?

 }-- End of excerpt from Masao Uebayashi

From: christos@zoulas.com (Christos Zoulas)
To: gnats-bugs@NetBSD.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org, 
	martin@NetBSD.org
Cc: 
Subject: Re: bin/49510: gpt(8) fails w/o drvctl and breaks sysinst
Date: Tue, 30 Dec 2014 08:37:07 -0500

 On Dec 30,  5:00am, uebayasi@gmail.com (Masao Uebayashi) wrote:
 -- Subject: Re: bin/49510: gpt(8) fails w/o drvctl and breaks sysinst

 |  > Consider stat'ing /dev/nrst0. Do you really want it to return the
 |  > size?
 |  
 |  I'd expect it to return the physical disk size in bytes.

 That's a tape, it'd have to spin it to the end, or the next EOF marker
 to find out.

 christos

From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: bin/49510: gpt(8) fails w/o drvctl and breaks sysinst
Date: Thu, 1 Jan 2015 20:49:20 +0000

 On Mon, Dec 29, 2014 at 09:05:00PM +0000, Christos Zoulas wrote:
  >  |  AIUI, it doesn't, same as stat(2) doesn't return the disk size. I
  >  |  consider this a bug.
  >  
  >  Consider stat'ing /dev/nrst0. Do you really want it to return the
  >  size? Or /dev/rcd0a, what's the size? Is it the capacity? Or the
  >  current amount of data written? What if it's unformatted? Or even
  >  on regular disks, the size can be iffy... If you return sectors *
  >  secperunit, are you sure you can write that many bytes (what about
  >  bad sectors)?

 tapes aren't disks; otherwise, it's the number of addressable sectors;
 the point is to know what range of sector addresses are valid, not
 whether writing there will necessarily succeed.

 It seems reasonable to me for an object that needs low-level
 formatting to have size zero until that happens.

 -- 
 David A. Holland
 dholland@netbsd.org

Home	PR Database Search