I’ve been attempting to install OES and/or SLES for a couple of weeks now with no success. My best attempts have been installing just SLES 11 SP2 or installing it with OES with edirectory. The install of just SLES SP2 lets me enter the registration code and says it’s successful but gives me an error that it failed to find media1 and the details show that the connection to https://nu.novell.com… failed due to an invalid certificate. This also prevents me from updating manually. Now if I install with the OES addon and edirectory I do not get this issue. The update screen after entering the registrations codes does not appear but I can run it manually after the install. The system seems to run fine, screens load quickly, I can browse directories without issue etc. I run the online updater and install the set of updates it recommends and reboot and everything still seems fine. Then I run the update again which installs the remaining updates in the list and that is when the server slows down to a crawl. Load takes forever, login takes probably 2 minutes. Loading Yast for instance takes 45 seconds to a minute before the window even appears where before the update it’s almost instant. Browsing directories is hit and miss both from the terminal and the file browser. Most open quickly but some freeze the screen for a couple of minutes.
So I run into issues with the update either way I go. One way is no updating at all, the other the updates install and the system becomes unusable.
I was also asked to provide this:
LSB_VERSION="core-2.0-noarch:core-3.2-noarch:core-4.0-noarch:core-2.0-x86_64:core-3.2-x86_64:core-4.0-x86_64"
Novell Open Enterprise Server 11 (x86_64)
VERSION = 11.1
PATCHLEVEL = 1
SUSE Linux Enterprise Server 11 (x86_64)
VERSION = 11
PATCHLEVEL = 2
more details may be available in ~root/.suse_register.log . I scanned the original thread and found both an indication that much of this may be new to you and no indication that anyone asked to have a look at it. “.suse_register.log” is the log file of the process that is run to register your system with the NCC - no matter if from command line (“man suse_register”) or from YaST.
Sometimes, the visual front ends make assumptions on why a command fails - looking at the log files, you then may find out that the original cause was somewhere different… so may I ask you to look at that file? (It retains historic entries, so even if those registration attempts have been days ago, you out to find some traces in there) If you wish, you can provide appropriate parts of the content here (please make sure no confidential information is included, when doing c&p to this forum ).
more details may be available in ~root/.suse_register.log . I scanned the original thread and found both an indication that much of this may be new to you and no indication that anyone asked to have a look at it. “.suse_register.log” is the log file of the process that is run to register your system with the NCC - no matter if from command line (“man suse_register”) or from YaST.
Sometimes, the visual front ends make assumptions on why a command fails - looking at the log files, you then may find out that the original cause was somewhere different… so may I ask you to look at that file? (It retains historic entries, so even if those registration attempts have been days ago, you out to find some traces in there) If you wish, you can provide appropriate parts of the content here (please make sure no confidential information is included, when doing c&p to this forum ).
Regards,
Jens[/QUOTE]
I actually found the probable cause of this one late last night. Going through some tech docs I found one about checking the certificate on the machine to see if it was valid. It was but it shouldn’t have been. While looking at it I happened to noticed the expiration date was the time I installed the server so the certificate was expired not valid. Seems that since the time was preset in the BIOS correctly down to the second when I was doing the initial setup I didn’t happen to notice that the year was set to 2012 instead of 2013. I mean really what are the odds of the clock being perfect except for the year and the year not being 1980 or 2000? So somewhere between the certificate being created and the check the clock was updating the year to 2013 and boom immediately expired certificate on my end. This would probably explain why I could update when installing edirectroy since it syncs to the time server. Of course I still need to finish the install and won’t be able to do that until tomorrow (which is driving me nuts not knowing).
Now the real question is will this fix the issue with the system being extremely slow after updating? That remains to be seen.
).
).