If the customer environment has a configuration where the machines 
ALWAYS PXE boot, then it is highly likely that they have their own 
mechanism for manipulating the menu.lst to provide the correct boot 
environment. We have no idea what configuration that is, therefore we 
cannot design for it.

We should ONLY consider the case where a one-off PXE boot is configured.

The people who do always PXE boot will be able to augment our stuff to 
fit their needs.

Just my 2 cents.

Alok Aggarwal wrote:
>
> On Thu, 25 Jun 2009, Dave Miner wrote:
>
>>> So, how does it work when I want to script the menu.lst
>>> such that the machine does AI once and then just does, say,
>>> a network boot (if that's what the boot order has set)
>>> thereafter?
>>>
>>
>> It's more usual to selectt network boot as a one-time, not 
>> persistently in the BIOS or OBP.  If you need to do the latter for 
>> some reason, then it's not going to work, but since most reasonable 
>> BIOS versions allow the former easily (and OBP always has), providing 
>> an optimal solution for that case seems wise.
>
> OBP isn't much of a problem because -
>
> a) AI would only be invoked by the user explicitly
>    specifying "boot net:dhcp - install" on the command
>    line
> b) The OS can dictate that the machine boot from disk
>    after an initial AI.
>
> So, even if the user has "boot net" set in the OBP, AI
> isn't going to get invoked accidentally and reinstall
> the installed system.
>
> BIOS is more of a problem because the OS cannot dictate
> the boot order. I agree that network boot won't be selected as the 
> default in 90% of the cases, but it
> would be selected in 10% of the cases for diagnostic
> purposes.
>
> And, for those 10% cases AI shouldn't be automatically
> invoked. The proposed solution does make it harder for
> the majority but it also protects the minority.
>
> I'm sorry if I'm being dense here but I just don't see
> how scripting menu.lst makes it easy for the majority
> and safe for the minority at the same time. Could you
> please elaborate?
>
> Alok
> _______________________________________________
> caiman-discuss mailing list
> caiman-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3262 bytes
Desc: S/MIME Cryptographic Signature
URL: 
<http://mail.opensolaris.org/pipermail/caiman-discuss/attachments/20090626/0891eeca/attachment.bin>

Reply via email to