Rick Miller wrote: > This is not OpenSolaris specific, but relates to Solaris 10 10/09 JumpStart > over the network. We are not using a traditional environment. We are > installing Solaris from a Linux OS. The end result is that the client's are > installed via the JumpStart mechanism. However, the PXE modules and boot > loaders are written in-house > I'm curious why you needed to write anything 'in-house'? Just because the pxegrub, included on the Solaris CD was written by sun, doesn't mean it requires a Solaris machine to serve it.
It's true that running 'setup-install-server' might be tough on a Linux server, but this is what I have done: 1. Mounted the Solaris 10 DVD iso on the Linux machine, and shared it via NFS 2. Loop-back mounted the bootin sub dir (I don't have the exact path in front of me right now.) - the one with the kernel, miniroot, and pxegrub in it. 3. Create the pxegrub menu.lst file to find the root NFS fs, install dvd NFS share, custom jumpstart area, sysidcfg file if needed. 4. Configure DHCP to assign an address to the clients, and respond with the GRUB site DHCP option set to the path to the menu.lst for this client. This is from memory, so there might be one or two small things I missed, but the point is you can (if you want to) server all the binaries that a Solaris server would serve from a Linux server. If you prefer, I beleive you might even be able to subsitute pxelinux for pxegrub, but I've never seen a reason to. I actually Net-boot and install all flavors of Linux using the Sun Solaris supplied pxegrub, and ignore pxelinux altogether. If this sounds like it will help you out. I can get you more info. -Kyle > We have found recently that when we attempt to boot and install the Solaris > 10 x86 OS onto a client, that the client exits install-discovery citing the > inability to configure the interfaces. Through poking around, I have found > that bootmac, hostip, netmask, and def_route are not set in the /devices tree > and this is why install-discovery quits. > > If I run /sbin/netstrategy, it returns "ufs none none" after > install-discovery has errored out. Executing the same from a working > environment after ctrl-C'ing install-discovery returns "ufs $int dhcp" > (where $int is the primary interface in the chassis). > > In analysing packet captures in a working and non-working environment, we > have found that in the working environment, the observed behavior is 2 DHCP > discovers (one from PXE; the second from Solaris when loading the Solaris > environment) while in our non-working environment we observe only the first > DHCP discover from PXE. > > I am trying to identify at what point our failure is occurring, but am unsure > how the variables identified above are populated in the /devices tree. I am > hoping that someone here might be able to guide me in the right direction to > identify the point and cause of failure. >
