Advice on a 64bit system upgrade

[jaclaz]

Just for the record.

Deleting the partitions means nothing.
What you do when deleting the partitions is to remove their addresses in the MBR partition table (and eventually in the chain of EMBR's).

And in any case if you have - say - a green car and you want to re-paint it in green (or red or black) you don't usually re-paint it in white before spraying it with the final colour.

In other words, when a program writes a byte on disk, that byte is written, no matter what was written in that location before.

As I tried to explain in the previous posts, in your particular case, a clone on a different kind of disk is not the most suited approach for your needs, an image would be IMHO better suited.

 

After all, there are - say - 95% probabilities that you won' t need to restore it, as the transplant would go fine, and a clone - since it cannot be connected concurrently to the original (without keeping one of the two disks unmounted or without having a backup of the MBR of the "original" ready to be re-deployed) on a NT based system is anyway less convenient, should it be needed.

 

jaclaz

[Dave-H]

Everything is going well so far.

I made a new clone disk this morning, and then immediately removed it.

Later on I opened up the machine and disconnected the SCSI cable from the board to the system disks, and replaced the clone in the IDE bay and set the BIOS to boot from it. Everything worked as I hoped, the drives on the IDE disk became C: and D: and both Windows XP and Windows 98SE booted fine.

They both booted very slowly, and were not performing anywhere near as fast as they usually do even after they were fully booted.

Don't know why that would be, there is no problem with the performance of the disk, but at least they worked!

 

So, I'm now confident that I have a "snapshot" of my system that I can now boot from if the original installation on the SCSI disk gets corrupted.

Presumably in that scenario I can boot from the IDE disk and then clone it back to the SCSI disk after deleting the partitions on it to stop them being used.

 

So what next, am I now ready to actually try the new hardware?

I should emphasise that I don't even know for certain that the new motherboard will actually work at all!

Both it, and the processors and memory are all "used" items, so there is no guarantee.

Edited August 6, 2014 by Dave-H

[dencorso]

First of all, take the IDE clone out of the room and store it safely. No matter what happens, don't even bring it into the room again, before consulting with us. Only use it again, in case of need, after we've collectively decided the best course of action. This is as important as actually having the clone!

 

That said, I have a question, because I'm not much familiar with SuperMicro boards (I've serviced no more than half a dozen machines using them in all my life, they are really rare in around herel): does your old hardware post, then attempt to boot from removable media when there's no (viz. none at all) HDD conected to it? And if so, does it provide info on the monitor (say, display the memory test and the detected hardware) before parking on a message like "insert bootable media and press any key"? Or does it just beep and stop without providing any useful info? I ask that because probably your new (used) board behaves in the same way... So that, at this point, I'd test the old system for useful info with no HDD and if it actually provides it, then remove the old board and put in the new with the processors and memory it came and have it post to see it's OK, then substitute the processors and repeat this process... until I'd made sure all the new (used) hardware is working fine. Then, and only then, I'd proceeto add the SCSI subsystem (board and HDDs) and try to boot XP from it. I say this because, as you bought the best processors that board can use, you may have to flash the BIOS to its latest version, before the board can use them. If so, it'll post OK with the original processors it cam with, but fail to post with the better ones. I've seen that happen more than once. As soon as you're sure the new hardware is OK, I think you're ready to add the Windows XP disk.  

[Dave-H]

Don't worry, the clone disk is safely shut away in a drawer!

 

My present board goes through the memory checks and detecting devices, including the SCSI card's BIOS, and then searches all the drives listed in the boot devices, in the order they are listed (which you an change of course) and if it can't boot from any of them, displays "operating system not found".

If no drives were connected, HDDs or CDs, the only thing in the list would be "bootable add-in cards" which I've never used.

 

I have already fitted the quad core processors to the board, with the thermal coupling compound and heat sinks of course, so I don't really want to put the old ones back in again!

Supermicro said that looking at the serial number of my board, it was made well after the 1.1 update revision was done to support quad core processors, so it's extremely unlikely that the BIOS on it won't support them.

Presumably even if it didn't, no permanent harm would be done, it just wouldn't work, so it that were the case I would try updating the BIOS and/or putting back the original dual cores.

 

