• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

Ghost 120GB to 250GB Windows 2000 SP4

ark42

Member

Just got my new 250GB drive from newegg today, and Ghosted all the data (one big partition, disk-to-disk) from my old 120GB drive using Ghost 8.0 which supports >128GB drives. I can boot from my old 120GB drive and see the entire 250GB as D: just fine, even without creating that EnableBigLBA registry key I've read about. Both drives have Windows 2000 SP4 and all the same data on them. If I switch the master and slave jumpers and try to boot from the 250GB drive, it completely fails without ever showing the slightest hint of NTLDR or anything. What do I need to do to be able to boot from this new drive? Typically in the past, Ghost has worked just fine to maintain all boot-related information so that switching the new drive in works perfectly.
 
Yes, I did, and the 120GB was set as slave. There is only one partition per drive. It doesn't matter if I disconnect the 120GB altogether and only have a total of 1 IDE device connected, the results are the same. The BIOS spits out its normal "Verifying DMI pool..." then nothing.

I tried booting a Windows 2000 CD with SP4 slipstreamed and telling it to repair, but it couldn't locate the installation. I ran the console mode from the CD and I could log into the C:\WINNT installation on the 250GB drive. I tried running FIXMBR and FIXBOOT but it didn't help. After "Verifying DMI pool..." I just get a few random garbage letters blinking in random colors at random spots on the screen.

I can put the 120GB back in, and set it to master, and it will boot just fine with the 250GB as slave. I can then compare files on C: and D: and they all seem the same (using fc /b from cmd).

I havn't tried just installing a fresh Windows 2000 on the 250GB drive, but I'm not sure it would be any different. Can Windows 2000 SP4 even boot >128GB drives, or do I *have* to make a <128GB boot partition and Windows 2000 SP4 can only access >128GB partitions after booting up?

 
ark42

out of curiosity, is your new hard drive SATA? if so, you have to install SATA drivers.

chipy
 
Originally posted by: chipy
ark42

out of curiosity, is your new hard drive SATA? if so, you have to install SATA drivers.

chipy

Agreed, if your old drive is regular ATA/133 and the new drive is SATA, this is going to be difficult for you.

However, Windows should still attempt to boot.

I'd wipe the 250Gb drive clean, personally, and then install Windows 2000 from scratch. If that fails to boot, then the drive may be screwed.
 
Both drives are PATA. A fresh install of Windows 2000 went ok partitioning and formatting the drive, but after the first reboot, I got back to unable to boot from the drive to continue the install, even though I can still boot from the 120GB and see the install files on the 250GB then.
I got it to work, but I'm not sure really which step did it. I flashed my motherboard BIOS which was a 2003 date to the newest, which was a late 2004 date. None of the listed fixes in the BIOS mentioned >128GB fixes though. I also ran the Hitachi diagnostic boot utilty, which said the drive was OK. I then let the utility write zeros to the entire drive and after both of those two things, I re-ghosted from the 120GB and booted the 250GB just fine.

I did notice that places that report CHS reported different values after those steps (more cylinders afterwards, but I think heads went from 255 down to 16, so it should be the same total size either way). I'm not sure that means anything though.

My guesses are that either the BIOS upgrade silently fixed some 48bit addressing glitch on my Epox 8RDA+ or the partition table/master boot record was somehow screwed up in a way that simlpy re-creating partitions and ghosting didn't change, and the writing zeros over the entire drive fixed it.

Anyway, it seems to work now. I'm a bit confused on the EnableBigLBA registry key you have to create though. How would you go about doing a fresh install to a >128GB partition without that key being set yet. From what I've read Windows 2000 SP3 and SP4 require that key to be set, and Windows XP SP1 requires the key as well, but Windows XP SP2 just supports BigLBA and ignores the key now.
 
