You are all likely to be suffering from bu id 6633017
JET 4.4.7 has a workaround for this. (in short, your explanation below
summarises the problem, the workaround removes most of the IP config
info from the sysidcfg, and dhcp is able to answer, JET then manually
configs the static info for you. (ish). (Check the bug id, and the
related JET fixed bug.
Mike
Geoff Ongley wrote:
> 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
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL:
<http://mail.opensolaris.org/pipermail/install-discuss/attachments/20081212/ee6db1af/attachment.bin>
