GNOME Bugzilla – Bug 625981
Disk Read Error after resizing a WIN-XP partition using GParted
Last modified: 2010-08-25 09:41:10 UTC
This problem occured when I tried to resize a cloned XP partition as follows: 1. I started with a 160 Gb hard drive. The drive only has one partition on it - a bootable Win XP partition. 2. I purchased a new 500 Gb hard drive. The aim being to clone the 160 Gb disk. 3. I booted my PC with the 0.6.2-1 Gparted Live CD with both disks attached. 4. I used dd if=/dev/sda of=/dev/sdb method to clone the disk. Of course this gives you a 160 Gb partition on the 500 Gb disk, with the remaining space unallocated. 5. I edited the MBR of the disk to give it a new ID. 6. I then used Gparted to resize the partition to make use of the full 500 Gb on the new disk. The behaviour is that initially I can boot the new disk, but after a few reboots, it fails to boot with the "disk read error" from Windows XP. If I omit the resize stage, the disk boots OK all the time - I've never seen it fail - it's only after the resize with Gparted that it will fail with the "disk read error". I very much this is a hard drive error - it's brand new, and works fine until you resize it. My guess is that Gparted isn't quite getting something write, and eventually Win XP stomps on something that prevents the disk from booting. The MBR on the disk looks fine - unchanged from when it was booting OK anyway. Another alternative is that Win XP is doing something really nasty, but at this stage my money is on the GParted resize - but that's just a feeling. (I'm something of a disk expert, having written a complete FAT12/16/32 driver for my own OS which is used in millions of installations over the world. Sadly I don't know much about NTFS.) HTH
Are both disk drives attached to the same computer when you boot XP? If so, did you change the UUID on one of the disks so that each partition has a unique UUID? If not, then this could cause confusion for an operating system.
I have never tried booting with both disks attached. I would expect XP to get confused if I did that. It doesn't take a lot. After the clone operation, I will only boot with one disk or the other attached. I'll probably store the original 160Gb disk when I'm done. With respect to the UUID, I have tried changing the UUID of the disk. The problem with this is that software applications may use the original UUID for things such as licensing. For example Avast appears to use the UUID to generate it's license key - so it stops working when you change the UUID, and you have to get a new license key. (As an aside, maybe it would be nice for Gparted to regenerate a new UUID on request - I did it with dd, mc, dd commands) What I might do is try Partition Magic, to see what it does.
It sounds like you understand the problems that can occur if there is more than one partition with the same UUID on the same computer. :-) When you performed the resize operation, did you change the "Free Space Before (MIB)" value? Also did you use the default "Align to MiB" partition alignment setting, or did you use "Align to Cylinder"?
When I used Gparted, the default "align to" option was Cylinder. I don't think it let me choose MiB. There was also "None". Normally, I left it as "CYL", but I think I've tried "None" as well. Interestingly the "Free Space Before" value comes up as 1 MiB, and I can't change that to 0. I don't quite understand what this means. The MBR is at LBA 0 on the disk, and the NTFS partition starts at LBA 63. You can see the IPL in LBA 63, and I've used a hex editor to poke around in there and debug a little bit (but not a lot). It's basically failing on a disk read of below 8GiB - which means it issues a CHS read via INT13, and it looks like the INT13 BIOS call is failing. Of course, without re-writing the IPL to some degree, it's not easy to obtain the failure status from the INT13 call. (You don't happen to know of any standalone debugger do you - I'd love to boot to a debugger from CDROM and then watch the boot process through a debugger). I'm beginning to wonder if I've got a hardware issue here. This PC is about 10 years old, and although it's been rock solid, I wonder if it's starting to give up - it's a SuperMicro P6SBU with 800 Mhz PIII and 100Mhz FSB, 512 Mb memory. As a check, I've swapped the processor module, and all the memory. That doesn't make any difference. If I could find another P6SBU I'd swap that too, but I haven't found one yet. I've just installed PM v8.0 on the 160G disk, so I'll clone it to the 500Gb disk again this weekend, and then do the partition re-size with PM and see what that does.
> When I used Gparted, the default "align to" option was Cylinder. I don't think > it let me choose MiB. There was also "None". Normally, I left it as "CYL", but > I think I've tried "None" as well. GParted versions 0.6.0 and 0.6.2 were the first versions to default to "Align to MiB". Due to serious bugs in 0.6.0, GParted 0.6.1 disabled "Align to MiB" and set "Align to Cylinder" as the default. GParted 0.6.2 resolved both of the problems found in 0.6.0. > Interestingly the "Free Space Before" value comes up as 1 MiB, and I can't > change that to 0. I don't quite understand what this means. GParted does not permit changing this value to 0 because some space must always be left at the start of the disk for the partition table. When using Cylinder alignment, GParted will reserve space for 1 track at the beginning of the disk which is normally 63 sectors with today's large hard drives. When using MiB or None aligment, GParted will reserve the first mebibyte of space for the partition table. This amount of reserved space is common with new operating systems, such as Ubuntu 10.04 and Windows 7. Alignment to MiB also helps performance with disk devices with sector sizes greater than 512 bytes. > You don't happen to know of any standalone debugger do you... I am not aware of one, but don't let me stop you from searching the internet. Such a tool might exist. > I'm beginning to wonder if I've got a hardware issue here. This PC is about 10 > years old, and although it's been rock solid, I wonder if it's starting to > give up - it's a SuperMicro P6SBU with 800 Mhz PIII and 100Mhz FSB, 512 Mb > memory. If you happen to have another PC around, you could try your clone/resize test using these same 160 GB and 500 GB hard drives in a different computer. This might be difficult though if the hardware is significantly different.
> I'm beginning to wonder if I've got a hardware issue here. Disk drive testing software is often available at disk drive manufacturer's web site. You could test the new 500 GB drive using such software. I must caution that many of these tests will overwrite your data so be sure to have a good backup first.
Making some progress in understanding this problem, but not quite there yet. In fact I've got a real puzzle on my hands now. At this point I think this issue is unlikely to be a problem of Gparted, but there may be something that can be improved. Anyway...... I have now reproduced the behaviour with Partition Magic - ie without using Gparted at all. Unless there is something that both Gparted and Partition Magic could be doing with NTFS XP partitions to prevent this issue, then I think neither are probably the root cause. I'm assuming you know something of the WINXP boot process. The BIOS reads the MBR and then looks for the active partition and loads in the Boot Sector from that partition. The BS contains the Initial Program Loader (IPL) which attempts to load in 16 sectors from the disk and hand control to the next stage. When the failure occurs, it is in the IPL. When it attempts to read the 16 sectors the INT 13 call to read one sector fails (I don't know why at this stage). The disk read error message is emitted. Now if you remember I am cloning a 160Gb disk (A) onto a 500Gb disk. This results in a 160Gb partition (B) which I then resize upwards to take advantage of the unallocated space. The full sized partition (C) works for a while but eventually fails to boot as described above. The bizarre thing is that apart from one field, the BS remains identical to the original 160Gb BS. Which boots OK. The big question now, is why does the INT13 call work with A, with B cloned and for a short while with the C? What makes the BIOS suddenly decide to fail the INT13 call but only on C - which has exactly the same BS (apart from one field which is the partition size)? Very odd. The failure seems to come after leaving the computer off for some time (possibly). It's almost like the BIOS is "forgetting" something. I thought the BIOS scans the disks attached every time it starts. Any offers?
Have you tried running some drive testing software on your new 500 GB drive? Often the manufacturer's web site will list some software for testing their drives.
Yes I have. I ran the Quick Test of Hitachi's DFT and it passed. The IPL however fails every time with the INT13 failure (disk read error). I'll try to understand why - and more importantly, what makes it transition from working all the time to failing all the time.
I have been busy again. I have reproduced the problem on a different disk - this time a 400 Gb disk. I have also left the partition at 160 Gb on my 500 Gb disk without the problem occurring. I have played around, poking the IPL to try to debug the issue. I have not 100% proved the problem, but here is what I think is happening: I believe the problem occurs because my BIOS can only access 32-bit LBA addresses - ie up to 137 Gb. This causes a disk read error if and when the boot process tries to access an LBA beyond the 32-bit, 137Gb limitation of the BIOS. On my 160Gb disk this doesn't happen. Most of the boot files will live at the start of the partition, and it's probably a good job that they do. I think that I may have been lucky in not seeing my 160 Gb disk fall over. When I clone the disk to a 500Gb disk, all is well whilst the partition remains at 160Gb - as you'd expect because it is, in effect the same disk. When I then resize the partition up to make use of the full partition, all is OK to start with. Again what you'd expect since all the boot files will be where they used to be. Then, at some stage, XP moves something that is required in the boot process to be outside of the 137Gb limit. Of course on a 500Gb disk there is now more chance of this happening. Once the "something" is moved outside of the 137Gb limit, the BIOS is unable to address it, and the boot process (which relies on the BIOS INT13 calls) fails and emits a disk read error. I have not established when, what and why XP moves to provoke this. The workaround is to have XP always boot from a 137Gb or less partition at the start of the disk and have a data partition use the remaining space after that. That way the required boot files can never be moved beyond the 137Gb limit on the disk. Of course, this is not a GParted bug. Or a Partition Magic bug for that matter - the issue reproduces with both of these. However, is it possible that Gparted (and partition magic) could have flagged the issue? Is it possible to make INT13 calls to the BIOS from Gparted or Parition Magic? Bypassing it's own driver? If so, then you could deduce the maximum addressable LBA and, if a bootable partition is involved flag that the operation could be dangerous if that BIOS is to be used to boot the disk. (Of course XP could do similar, and set a flag preventing itself from moving boot files above the 137Gb limit on 32-bit LBA BIOS boards. After all, once XP has installed it's own mass storage driver, it can access up to 48-bit LBAs, so all it's got to do is detect the BIOS limit and maintain the boot files such that they live within that limit - and of course refusing to make partition that live at the top of the disk, outside the BIOS limit, bootable. But perhaps that is way too clever for Microsoft!) Finally, a word of warning. I haven't totally proved all of this. It just seems like the most probable explanation. I don't know what XP is moving about or what triggers it - possible a background defragger. It may be worth considering having GParted flag this scenario - it may save you much more time than putting it in?????
Thank you for reporting back with your testing and theories. I would agree that the 137 GB limit with some 32-bit LBA BIOS boards is not a bug in the GParted application. GParted uses the libparted library to talk to the GNU/Linux operating system which can then talk with the motherboard BIOS. As such I am not aware of any easy way to add check for this limitation. Also this problem will become less prominent as old computers are retired. I will mark this bug report as NOTABUG since the problem does not reside with GParted. If you discover a way to test for this problem then please do feel free to re-open this bug report and provide code describing how to non-destructively test for the 137 GB BIOS limitation.
As an after thought, I love the comment: "Also this problem will become less prominent as old computers are retired." That's what they said about the old 8Gb CHS limit. And by the time nearly all those bangers had been retired, the 137Gb limit had been hit. In my opinion, it is rather poor, when any software stack, which could theorectically detect an error, allows it through and it leads to leaving your computer in a non-bootable state. I don't really understand the Linux boot process, but I wonder what would happen if I have a small linux boot partition, and I moved it to beyond the 137Gb limit on a big disk? Both the Linux/libparted/Gparted and XP/partition magic stacks are equally guilty of this offence. They could do something about it. But they don't.