Hi All,
I believe I have hit the same problem and have a theory (though maybe its just
similar), and a partial work around (not removing the subnet mask from
sysidcfg).
The configuration I'm using to test/work on this is a JET box with Sun DHCP
Server, Solaris 10 u5 and Solaris 10 u6.
When you boot with Update 5, you are all fine as mentioned.
Update 6 fails, and I believe the reason for this is it attempts (when we do a
dhcpinfo at this point of the installation), and the interface is not in dhcp
control.
It goes something like this:
######################################
{0} ok boot net:dhcp - install
.
.
.
Completing system identification...
Starting remote procedure call (RPC) services: done.
System identification complete.
Starting Solaris installation program...
Searching for JumpStart directory...
/sbin/dhcpinfo: primary interface requested but no primary interface is set
not found
Warning: Could not find matching rule in rules.ok
Press the return key for an interactive Solaris install program...
Executing JumpStart preinstall phase...
##################################################
Option Code 14 tells us where to locate rules.ok, so if we can't find that
option code (because of the dhcpinfo error), then we don't know what server to
ask for the rules.ok or where on that server to look (option code 14 looks like
<ip address>:/opt/SUNWjet)
If you then bail to the command line at this point to run dhcpinfo manually,
you'll find it does not work (which is expected once you notice the interface
is NOT in DHCP control):
###################
bge0: flags=1000863<UP,BROADCAST,NOTRAILERS,RUNNING,MULTICAST,IPv4> mtu 1500
index 1
###################
(note: no DHCP flag).
If you then try to get a dhcp address with the interface in this state, with
ifconfig bge0 dhcp, it hangs, and there is no response from the Sun DHCP
server. Make sure you ifconfig bge0 0 the interface first to drop its address.
If you don't, tt appears the Sun DHCP server gets an echo response from the
client (presumably does this to avoid handing out an address that is set
statically on the network), and proceeds to disable the ip from being used, and
as such, never responds to the DHCP query.
On the Sun DHCP server:
#######################################################
Dec 11 11:42:42 infpssm005 in.dhcpd[8488]: [ID 720561 daemon.warning] ICMP ECHO
reply to OFFER candidate: <TheIPAddress>, disabling.
Dec 11 11:42:46 infpssm005 in.dhcpd[8488]: [ID 205727 daemon.notice]
(0100144F6FF026,<TheIPAddress>) currently marked as unusable.
Dec 11 11:42:46 infpssm005 in.dhcpd[8488]: [ID 986651 daemon.warning] Client:
0100144F6FF026 MANUAL record <TheIPAddress> is UNUSABLE. No other IP address
will be allocated.
Dec 11 11:42:54 infpssm005 in.dhcpd[8488]: [ID 205727 daemon.notice]
(0100144F6FF026,<TheIPAddress>) currently marked as unusable.
#########################################################
To prove this theory, rebooted the client, set the address in Sun DHCP back to
reserved, and then bailed back to the command line on the jumpstart client.
ifconfig bge0 0
then
ifconfig bge0 dhcp
works fine, and gets an address. You can then correctly use dhcpinfo to get
option code 14.
Anywho, from here, presuming you have manually done a dhcp correctly after
bailing to the command line from the interactive installer (as above) when the
interface is in DHCP control, you can now continue non-interactively by kicking
off a:
# install-solaris
which now with the interface in DHCP control correctly finds rules.ok, and
jumpstart works as normal.
To verify this I checked in update 5 the interface is in DHCP control at this
point of the installtion, (if you force it to bail in the same manner by moving
rules.ok out of the way, and then check the flags at the command line):
##########################################
# ifconfig bge0
bge0: flags=1004863<UP,BROADCAST,NOTRAILERS,RUNNING,MULTICAST,DHCP,IPv4> mtu
1500 index 1
###########################################
So it appears to me, when you boot update 6 from jumpstart, it is setting the
IP address statically, rather than dynamically as in previous releases (even
though we're using dhcp to boot initially)
When the interface is set statically, you cannot use dhcpinfo to get option
code 14 (the one that tells it where to find rules.ok)
And of course, if you don't know where to look for rules.ok, you can't find it,
and you get the failure discussed here.
With update 5, the interface is configured with DHCP still at this point and as
such works fine, as dhcpinfo can query option code 14 from the interface.
Thoughts?
-Geoff Ongley
--
This message posted from opensolaris.org
