In article <1118406252.449684.185530@g43g2000cwa.googlegroups .com>,
chadmjohn@gmail.com wrote:

> Per the documentation you are correct. But you can do this (I haven't
> made it that far yet) by modifying the information on your boot media.

So, how would this work on a bare metal machine?

>
> Basically you make a 'jumpstart on cd' system but instead of installing
> from the cd itself the target system obtains it's profile information
> from the remote location. I can see it is possible but was hoping
> someone had already done the *hacking* of the /etc/rcS script in the
> jumpstart system to do it.

This part of the install (the Solaris kernel install) shouldn't be a
problem. It's done via an NFS mount, so you don't need to do this.
Unless I'm missing something on what you're saying...

>
> Also, DHCP booting is only available in the more current boot proms and
> I have a large array of systems (old & new) to deal with.

Yep. That pretty much puts you into the RAPR camp.

>
> Some routers can be configured to forward RARP requests but this is not
> standard (so not reliable).
>
> Thanks.

From what I recall (before the days of DHCP Jumpstart), the bootstap
process is the following:

-> client bootprom issues rarp request to host
<- boot host returns ip address from boot host rarpd's
reading /etc/ethers or ethers map OR dhcp host returns
ip address and bootfile
-> client boot prom issues tftp request
<- boot host returns tftpd reading /tftpboot/IPADDR
(linked to inetboot for arch) OR bootfile dhcp host sent
-> client runs inetboot which issues whoami to boothost
or dhcp host to obtain boot parameters
<- boot or dhcp host returns bootparamd's hostname from /etc/hosts
or host map
-> client's inetboot issues getfile to host
<- boot host's bootparamd reads /etc/bootparams to
get client's root location if dhcp is not used
-> client's inetboot issues NFS mount of root filesystem
on responding host
-> client's inetboot opens and reads kernel of NFS mounted root

So the rarp/boot server has to be on the same segment as the client (or
the server is multi-homed). If you use dhcp, it can be anywhere on the
network, even across routers. The load server can be on another net
or can be on the same system as the boot server.

Configuration files:

/etc/hosts
/etc/ethers
/etc/dfs/dfstab (to serve the root filesystems)
/etc/bootparams
/tftpboot/IPADDR -> inetboot for specific architecture and OS


No matter what way you slice this, I think you're SOL without DHCP or a
multi-homed boot server. If you want to "roll your own" network boot,
great. But the sysadmin that replaces you will most likely scrap it and
curse your name and your children's children.

Good luck. You need it.

--
DeeDee, don't press that button! DeeDee! NO! Dee...