NetBSD Problem Report #39728

From mouse@Sparkle.Rodents-Montreal.ORG  Sun Oct 12 01:36:09 2008
Return-Path: <mouse@Sparkle.Rodents-Montreal.ORG>
Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11])
	by narn.NetBSD.org (Postfix) with ESMTP id 55DC663B88A
	for <gnats-bugs@gnats.NetBSD.org>; Sun, 12 Oct 2008 01:36:09 +0000 (UTC)
Message-Id: <200810120136.VAA27368@Sparkle.Rodents-Montreal.ORG>
Date: Sat, 11 Oct 2008 21:31:52 -0400 (EDT)
From: der Mouse <mouse@Rodents-Montreal.ORG>
Reply-To: mouse@Rodents-Montreal.ORG
To: gnats-bugs@gnats.NetBSD.org
Subject: [dM] sparc installboot unreasonably picky
X-Send-Pr-Version: 3.95

>Number:         39728
>Category:       port-sparc
>Synopsis:       [dM] sparc installboot unreasonably picky
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    port-sparc-maintainer
>State:          open
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Sun Oct 12 01:40:00 +0000 2008
>Closed-Date:    
>Last-Modified:  Mon Oct 13 06:40:02 +0000 2008
>Originator:     der Mouse
>Release:        NetBSD 3.1
>Organization:
	Dis-
>Environment:
	The subject system is not yet set up to the point where running
	send-pr on it is reasonably easy; its uname -a is
