Re: bin/37415: sysinst should be available after installation

[Marc Balmer <marc%msys.ch@localhost>]

Am 06.03.2012 um 12:55 schrieb Marc Balmer:

> The following reply was made to PR bin/37415; it has been noted by GNATS.
> 
> From: Marc Balmer <marc%msys.ch@localhost>
> To: gnats-bugs%NetBSD.org@localhost
> Cc: 
> Subject: Re: bin/37415: sysinst should be available after installation
> Date: Tue, 6 Mar 2012 12:53:40 +0100
> 
> Am 05.03.2012 um 06:45 schrieb Matthew Mondor:
> 
>> The following reply was made to PR bin/37415; it has been noted by GNATS.
>> 
>> From: Matthew Mondor <mm_lists%pulsar-zone.net@localhost>
>> To: gnats-bugs%NetBSD.org@localhost
>> Cc: 
>> Subject: Re: bin/37415: sysinst should be available after installation
>> Date: Mon, 5 Mar 2012 00:43:41 -0500
>> 
>> On Mon,  5 Mar 2012 05:40:03 +0000 (UTC)
>> David Holland <dholland-bugs%netbsd.org@localhost> wrote:
>> 
>>> however, I think the best way to detect if it's being run from install
>>> media is to have the install media invoke it with some option. An
>>> ordinary user running it won't provide that option (unless they know
>>> what they're doing, etc.)
>> 
>> I think that this makes a lot of sense.
> 
> 
> Yes, no magic trickery, but a clear option, maybe -i


An here is a very good reason to put sysinst in base (i.e. /sbin or /usr/sbin): 
 It can be used to prepare NetBSD disk images that are later deployed e.g. in 
an embedded system.  To prepare CF disks, for example.  Usage could be 'sysinst 
<device>'.  And then, I think it does not really matter if sysinst comes from 
boot media are not, but rather whether it is being execute on the final target 
or nor.  An option -T could indicate that sysinst runs on the target, and 
ramdisks with installers would invoke sysinst as 'sysinst -T'.