Have a Solaris 10 system that I had to reinstall named gsbgcn2. Blasted an OS to it and configured it. Removed the system from the Update Connection portal and waited 24 hours. Trying to re-register the system today and get the following message box from updatemanager during the final phace of registration:
Invalid System Name(Asset)
I am having a similar and frustrating problem. I also reinstalled Solaris 10 on the same system. Now, when I try to access the update manager, it defaults to the registration wizard, which ultimately tells me my system is invalid or already used, and forbids further progress.
Furthermore, I cannot even unregister the system with the online Update Connection page, because it is not listed there to begin with. How can I cancel and renew my registration on this system?
Anyone from Sun have even a temporary solution to this problem? Have a system here that I can't patch. Sorry, shouldn't say can't, I could by downloading them all and applying everything over and over until they all complete. Still can't re-register this system and it's been deleted for some time.
For my Solaris 10 systems that are going to be production, I'd really like to have some other method to patch them other than Update Connection since it's still really in progress. The older, more reliable plain old smpatch like the one in 8 and 9 would be just fine for now. I really do understand that the Update Connection is not 100% but on the other side I really do need something that will patch the Solaris 10 systems in a reliable manner.
For verification:
Are we talking x86 systems or SPARC systems?
I assume you already tried below procedure?
-
You should be able to re-register using the same system name provided that the 24 hours have passed since you deleted the system on the Sun Update Connection portal
Once you register a system, the system name you choose will be tied to the hostname but we do believe that it would not prevent you from registering, deleting, and then re-registering a different system using the same system name as before.
The procedure below was to fix a particular issue and it is not quite generic:
Procedure to purge portions of the customer's client side Sun Update Connection registry information by execution of some UNIX commands. Followed by steps to re-register the hosts
Assumptions:
o Sun Update Connection 1.0 System Addition is properly installed
o The customer has a valid Contract ID
o The customer has a valid Subscription Key
o The customer has a UNIX background and has root user permissions
Steps:
On each host
1. Launch a terminal session and log in as root
2. Run following command and note the assetid number returned
/usr/lib/cc-ccr/bin/ccr -g cns.assetid
3. Run these exact ccr commands as root, where <ASSETID> = the number returned in above step:
/usr/lib/cc-ccr/bin/ccr -p cns.assetid -v <ASSETID>
and then
/usr/lib/cc-ccr/bin/ccr -p cns.transport.serverurl -v "https://cns-transport.sun.com"
4. Exit the terminal session
5. Launch Update Manager
6. Select the File Menu
7. Select Manage Subscription
8. In the registration wizard, enter the Username /Password /Subscription key (all 3 fields are required)
-
Regarding Sun Update Connection/smpatch, you can still use smpatch only, but you have to make sure not to install patches 119107/119108 as they install Sun Update Connection.
Sparc:
Nope, can't re-register. Deleted and it's been several days now with the same results.
/usr/lib/cc-ccr/bin/ccr -g cns.assetid
gives me:
root@:[root]$ /usr/lib/cc-ccr/bin/ccr -g cns.assetid
root@:[root]$
zero, zip, empty, blank, no results.
Message was edited by: ForumModerator
I've seen this on a couple of machines. Boils down to the backend servers think you're trying to do something sneaky like get more than one system registered with the same contract info or you're trying to spoof another system. We know that in most cases this is *not* true and what is really happening is the hostid/system name/serial numbers aren't matching what is in the backend systems to allow a "re-registration" to happen.
We see this mostly on x86 boxes but can happen whenever a system is rebuilt from scratch.
A work around is to change the hostname to trick the backend into thinking you're adding a brand new host. You can do this by editing /etc/hosts and /etc/hostname.<primary interface> to be a diff name than the previous registrations (I usually just add a digit 1,2,3....depending on how many times I've rebuild the system). This should allow the system to register with the backend. Once registration is complete and you can set the /etc/hosts and /etc/hostname back to normal.
There is a fix in the server code to correct this issue but I don't know when it will be released so until then this is the only way to get around it.
hth,
-m
I'll give that a try today and see what happens.
Register more than one system with the same contract info? Ahh, I use the same contract info for all the systems. We went to one master agreement for all hardware over 2 years ago. It's impossible to maintain separate contacts for every host that's under maintenance.
We have around 30 Sun systems on one contract and all the Sun software on another master agreement. 1 bill every year to pay.