NetBSD SPARC 3.1 NetBSD 3.1 (GEN31) #1: Sat Oct 11 21:36:17 UTC 2008  root@SPARC:/home/mouse/kbuild/GEN31 sparc
>Description:
	When installboot is asked to install bootblocks on a secondary
	disk, it fails gratuitously.  For example, single-user with
	sd1a mounted on /mnt:

	SPARC# installboot -v /dev/rsd1a /usr/mdec/bootxx /mnt/boot
	File system:         /dev/rsd1a
	File system type:    ffs (blocksize 8192, needswap 0)
	Primary bootstrap:   /usr/mdec/bootxx
	Secondary bootstrap: /mnt/boot
	installboot: The secondary bootstrap `mnt/boot' must be in /
	installboot: Set bootstrap operation failed

	In this particular case, it worked to chroot to /mnt and run
	installboot within the chroot.  But this is not satisfactory
	for multiple reasons: (1) it works only for root, while there's
	no reason installboot shouldn't work for anyone who can write
	to the relevant disk; (2) it requires there be an OS already
	installed in the filesystem; (3) it requres that that OS's
	installboot run under the currently-booted kernel.  (Depending
	on whether the message means "in the / directory" or "on the /
	filesystem", there might be another issue in that there's no
	reason except installboot fiat that the second-stage bootblocks
	can't be anywhere on the boot partition.)

	For example, this makes it impossible to set up something I've
	done numerous times under other releases, with a small boot
	partition with bootblocks and kernels but no OS, and a kernel
	configured to get root from a specific (other) partition.  I'd
	have to put enough of an OS on the boot partition to run
	installboot, which _really_ shouldn't be necessary.
>How-To-Repeat:
	Boot a 3.1 SPARC single-user.  Put a filesystem on a secondary
	disk.  Mount it, copy a /boot to it, and try to use installboot
	to install first-stage bootblocks.
>Fix:
	None yet; getting the machine set up takes priority for now.
	If nobody else gets to this first, I'll send in a fix once it
	irritates me into prying loose the round tuits to fix it.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse@rodents-montreal.org
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

>Release-Note:

>Audit-Trail:
From: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
To: gnats-bugs@NetBSD.org
Cc: port-sparc-maintainer@NetBSD.org, gnats-admin@NetBSD.org,
        netbsd-bugs@NetBSD.org, tsutsui@ceres.dti.ne.jp
Subject: Re: port-sparc/39728: [dM] sparc installboot unreasonably picky
Date: Sun, 12 Oct 2008 11:20:48 +0900

 > >Synopsis:       [dM] sparc installboot unreasonably picky

 > 	SPARC# installboot -v /dev/rsd1a /usr/mdec/bootxx /mnt/boot
  :
 > 	installboot: The secondary bootstrap `mnt/boot' must be in /

 The secandary bootstrap arg should be an absolute path
 in the specified file system.
 (otherwise you can't installboot unmounted file system)

 You don't have to include a current mount point of it, i.e.
 "installboot -v /dev/rsd1a /usr/mdec/bootxx /boot"
 should work even if the file system is mounted on /mnt.
 ---
 Izumi Tsutsui

From: der Mouse <mouse@Rodents-Montreal.ORG>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: port-sparc/39728: [dM] sparc installboot unreasonably picky
Date: Sat, 11 Oct 2008 22:44:47 -0400 (EDT)

 >> 	installboot: The secondary bootstrap `mnt/boot' must be in /
 > The secandary bootstrap arg should be an absolute path in the
 > specified file system.

 ...oh!  Thank you.

 Okay then, it's just that the message is confusing.  I'll reprioritize
 the PR.

 This, I say mostly to get it into the PR: what I'd suggest (and
 implement, if I'm the one who ends up fixing it) is something like

 	installboot: /mnt/boot: No such file or directory
 	installboot: (Path must be relative to the filesystem root.)

 (where the "No such..." is actually obtained from strerror(ENOENT), for
 consistency).

 /~\ The ASCII				  Mouse
 \ / Ribbon Campaign
  X  Against HTML		mouse@rodents-montreal.org
 / \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

From: "Greg A. Woods; Planix, Inc." <woods@planix.ca>
To: gnats-bugs@NetBSD.org
Cc: port-sparc-maintainer@netbsd.org,
 mouse@Rodents-Montreal.ORG
Subject: Re: port-sparc/39728: [dM] sparc installboot unreasonably picky
Date: Sun, 12 Oct 2008 10:26:32 -0400

 This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
 --Apple-Mail-17-701256597
 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
 Content-Transfer-Encoding: 7bit


 On 11-Oct-08, at 10:55 PM, der Mouse wrote:
 >>> 	installboot: The secondary bootstrap `mnt/boot' must be in /
 >> The secandary bootstrap arg should be an absolute path in the
 >> specified file system.
 >
 > ...oh!  Thank you.
 >
 > Okay then, it's just that the message is confusing.  I'll reprioritize
 > the PR.

 Indeed, it is _very_ confusing.  I had to read the source, twice, to  
 try to figure out what I was doing wrong.  The second time I finally  
 added the following to my notes:

      - install the boot program(s):

        sparc:

          # cp /usr/mdec/boot /stand-sd1
          # installboot -v /dev/rsd1c /usr/mdec/bootxx /boot
          (it means the location of boot within the root of sd1a)


 > This, I say mostly to get it into the PR: what I'd suggest (and
 > implement, if I'm the one who ends up fixing it) is something like
 >
 > 	installboot: /mnt/boot: No such file or directory
 > 	installboot: (Path must be relative to the filesystem root.)
 >
 > (where the "No such..." is actually obtained from strerror(ENOENT),  
 > for
 > consistency).


 That would help somewhat for sure.

 The manual page, if it is read very carefully and completely, is  
 reasonably clear about this parameter now too, though unfortunately  
 that manual page is very dense and complex now that it deals with so  
 many options and features and tries to cover all kinds of systems.

 -- 
 					Greg A. Woods; Planix, Inc.
 					<woods@planix.ca>


 --Apple-Mail-17-701256597
 content-type: application/pgp-signature; x-mac-type=70674453;
 	name=PGP.sig
 content-description: This is a digitally signed message part
 content-disposition: inline; filename=PGP.sig
 content-transfer-encoding: 7bit

 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.4.8 (Darwin)

 iD8DBQFI8gkYZn1xt3i/9H8RAqV7AKDGPzY7FwxcFcrPWewZIcym0p9XpwCfSEOw
 FhGzC0vlrS217kEGCUf/9TM=
 =4HWl
 -----END PGP SIGNATURE-----

 --Apple-Mail-17-701256597--

From: Alan Barrett <apb@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/39728 CVS commit: src/usr.sbin/installboot
Date: Sun, 12 Oct 2008 16:02:45 +0000 (UTC)

 Module Name:	src
 Committed By:	apb
 Date:		Sun Oct 12 16:02:45 UTC 2008

 Modified Files:
 	src/usr.sbin/installboot: installboot.8

 Log Message:
 Try to improve documentation of the fact that the primary bootstrap is
 specified using a file name on the running system, while the secondary
 bootstrap is specified using a file name relative to the root of the
 file systrem in which the installation is being performed.

 Inspired by PR 39728 by der Mouse


 To generate a diff of this commit:
 cvs rdiff -r1.71 -r1.72 src/usr.sbin/installboot/installboot.8

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

From: Alan Barrett <apb@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/39728 CVS commit: src/usr.sbin/installboot
Date: Sun, 12 Oct 2008 16:03:27 +0000 (UTC)

 Module Name:	src
 Committed By:	apb
 Date:		Sun Oct 12 16:03:27 UTC 2008

 Modified Files:
 	src/usr.sbin/installboot: ext2fs.c ffs.c

 Log Message:
 Try to improve warning messages when stage2 bootstrap is not found
 in the root of the file systrem in which the installation is being
 performed.

 Inspired by PR 39728 by der Mouse


 To generate a diff of this commit:
 cvs rdiff -r1.2 -r1.3 src/usr.sbin/installboot/ext2fs.c
 cvs rdiff -r1.25 -r1.26 src/usr.sbin/installboot/ffs.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

State-Changed-From-To: open->feedback
State-Changed-By: apb@NetBSD.org
State-Changed-When: Sun, 12 Oct 2008 16:26:44 +0000
State-Changed-Why:
Are the new warning messages and updated man page good enough?


From: der Mouse <mouse@Rodents-Montreal.ORG>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: PR/39728 CVS commit: src/usr.sbin/installboot
Date: Sun, 12 Oct 2008 12:44:29 -0400 (EDT)

 With apb's changes, the only thing left to do here is to lift the
 restriction-by-fiat on /boot being directly in the root directory;
 there's no reason it can't be anywhere in the filesystem.  (I suspect,
 currently without evidence, that this is for code convenience, so
 installboot doesn't have to be able to do a full path walk.  I may try
 to write up some doc changes if that's how it looks when I get around
 to looking at it, since it's fairly easy to work around this by mving
 the file after running installboot.)

 It's also possible for all I know that there is no such restriction,
 but in that case I would have expected apb to have updated the "must be
 in /" message when adding the "relative to" message.

 /~\ The ASCII				  Mouse
 \ / Ribbon Campaign
  X  Against HTML		mouse@rodents-montreal.org
 / \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

State-Changed-From-To: feedback->open
State-Changed-By: mouse@NetBSD.org
State-Changed-When: Sun, 12 Oct 2008 16:54:36 +0000
State-Changed-Why:
The only remaining part is now more accurately a change-request, so I
reclassified the PR.  The resulting change-request is now more properly
open rather than in feedback.


From: Alan Barrett <apb@cequrux.com>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: PR/39728 CVS commit: src/usr.sbin/installboot
Date: Sun, 12 Oct 2008 19:15:05 +0200

 On Sun, 12 Oct 2008, der Mouse wrote:
 >  With apb's changes, the only thing left to do here is to lift the
 >  restriction-by-fiat on /boot being directly in the root directory;
 >  there's no reason it can't be anywhere in the filesystem.  (I suspect,
 >  currently without evidence, that this is for code convenience, so
 >  installboot doesn't have to be able to do a full path walk.

 In the case of primary boot loaders that contain a list of file system
 block numbers for the secondary boot loader, the restriction that the
 second stage boot loader must be in the root directory does indeed
 appear to be purely for the convenience of installboot(8).

 Some primary boot loaders may have other restrictions; for example the
 i386 bootxx_ffs* primary boot loaders expect to find the secondary boot
 loader in a file named "boot" in the root directory, and this is not
 configurable.  (See PR 39736)

 --apb (Alan Barrett)

From: der Mouse <mouse@Rodents-Montreal.ORG>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: PR/39728 CVS commit: src/usr.sbin/installboot
Date: Sun, 12 Oct 2008 13:43:49 -0400 (EDT)

 >> [...] the restriction-by-fiat on /boot being directly in the root
 >> directory; there's no reason it can't be anywhere in the filesystem.
 > In the case of primary boot loaders that contain a list of file
 > system block numbers for the secondary boot loader, the restriction
 > that the second stage boot loader must be in the root directory does
 > indeed appear to be purely for the convenience of installboot(8).

 And this _is_ a port-sparc PR.

 > Some primary boot loaders may have other restrictions;

 Which is fine; let those ports' installboots (or, rather, installboot
 when run for such a port) impose corresponding restrictions.  There's
 no reason sparc needs to be (or should be) saddled with i386's
 restrictions, any more than conversely.

 /~\ The ASCII				  Mouse
 \ / Ribbon Campaign
  X  Against HTML		mouse@rodents-montreal.org
 / \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

From: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
To: gnats-bugs@NetBSD.org
Cc: port-sparc-maintainer@NetBSD.org, gnats-admin@NetBSD.org,
        netbsd-bugs@NetBSD.org, mouse@Rodents-Montreal.ORG,
        tsutsui@ceres.dti.ne.jp
Subject: Re: PR/39728 CVS commit: src/usr.sbin/installboot
Date: Mon, 13 Oct 2008 03:19:51 +0900

 >  With apb's changes, the only thing left to do here is to lift the
 >  restriction-by-fiat on /boot being directly in the root directory;
 >  there's no reason it can't be anywhere in the filesystem.

 Possible, but no benefits even on sparc.
 It just increases size of installboot(8), which is in ~all install media.
 ---
 Izumi Tsutsui

From: der Mouse <mouse@Rodents-Montreal.ORG>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: PR/39728 CVS commit: src/usr.sbin/installboot
Date: Mon, 13 Oct 2008 02:05:09 -0400 (EDT)

 >> With apb's changes, the only thing left to do here is to lift the
 >> restriction-by-fiat on /boot being directly in the root directory;
 >> there's no reason it can't be anywhere in the filesystem.
 > Possible, but no benefits even on sparc.

 Simplicity; it avoids having to understand the boot sequence enough to
 know you can mv /boot after installbooting and have it continue to
 work.  (And as for why you'd want to do that, perhaps to keep / clean?
 I don't like forbidding things for no good reason.)

 >  It just increases size of installboot(8), which is in ~all install
 >  media.

 Good point; if this is done it probably should be done #ifdef
 NO_SIZE_CONSTRAINTS or some such, and the maintenance load created
 thereby probably isn't worth the (marginal) benefit.

 If/when I deal with it, I'll probably just document the mv workaround,
 rather than changing the code, since it's a reasonable workaround and I
 can't think of any circumstance where it's onerous; if anyone can, this
 can be revisited then in light of it.

 /~\ The ASCII				  Mouse
 \ / Ribbon Campaign
  X  Against HTML		mouse@rodents-montreal.org
 / \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

From: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
To: gnats-bugs@NetBSD.org
Cc: port-sparc-maintainer@NetBSD.org, gnats-admin@NetBSD.org,
        netbsd-bugs@NetBSD.org, mouse@Rodents-Montreal.ORG,
        tsutsui@ceres.dti.ne.jp
Subject: Re: PR/39728 CVS commit: src/usr.sbin/installboot
Date: Mon, 13 Oct 2008 15:35:46 +0900

 >  Simplicity; it avoids having to understand the boot sequence enough to
 >  know you can mv /boot after installbooting and have it continue to
 >  work.  (And as for why you'd want to do that, perhaps to keep / clean?
 >  I don't like forbidding things for no good reason.)

 Why do you ignore simplicity of installboot?
 There is no benefits for me to make installboot more complex
 in exchange only for keeping / clean.

 If you really want such a perfect world, the right thing to do
 is to implement file system aware primary bootloaders like
 alpha, i386 and pmax etc.

 Anyway, please close the original PR and file new one for it
 with a proper synopsis, or implement it yourself.
 ---
 Izumi Tsutsui

>Unformatted:

NetBSD Home
NetBSD PR Database Search

(Contact us) $NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2007 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.