Re: [CGUYS] Disk geometry error - solved but not cured
On Aug 18, 2009, at 2:41 PM, Tony B wrote: Maybe I'm just misunderstanding, but I think you're wrong here. In the old days disk imaging may have done bit for bit clones, but these days they use compression, and they ignore empty spaces on the disk. So they have no trouble copying a partition to a different size disk. i.e., Last week I 'restored' my Vista 50gb partition to a brand new 75gb partition. It does not look like a 50gb partition to the OS. Some of us like to have choices. You are describing a different choice as if it were the only way to do it. There are times when a bit-for-bit copy is just the ticket. * ** List info, subscription management, list rules, archives, privacy ** ** policy, calmness, a member map, and more at http://www.cguys.org/ ** *
Re: [CGUYS] Disk geometry error - solved but not cured
Maybe I'm just misunderstanding, but I think you're wrong here. In the old days disk imaging may have done bit for bit clones, but these days they use compression, and they ignore empty spaces on the disk. So they have no trouble copying a partition to a different size disk. i.e., Last week I 'restored' my Vista 50gb partition to a brand new 75gb partition. It does not look like a 50gb partition to the OS. On Tue, Aug 18, 2009 at 2:24 PM, TPiwowar wrote: > Making a bit-for-bit copy is going to give you an exact replica. If > somebody has messed with track zero the copied drive will have the exact > same modification. A bit-for-bit copy of a 100GB drive onto a 500GB platter > will still look like a 100GB drive. To get the "lost" 400GB you will need to > go back and mess with the drive some more or use a different copy method. > * ** List info, subscription management, list rules, archives, privacy ** ** policy, calmness, a member map, and more at http://www.cguys.org/ ** *
Re: [CGUYS] Disk geometry error - solved but not cured
On Aug 18, 2009, at 11:18 AM, Tony B wrote: I guess what I'm saying is this explanation doesn't make sense to me. Do you have a link for further reading? Or is this just another reason not to use Acronis? Nothing wrong with Acronis. Different methods of copying are appropriate in different cases. You need to use the right tool and the right settings for the particular job. Making a bit-for-bit copy is going to give you an exact replica. If somebody has messed with track zero the copied drive will have the exact same modification. A bit-for-bit copy of a 100GB drive onto a 500GB platter will still look like a 100GB drive. To get the "lost" 400GB you will need to go back and mess with the drive some more or use a different copy method. * ** List info, subscription management, list rules, archives, privacy ** ** policy, calmness, a member map, and more at http://www.cguys.org/ ** *
Re: [CGUYS] Disk geometry error - solved but not cured
I've seen lots of disks with extra partitions for manufacturer stuff. But usually it's a simple matter to just ignore it and toss in a newly copied hard drive. I guess what I'm saying is this explanation doesn't make sense to me. Do you have a link for further reading? Or is this just another reason not to use Acronis? PS Yes, there are still a few people on this list that like to talk about computers. For now. On Tue, Aug 18, 2009 at 10:44 AM, Jack wrote: > In case anybody was wondering, I did figure out what I did wrong with the > 100->500GB disk upgrade. > > The original disk in a Dell notebook came with a host protected area (HPA). > Dell uses this area to store extra features, which in this case was Media > Direct. > > The cloning process (Acronis True-Image) duplicates track 0, which includes > code in LBA-3 that exposes the Media Direct package when requested. > However, the cloning process does not copy the contents of the HPA. > > The result is that the OS reports that there is HPA beginning at about > 95GB. This is a boot-up BIOS feature that occurs in both Windows and > Linux. When the new disk is booted, only the first 90-plus GB are seen, and > the rest (400GB or so) are behind the HPA. > > The solution is to zap LBA-3, the sector that contains the HPA > activation/exposure jump address. If this is zero, the system sees no HPA, > and all is fine. * ** List info, subscription management, list rules, archives, privacy ** ** policy, calmness, a member map, and more at http://www.cguys.org/ ** *
[CGUYS] Disk geometry error - solved but not cured
In case anybody was wondering, I did figure out what I did wrong with the 100->500GB disk upgrade. The original disk in a Dell notebook came with a host protected area (HPA). Dell uses this area to store extra features, which in this case was Media Direct. The cloning process (Acronis True-Image) duplicates track 0, which includes code in LBA-3 that exposes the Media Direct package when requested. However, the cloning process does not copy the contents of the HPA. The result is that the OS reports that there is HPA beginning at about 95GB. This is a boot-up BIOS feature that occurs in both Windows and Linux. When the new disk is booted, only the first 90-plus GB are seen, and the rest (400GB or so) are behind the HPA. The solution is to zap LBA-3, the sector that contains the HPA activation/exposure jump address. If this is zero, the system sees no HPA, and all is fine. * ** List info, subscription management, list rules, archives, privacy ** ** policy, calmness, a member map, and more at http://www.cguys.org/ ** *