DS.nlm no long load after a "successful" upgrade from NW6 sp4 to sp5

Hi gang,

We're running into HUGE problem here upgrading NW6 sp4 to sp5.

For reasons unknown four servers failed the upgrade, out of a slew of over 10 servers upgrade.  The problem we run into is that the upgrade appear to be successful - no error message, nothing!  However, upon restart, the affected server would failed on loading DS.NLM - all they're showing is "Unresolved".

Any ideas on how to fix this...  or how to remove the "Dead" server from the TREE?

Of course, we'd like to fix the servers if possible since they're production servers.  But if not, then how could we remove them from the TREE.

Thanks much in advance!

There's just nothing to post because there are no errors.  But if you have any questions please ask...  

LVL 11
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

NetWare v6.0, right? Not NetWare v6.5, right?

OK, you started with the server holding the Master replica of the [Root] partition, right? That was the first server you did, and you did not do any other servers until that was done and up and running, right?

Before you started, did you insure that time was synched across the network, and all replicas were replicating?

Well, I'm turning into a pumpkin. I'll check back later this morning.

As with any deployment that affects NDS, you start with the server that holds the Master replica of the [Root] partition of the NDS tree. You also make sure time is in sync and that all replicas are in sync. Hopefully, that is how you approached this.

Without knowing more, I'd start troubleshooting by picking a server, the "highest" one in the NDS tree affected, and getting a hardcopy of its AUTOEXEC.NCF file. I'd boot it up to a DOS prompt and then, in C:\NWSERVER, enter the command --> server -na -nl

That will load NetWare, and supress running AUTOEXEC.NCF as well as the display of that annoying logo screen. The commands in STARTUP.NCF will be executed.

If no errors result, then start entering the commands from AUTOEXEC.NCF, one at a time, until something breaks or you're done. If something breaks, post the details here.

If the server can't even come up that far without bombing, then reboot to the DOS prompt, get a hardcopy of STARTUP.NCF, and in C:\NWSERVER, enter --> server -na -ns -nl

That will load NetWare, and supress running STARTUP.NCF, AUTOEXEC.NCF as well as the display of that annoying logo screen. The server will boot up to basically a console screen with a bare ":" prompt.

Enter the commands from STARTUP.NCF, one at a time, until something barfs or you get thru all the commands. If something barfs, post the details here.

If you get thru STARTUP.NCF without incident, then at the console prompt, enter --> LOADSTAGE 1

If it barfs, post the details here. Otherwise, replace "1" with "2" and repeat. Then do the same for "3", "4" and "5". If anything barfs, stop there and post the details.

If you get all the way thru LOADSTAGE 5 and nothing barfed, start entering the commands from AUTOEXEC.NCF.

If you can do it all manually but it barfs when does automatically, then its some sort of timing issue.

The last time I saw something like this was in NetWare v5.1, where applying an SP appeared to break NICI, but it was actually a storage driver problem, and the solution was to backlevel that one driver.
Mighty_SillyAuthor Commented:
Thanks for the quick response PsiCop!

It was NW6.0, from sp4 to sp5, not NW6.5.

Yeah, the Master replica was completed b-4 any of these were done.

We found out the problem - following another fix we copied several files to the local C:\DOS partition and that ended up mucking up this process.

To make a long story short, it was the DSLOADER version that got copied over from above mentioned fix that bombed the DS.NLM.

Novell tech sez to copy DSLOADER from another NW6.0 sp5 server to the C:\ partition and that did the trick.


Cloud Class® Course: Microsoft Exchange Server

The MCTS: Microsoft Exchange Server 2010 certification validates your skills in supporting the maintenance and administration of the Exchange servers in an enterprise environment. Learn everything you need to know with this course.


Glad its fixed. Don't forget to post a (free) Question in the Community Support TA (http://www.experts-exchange.com/Community_Support/) and request that this Question be PAQed and your points refunded. Be sure to include a link to this Question.
Mighty_SillyAuthor Commented:
Thanks PsiCop!

Though we got a workaround and revived these batch of 4 servers, we subsequently had issues with upgrading another batch from NW6sp4 (eDir 873) to NW6sp5.  

Could you take a look at my other post?  

Thanks guy!

ps: I posted a note in community support to close this Q.  
No objection (obviously).
Question PAQ'd
500 points refunded.

Community Support Moderator

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Novell Netware

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.