NetBSD Problem Report #54201

From www@netbsd.org  Sun May 12 23:18:16 2019
Return-Path: <www@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 281A87A16F
	for <gnats-bugs@gnats.NetBSD.org>; Sun, 12 May 2019 23:18:16 +0000 (UTC)
Message-Id: <20190512231814.8150E7A1D2@mollari.NetBSD.org>
Date: Sun, 12 May 2019 23:18:14 +0000 (UTC)
From: thorpej@me.com
Reply-To: thorpej@me.com
To: gnats-bugs@NetBSD.org
Subject: disklabel(8) annoyingly overrides user intent when run as a "native" tool
X-Send-Pr-Version: www-1.0

>Number:         54201
>Category:       bin
>Synopsis:       disklabel(8) annoyingly overrides user intent when run as a "native" tool
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    bin-bug-people
>State:          feedback
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun May 12 23:20:00 +0000 2019
>Closed-Date:    
>Last-Modified:  Fri May 31 11:34:16 +0000 2019
>Originator:     Jason Thorpe
>Release:        8.99.37
>Organization:
Jason's messy garage of hackery
>Environment:
NetBSD netbsd-vm 8.99.37 NetBSD 8.99.37 (GENERIC) #19: Mon Apr 15 08:49:13 PDT 2019  thorpej@BigMac.local:/Volumes/Data0/Users/thorpej/hack/NetBSD/current/netbsd-src/sys/arch/amd64/compile/GENERIC amd64

>Description:
The -m flag for disklabel(8) behaves differently when build as a host tool vs run as a native tool with a different target machine.  In my scenario, I was attempting to write a disklabel to a NetBSD MBR partition for evbmips.  This failed when run as a "native" tool with -M evbmips on NetBSD/amd64, but succeeded when the host tool (nbdisklabel) was run with the same arguments.

The handling of the -m flag seems unnecessarily complex in the disklabel(8) code, and also seems that how it works to lead to user confusion.
>How-To-Repeat:
Use disklabel -m as a "native" tool with a different target machine that does not normally "use mbr".
>Fix:
Unknown.

>Release-Note:

>Audit-Trail:
From: mlelstv@serpens.de (Michael van Elst)
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: bin/54201: disklabel(8) annoyingly overrides user intent when run as a "native" tool
Date: Mon, 13 May 2019 05:14:05 -0000 (UTC)

 thorpej@me.com writes:

 >The handling of the -m flag seems unnecessarily complex in the disklabel(8) code, and also seems that how it works to lead to user confusion.

 Maybe this:

 Index: main.c
 ===================================================================
 RCS file: /cvsroot/src/sbin/disklabel/main.c,v
 retrieving revision 1.50
 diff -p -u -r1.50 main.c
 --- main.c	27 Jun 2018 01:14:48 -0000	1.50
 +++ main.c	13 May 2019 05:12:38 -0000
 @@ -154,7 +154,6 @@ static	int	tflag;		/* Format output as d
  static	int	Dflag;		/* Delete old labels (use with write) */
  static	int	Iflag;		/* Read/write direct, but default if absent */
  static	int	lflag;		/* List all known file system types and exit */
 -static	int	mflag;		/* Expect disk to contain an MBR */
  static int verbose;
  static int read_all;		/* set if op = READ && Aflag */

 @@ -481,6 +480,7 @@ main(int argc, char *argv[])
  #endif
  		DELETE
  	} op = UNSPEC, old_op;
 +	unsigned long val;

  #ifndef HAVE_NBTOOL_CONFIG_H
  #if !defined(NATIVELABEL_ONLY)
 @@ -502,22 +502,13 @@ main(int argc, char *argv[])
  	}
  #endif

 -	mflag = labelusesmbr;
 -	if (mflag < 0) {
 -#if HAVE_NBTOOL_CONFIG_H
 -		warn("getlabelusesmbr() failed");
 -#else
 -		warn("getlabelusesmbr() failed");
 -		mflag = LABELUSESMBR;
 -#endif
 -	}
  #if HAVE_NBTOOL_CONFIG_H
  	/* We must avoid doing any ioctl requests */
  	Fflag = rflag = 1;
  #endif

  	error = 0;
 -	while ((ch = getopt(argc, argv, "AB:CDFIM:NRWef:ilmrtvw")) != -1) {
 +	while ((ch = getopt(argc, argv, "AB:CDFIL:M:NO:P:RWef:ilmnrtvw")) != -1) {
  		old_op = op;
  		switch (ch) {
  		case 'A':	/* Action all labels */
 @@ -559,6 +550,24 @@ main(int argc, char *argv[])
  		case 'N':	/* Disallow writes to label sector */
  			op = SETREADONLY;
  			break;
 +		case 'L':	/* Label sector */
 +			val = strtoul(optarg, NULL, 10);
 +			if ((val == ULONG_MAX && errno == ERANGE) || val > UINT_MAX)
 +				err(EXIT_FAILURE, "invalid label sector: %s", optarg);
 +			labelsector = val;
 +			break;
 +		case 'O':	/* Label offset */
 +			val = strtoul(optarg, NULL, 10);
 +			if ((val == ULONG_MAX && errno == ERANGE) || val > UINT_MAX)
 +				err(EXIT_FAILURE, "invalid label offset: %s", optarg);
 +			labeloffset = val;
 +			break;
 +		case 'P':	/* Max partitions */
 +			val = strtoul(optarg, NULL, 10);
 +			if ((val == ULONG_MAX && errno == ERANGE) || val > UINT_MAX)
 +				err(EXIT_FAILURE, "invalid max partitions: %s", optarg);
 +			maxpartitions = val;
 +			break;
  		case 'W':	/* Allow writes to label sector */
  			op = SETWRITABLE;
  			break;
 @@ -578,7 +587,10 @@ main(int argc, char *argv[])
  			lflag = 1;
  			break;
  		case 'm':	/* Expect disk to have an MBR */
 -			mflag ^= 1;
 +			labelusesmbr = 1;
 +			break;
 +		case 'n':	/* Expect disk to not have an MBR */
 +			labelusesmbr = 0;
  			break;
  		case 'r':	/* Read/write label directly from disk */
  			rflag = 1;
 @@ -989,7 +1001,7 @@ readlabel_mbr(int f, u_int sector)
  static int
  writelabel_mbr(int f, u_int sector)
  {
 -	return update_label(f, sector, mflag ? LABELOFFSET_MBR : ~0U) ? 2 : 0;
 +	return update_label(f, sector, labelusesmbr ? LABELOFFSET_MBR : ~0U) ? 2 : 0;
  }

  #endif	/* !NO_MBR_SUPPORT */
 @@ -1369,7 +1381,7 @@ readlabel_direct(int f)
  		}
  	}

 -	if (mflag && process_mbr(f, readlabel_mbr) == 0)
 +	if (labelusesmbr && process_mbr(f, readlabel_mbr) == 0)
  		return 0;

  	disk_lp = find_label(f, 0);
 @@ -1378,7 +1390,7 @@ readlabel_direct(int f)
  		return 0;
  	}

 -	if (!mflag && process_mbr(f, readlabel_mbr) == 0)
 +	if (!labelusesmbr && process_mbr(f, readlabel_mbr) == 0)
  		return 0;

  	return 1;

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

State-Changed-From-To: open->feedback
State-Changed-By: maya@NetBSD.org
State-Changed-When: Fri, 31 May 2019 11:34:16 +0000
State-Changed-Why:
engage gnats pestering abilities!


>Unformatted:

Home	PR Database Search