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:
(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.