[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: bin/37415: sysinst should be available after installation
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
> 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
>> 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'.
Main Index |
Thread Index |