Originally posted by: ark42
Both drives are PATA. A fresh install of Windows 2000 went ok partitioning and formatting the drive, but after the first reboot, I got back to unable to boot from the drive to continue the install, even though I can still boot from the 120GB and see the install files on the 250GB then.
I got it to work, but I'm not sure really which step did it. I flashed my motherboard BIOS which was a 2003 date to the newest, which was a late 2004 date. None of the listed fixes in the BIOS mentioned >128GB fixes though. I also ran the Hitachi diagnostic boot utilty, which said the drive was OK. I then let the utility write zeros to the entire drive and after both of those two things, I re-ghosted from the 120GB and booted the 250GB just fine.

I did notice that places that report CHS reported different values after those steps (more cylinders afterwards, but I think heads went from 255 down to 16, so it should be the same total size either way). I'm not sure that means anything though.

My guesses are that either the BIOS upgrade silently fixed some 48bit addressing glitch on my Epox 8RDA+ or the partition table/master boot record was somehow screwed up in a way that simlpy re-creating partitions and ghosting didn't change, and the writing zeros over the entire drive fixed it.

Anyway, it seems to work now. I'm a bit confused on the EnableBigLBA registry key you have to create though. How would you go about doing a fresh install to a >128GB partition without that key being set yet. From what I've read Windows 2000 SP3 and SP4 require that key to be set, and Windows XP SP1 requires the key as well, but Windows XP SP2 just supports BigLBA and ignores the key now.

http://support.microsoft.com/default.aspx?scid=kb;en-us;305098
http://support.microsoft.com/default.aspx?scid=kb;en-us;303013

Seems like 2000 SP3 and 4 require the key, but XPSP1 and higher do not.
 
I deleted the key and rebooted and copied a few large files until I was using nearly the full drive, and ran utilities like defrag and scandisk to verify that all of the space is ok, and it seems to work just fine without the registry key being set in 2000 SP4.
 
Originally posted by: ark42
I deleted the key and rebooted and copied a few large files until I was using nearly the full drive, and ran utilities like defrag and scandisk to verify that all of the space is ok, and it seems to work just fine without the registry key being set in 2000 SP4.

Per MS's KB article:

? After you enable 48-bit LBA support by adding the appropriate registry key, data corruption may occur if you remove the registry key or if you remove (uninstall) SP3 for Windows 2000.

That isn't a recommended move.

http://support.microsoft.com/default.aspx?scid=kb;en-us;305098
 
From what I can tell, the KBs only refer specifically to SP3 and SP2, and probably where not updated for SP4 (?)
I tested for data corruption - my assuption is that if something goes wrong, the software will wrap-around past 128GB and information that is supposed to be written at the spot for 129GB will be written back at 1GB into the drive. I had about 200GB of 250GB used and ran defrag to move everything around (it was pretty fragmented to start with anyway) and tested a bunch of files afterwards. It still is up and running and I didn't see any corruption yet.
 
This sounds like the hitachi utility modified the hard drive's translation table to suit your bios.

Storagereview.com has detailed info on this if it is of interest to you. The Cliff Note version AFAIK is that this is the workaround to overcome the latest limitations to hard drive size. When I've used this method , it has been effective and without any downside that I've noticed.


Jim
 
Originally posted by: ark42
From what I can tell, the KBs only refer specifically to SP3 and SP2, and probably where not updated for SP4 (?)
I tested for data corruption - my assuption is that if something goes wrong, the software will wrap-around past 128GB and information that is supposed to be written at the spot for 129GB will be written back at 1GB into the drive. I had about 200GB of 250GB used and ran defrag to move everything around (it was pretty fragmented to start with anyway) and tested a bunch of files afterwards. It still is up and running and I didn't see any corruption yet.

Sounds like you're good to go - I would agree with your hypothesis that the BIOS silently changed the LBA method, especially if you saw the CHS (Cylinders, Heads, Sectors) figures change.

Now, go fill it up with downloads from em****ium.us 😉

:thumbsup::beer:
 
Back
Top