I don't know what BIOS version is actually fitted, the chip has 7DAL C056 on it, but I don't think that relates to the version at all as the latest BIOS on Supermicro's site is quoted as 2.1c. I guess i won't know until I fire it up!

[dencorso]

Well, if you already added the new processors, then turn it on, with no HDD. If the new processors are recognized OK, you'll will see their recognition by the BIOS and the RAM count. Once you know that happens, you may go ahead. If the board refuses to POST, then you should go back to the processors it came with and try again. If it then POSTs, then a BIOS update should be needed. Of course, "POST" means "Power On Self-Test" and to POST means to perform it.

 

As for the BIOS version, the easiest way is to use CPU-Z to determine it... or to use this old app, from true DOS (it can be run from a floppy!).

[Dave-H]

Thanks Den, I'll probably give that a try tomorrow.

I'll see what the BIOS version is, and what it recognises as regards processors and memory.

Supermicro say that you should never update your motherboard BIOS unless you are actually having problems, so if I find the version on my board isn't the latest version, do you think I should update it anyway?

The latest version posted will almost certainly also be the last version, as it is a seven year old board.

[dencorso]

No, if all is working, I see no need to upgrade the BIOS now. Moreover, unless you need to do it because something does not work, it's not a priority and anyway it can be done latter at any time, if you ever decide to. But if the processors or part of the RAM are not correctly detected, then (and only then) it would be 1st priority.

[Dave-H]

Thanks.

I will try the new board tomorrow probably.

If my next post is from my netbook, you'll know it was a disaster!

[jaclaz]

 GO Dave-H GO! 

 

jaclaz

[Dave-H]

Hi guys, well it worked (mostly)!

The main problem I've run into is actually a physical one, not software related at all.

The processors and their heat sinks are in a completely different place on the new board to the old one, and the metal expansion frame that contained my SCSI drives will now not go back into the case because they're in the way!

At the moment the drives are sitting in their frame outside the computer while i wonder what to do about that!

 

Software wise, everything went very well. The motherboard BIOS is 2.1a, which is the latest version, and the BIOS is reporting two quad core Xeons running at 3.16 GHz, which is all as it should be, and 4 GB of RAM.

 

So, the hardware is all working, I think!

I probably didn't mention this before, but I was a bit puzzled why the guy in Germany I bought the board from included a PCI Ethernet card in with it.

I asked him why, because the board has its own Ethernet connections of course, two of them in fact.

He came back to say that he had trouble with the on-board controllers, so had thrown in the card.

 

I found the on-board controllers' jumpers were set to disabled, so thought that might be the problem, but when enabled, they are recognised by the system, but absolutely refuse to accept any drivers! It's supposed to be an Intel 82563EB controller, but no matter what driver I try, when I try to update the driver it says there is no compatible driver found. I eventually got online by using the PCI card, but I don't want to stay like that ideally as it's using up a precious expansion slot.

 

I can't believe that both GLANs are physically faulty, although they could share some hardware of course.

They are both being seen in Device Manager, the ID is PCI\VEN_8086&DEV_1081&SUBSYS_00008086&REV_01\6&1185AD87&0&00100018, which produces no results on Google. All a bit of a mystery. Even the drivers on the Supermicro disk don't work, the Intel network software installs OK, but there is then no working network connection!

 

I haven't dared try running Windows 98 yet, I fully expecting that it won't start at all..........

Edited August 7, 2014 by Dave-H

[dencorso]

Well, it sure seems as if both onboard GLANs are toast!
And that would be why they were disabled.
 
As for the heatsinks, you probably can either use other models or with some luck, remove them, mount the drive bay then mount them once more? A PIC of the problem would also be much welcome.
 
So XP did run with no complaint after all? Great!

[Dave-H]

The previous guy who owned the board presumably disabled the GLANs, to stop constantly being nagged for drivers.

It seems a bit strange that they should both still be seen by the system and appear in Device Manager if they are physically faulty.

I think I will e-mail Supermicro about this and see what they say.

 

Everything else is pretty good, the system is running very fast and well.

I am getting an annoying long constant beep from the system when it boots up, which goes away when Windows loads.

Occasionally it does come back when I do some things, for instance yesterday it was beeping whenever I used the left arrow key to jog backwards on a video, but I haven't identified a common cause as yet. There's no sign of any hardware distress anyway.

 

