Can I PXE boot a Sol 10 X4100 off a Sol 8 BOOTP server?
I doubt it, I was able to run add_install_client with -d:
/js/os/sol-10-u1-ga-x86/Solaris_10/Tools/add_install_client -d -s
sunset-qfe0:/js/os/sol-10-u1-ga-x86 -p
sunset-qfe0:/js/jumpstart/yipes/Sysidcfg/Solaris_sol.nm24 -c
sunset-qfe0:/js/jumpstart/yipes dnsback3.yipes.com i86pc
But the interface does not respond. The other two DHCP servers on the subnet also respond, or course they do not know about my server (snoop output):
OLD-BROADCAST -> BROADCASTDHCP/BOOTP DHCPDISCOVER
10.10.12.5 -> BROADCASTDHCP/BOOTP DHCPOFFER
10.10.12.1 -> BROADCASTDHCP/BOOTP DHCPOFFER
OLD-BROADCAST -> BROADCASTDHCP/BOOTP DHCPREQUEST
10.10.12.1 -> BROADCASTDHCP/BOOTP DHCPACK
10.10.12.5 -> BROADCASTDHCP/BOOTP DHCPACK
Does anyone know how to fashion a DHCP response from my 10.10.12.5 box, which is some kind of WIndows DHCP server, to refer the X4100 to my "sunset-qfe0" interface?
[1131 byte] By [
wsanders1] at [2007-11-25 22:36:14]
# 1
Oh, I see - the -d flag on add_Install_server didn't cause anything in /var/dhcp to get updated at all. It did print out the cryptic message:
If not already configured, enable PXE boot by creating
a macro named PXEClient:Arch:00000:UNDI:002001 with:
Boot server IP (BootSrvA) : 10.10.20.41
Boot file(BootFile) : dnsback3.yipes.com
So my guess is the answer is no.
# 2
Another thing I found if that add_install_client prints the wrong IP when used with multi-homed jumpstart hosts. My system has three interfaces, hne0, qfe0, qfe1, and I want to install on the subnet on qfe0:
# /js/os/sol-10-u1-ga-x86/Solaris_10/Tools/add_install_client
-d -s sunset-qfe0:/js/os/sol-10-u1-ga-x86 -p
sunset-qfe0:/js/jumpstart/yipes/Sysidcfg/Solaris_sol.nm24 -c
sunset-qfe0:/js/jumpstart/yipes x4100a.yipes.com i86pc
The IP of sunset-qfe0 is 10.10.12.85, but the message printed out by
add_install_client is:
If not already configured, enable PXE boot by creating
a macro named PXEClient:Arch:00000:UNDI:002001 with:
Boot server IP (BootSrvA) : 10.10.20.41<<< WRONG! that's hme0
Boot file(BootFile) : x4100a.yipes.com
There is an infodoc 84167 that seems to have a lot of Solaris DHCP trivia in it, for interpreting what the line above mean.
It's pretty clear to me by now that Jumpstart and SOlaris DHCP don't interact. It woudl be nice if they did.
# 3
The Solaris DHCP is such a kludge I installed the ISC DHCP server and am well on my way to getting it to work. It is SOOOO EASY! compared to the Solaris one. It took me about 15 minutes instead of spending hours groveling around for all the obscure documentation on dhtadm.
Run it in debug mode, you get:
Listening on DLPI/hme0/08:00:20:b1:e6:c7/10.10.20/24
Sending onDLPI/hme0/08:00:20:b1:e6:c7/10.10.20/24
Sending onSocket/fallback/fallback-net
DHCPDISCOVER from 00:14:4f:20:78:44 via hme0
DHCPOFFER on 10.10.20.201 to 00:14:4f:20:78:44 via hme0
DHCPREQUEST for 10.10.20.201 (10.10.20.41) from 00:14:4f:20:78:44 via hme0
DHCPACK on 10.10.20.201 to 00:14:4f:20:78:44 via hme0
And there is sweet lovely GRUB right on the serial port. It won't boot jumpstart just yet, since I haven't supplied the right parameters to GRUB, but editing the dhcp.conf file is pretty straightforward, it currently contains:
ddns-update-style none;
subnet 10.10.20.0 netmask 255.255.255.0 {
range 10.10.20.200 10.10.20.201;
}
group {
next-server 10.10.20.41;
host x4100a.yipes.com {
hardware ethernet 00:14:4f:1f:9e:70;
filename "pxegrub.I86PC.Solaris_10-1";
}
}
Sun, just drop DHCP from the Solaris distro. You can't even make your proprietary one work with "add_install_client", and why bother?
# 4
After some further reverse-engineering of the X86 Jumpstart process, it looks like Jumpstart makes a second DHCP request for the parameters it used to get first from sysidcfg. This is where all the Sun-specific DHCP parameters come in. With that request being unsuccessful, it make a second try from the sysidcfg file it has been instructed to use in the kernel params (that one enters via add_install_client).
Jumpstart also behaves differently on X86 and SPARC with respect to sysidcfg: On SPARC, it ignores a lot ot imperfections in the sysidcfg file and proceeds with an unattended install anyway in most cases. In X86, if any of the information is missing, it will drop into X windows and ask for eveything all over again, making unattended installation fail if your sysidcfg file is not perfect.