One thing that's puzzling me that I haven't researched on yet, is that I have two old (make that ancient) 16 bit programs that I still use. One is a desktop clock, and the other a desktop program running utility. Neither will now work, if i try and run them there's no error messages or anything, but they just don't run.

16 bit compatibility hasn't gone with this system surely!

[cdob]

It's supposed to be an Intel 82563EB controller, but no matter what driver I try, when I try to update the driver it says there is no compatible driver found.

I can't believe that both GLANs are physically faulty, although they could share some hardware of course.

They are both being seen in Device Manager, the ID is PCI\VEN_8086&DEV_1081&SUBSYS_00008086&REV_01\6&1185AD87&0&00100018

Can you check the HardwareID again? Which ID goes to the second device?

It's a sever motherboard, Intel dosn't offers XP LAN drivers always.

Try patching drivers at own risk.

http://www.intel.com/support/network/sb/cs-006120.htm

http://downloadcenter.intel.com/detail_desc.aspx?agr=Y&DwnldID=18717

File name: PRO2K3XP_32.exe

Version: 18.3 (Latest)

Date: 05/15/2013

Yes, no HardwareID 'PCI\VEN_8086&DEV_1081'

PRO2K3XP_32\PRO1000\Win32\NDIS5x\e1000325.inf

%E108ASA.DeviceDesc% = E108A.ndi, PCI\VEN_8086&DEV_108A

E108ASA.DeviceDesc = "Intel® PRO/1000 P Dual Port Server Adapter"

PRO2K3XP_32\PRO1000\Win32\NDIS5x\e1e5132.inf

%E108BEC.DeviceDesc% = E108B.ndi.5.1, PCI\VEN_8086&DEV_108B

%E108BEC.DeviceDesc% = E108B.ndi.5.1, PCI\VEN_8086&DEV_108C

%E1096NC.DeviceDesc% = E1096.ndi.5.1, PCI\VEN_8086&DEV_1096

%E1098BC.DeviceDesc% = E1098.ndi.5.1, PCI\VEN_8086&DEV_1098

E108BEC.DeviceDesc = "Intel® PRO/1000 PM Network Connection"

E1096NC.DeviceDesc = "Intel® PRO/1000 EB Network Connection with I/O Acceleration"

E1098BC.DeviceDesc = "Intel® PRO/1000 EB Backplane Connection with I/O Acceleration"

Guessed, edit: PRO2K3XP_32\PRO1000\Win32\NDIS5x\e1e5132.inf

[Intel.NTx86.5.1]%E108BEC.DeviceDesc%            = E108B.ndi.5.1,       PCI\VEN_8086&DEV_1081

or try

[Intel.NTx86.5.1]%E1096NC.DeviceDesc%            = E1096.ndi.5.1,       PCI\VEN_8086&DEV_1081

[Dave-H]

Thanks cdob!

I have in fact now found a driver that does work with the GLANs, and they're now installed fine, as two "Intel PRO/1000 EB Network Connections", which I hope means that there's no hardware fault, but I still can't connect to the internet with either of them, it tries but then says it can't allocate an IP address.

 

The driver you found is one of the ones I tried, but as you say it doesn't support this hardware as it is.

I have e-mailed Supermicro to ask them about this, as it's very strange that there seems to be no software on their driver disk to support this hardware!

Both GLANs have the same hardware ID BTW.

 

I've found a later version of the driver I'm already using, which I will try, but if that doesn't work either I'll try hacking the driver as you outline above to see if that produces any joy.

Edited August 8, 2014 by Dave-H

[jaclaz]

Well, you could at least detail WHICH driver is working, possibly also providing a link to them,  so that other people in a similar situation as you were will benefit from your findings.

 

The issue with the "can't allocate an IP address" may be connected to those drivers (then thus are pretty much useless) or to *something* else, you will need to provide some more details and possibly someone can help you solve this latter issue.

 

Still, if you can find the "right" drivers for *another* OS, let's say Windows 7, it would be a good idea to try (even a PE 3.x would do) if the NIC's are actually working with it, as it is possible that the issue is actually in some form of malfunctioning.

 

jaclaz