GNOME Bugzilla – Bug 414943
Resizing Win XP FAT32 (not NTFS) partition leaves Win XP unbootable.
Last modified: 2009-11-04 00:33:59 UTC
Please describe the problem: Downloaded and used gparted 0.3.4-0 yesterday, Mar 4, 2007. Tagged this as version "0.3.3" since that was most recent version available in the Bugzilla menu today. Three disk system, Win XP on single partition of first disk, taking entire disk. I had created it as FAT32, not NTFS. I use GRUB as the bootloader. Used gparted (always used Partition Magic before, which always worked) to resize the 30GB Windows XP on hda1 down to about 20GB to install FreeBSD on last 10GB of hda. Seemed to go OK, but now Win XP won't boot. Other (Linux) partitions still boot, so GRUB, MBR must be OK. Steps to reproduce: 1. Probably reproducible, seems similar to bug 352270, unfortunately closed. 2. Outside chance this is a GRUB bug, since two days earlier I had installed a new copy of Linux (SLED 10, which is working great) on another disk, hdc. But possibly GRUB itself lost Win XP's loader offset during that installation. 3. If anyone knows the offsets, can I just use dd to slide Win XP's loader back to where GRUB thinks it is? If that doesn't clobber anything critical. Actual results: GRUB tries to boot Win XP, but I see messages (first 3 letters off the screen): "inloader(hd0,0)+1" (I think this means "chainloader(hd0,0)+1") "DR is missing" (I think this means Win XP loader can't be found) "ss any key to restart" (I think this means "Press any key to restart") Expected results: I expected Win XP to boot as usual. This is probably a trivial fix having to do with an offset to the Win XP loader, but is a real problem for a user like me. Does this happen every time? Have booted Linux repeatedly since then, but booting Win XP always fails with same messages (see above). Clutching at straws (see bug 350793), I used gparted to grow Win XP partition back to original size, but that did not help at all. Other information: I can reinstall Win XP if no fix is available, but then I would need help reinstalling GRUB so I can boot my Linux partitions without reinstalling THEM. Would be preferable if some tool can tweak something so GRUB chainloader command can find the Win XP loader.
Is there a quick and easy way to rescue your Linux partitions on 2nd and 3rd disks after reinstalling Windows on the first disk (which wipes out the MBR and thus GRUB)? Thanks for anyone's help.
David, Usually XP is used with NTFS file system, and GParted make the changes to the bootsector so it can boot after moving. Anyway you didnt perform a move but only shrunk your partition, right ? I will make a quite test and install a XP on fat32. but i need some time as you can guess. I want to see exactly what happens... Could you try to delete the fsb and grow the XP partition to its previous size ? About restoring Grub on mbr it is not a big deal. Like you said, installing XP will wipe out mbr. Then you need to boot of some rescue cd and set grub to the mbr back. Which linux distro do you use ?
Thanks Larry, Bug 352270, prematurely closed, may be the same problem but with an NTFS file system. So maybe you can try it first with NTFS if that's faster just to make sure and old bug hasn't reappeared in version 0.3.4. (I did download and use 0.3.4. But Bugzilla's dropdown menu only gave 0.3.3 as the latest choice of versions, another bug in itself, I guess.) Yes, it was only a resize, not a move. What is the "fsb"? But I did grow the partition back to occupy the full 30GB WD Caviar disk, using gparted again. No help. Data seems unharmed--I have R/W access to that partition from my Linux partitions. The Linux distro I use daily is a new copy of Novell's SLED 10, installed just a couple of days prior to trying out gparted.
David, I did a fresh XP-pro US installation on FAT32, and successfully resized the partition from 5 to 3.5 go ! I gonna perform the same test again with NTFS, but i guess the problem comes from something else. About version 0.3.4 comes from SVN, so you may choose CVS i think. But i will talk about that point to Plors the C++ dev. I don't know novell, but i think it might be about the same as fedora. so you just need to have a look at the novell docs and "how to reinstall grub" : it should be documented.
Hi Larry, I don't anticipate any real problems with reinstalling GRUB in the MBR. The very easiest way to do it would be to install yet another flavor of Linux in one of my other free partitions. Maybe the latest and greatest Red Hat... Have you seen bug 379482? Sounds a lot like mine. He has an nVidia chipset as do I. He has nForce3 250 SATA Controller. My Southbridge chip is nVIDIA nForce 430 MCP, with MCP51 SATA controller. Is nVidia the common link with these bug reports--a buggy driver somewhere? What about their NCQ (native command queueing) for their SATA controller? I think these are fairly new chips/controllers. nVIDIA was releasing new Linux drivers for the Northbridge chip (6150 onboard graphics) for this same moboard as late as last summer. But if your test rig used nVidia chips (at least for the Southbridge) then the preceding paragraph is all hot air. Still curious as to what the "fsb" is that you mentioned in Comment 2. To me, "fsb" means "front side bus", not something you would want to delete even if you could. Thanks, DE
About "fsb" : i am sorry it was just a mistake :-/ fs : file system. :D I will try to see relation with this other bug you mentioned. I need sometime, as you can easily guess. thx for reporting
Additional info: 1. Looked at XP C: drive from dual-booted Linux. Saw that NTLDR and boot.ini were there, apparently intact. Reasoned that since MBR obviously OK (I could boot Linux fine), something "invisible" was wrong with XP boot sequence. 2. Fired up Windows Recovery Console and fixed XP boot sector. This went OK, but did not help, still got "NTLDR is missing". 3. Made a Win XP boot floppy (format a floppy in a working XP machine, then copy 3 files to it: NTLDR, ntdetect.com, boot.ini) and boot it in the stricken machine. Thus, the entire boot sequence takes place from the floppy, but the floppy's version of NTLDR loads the balky Win XP from the hard disk. THIS WORKED and I am still using this method to boot my Win XP (fine with me since I use it so rarely). 4. So it seems gparted didn't really overwrite or otherwise lose anything at all when it resized my Win XP partition, since it all works fine now, so long as I boot from a floppy. Incidentally, I used the three critical files (NTLDR, boot.ini and ntdetect.com) from my own "bad" Win XP partition--just booted Linux, inserted the blank floppy (formatted on a working Win XP machine, which apparently automatically puts a boot sector on the floppy) and dragged and dropped the three files to it using the ordinary Gnome GUI. That proves there was nothing wrong with those files themselves, but something "invisible" somewhere in the boot sequence. Upon further research: 1. It appears there are any number of things that can cause Win XP boot to fail with the "NTLDR is missing" message. A really weak point (among many) of Win XP. 2. www.5starsupport.com has a list of MS KB articles on the issue. One of them is #320397 which I believe may be the key to my problem (and several others who have posted similar bugs for gparted). Unbelievably, #320397 DOES NOT APPEAR in a Google search for "NTLDR is missing" or "NTLDR reinstall", at least not in the first few pages of results. I am grateful to 5starsupport for their pointer. 3. The gist of #320397 is that if the Windows root directory gets too many files created (even if they are later deleted), the directory's track allocation structure gets screwed up enough that the Win XP boot sequence can no longer find NTLDR (even though it's right there all along). A huge and horrible bug somewhere in their boot code! 4. So. Does gparted (in a downsize operation on the Win XP partition) do all its file copying to/from the Win XP root directory (C:\)??? If so, it may be tripping over this Win XP bug. The workaround might be to use some (any) OTHER directory--make yourself a "gparted" directory, maybe. Anything but the directory that contains Win XP's boot files: boot.ini, ntdetect.com and NTLDR.
Hm, really weird ! Happy that you solved this problem. No idea how to fix this atm...
You and your abbreviations! :-) If "atm" means "at the moment", then nobody but Microsoft can fix it, and they've apparently known about it since Win XP came out. All they've done is offer a "Bcupdate.exe utility" through Microsoft Support Services. Assuming "bcupdate" means "boot code update", this is useless unless either (1) every Win XP user has installed it or (2) gparted fixes up the broken Win XP boot code itself on the fly (probably inadvisable). So don't hold your breath. If Microsoft wanted to fix this, they could have years ago. I think that several other bug reports on gparted are on this same problem. I suggest: 1. Show this to the developers. My speculation above is all hot air if gparted does NOT use C:\ as its temp directory during resizing and writing perhaps many thousands of temporary files to it. 2. But if gparted does use C:\ that way, then the workaround for gparted is to use someplace else, ANYPLACE else. The problem shows up when root directory's MFT (Master File Table) is forced to construct "a second allocation index" into which NTLDR gets pushed since the MFT is kept in alphabetical order. Apparently some bit of Win XP boot code simply ASSUMES that NTLDR could only be in the FIRST allocation index and never looks anywhere else (and normally it would be there, since Microsoft themselves put only a few files in the C:\ directory at install time and rarely/never add any others). If I were the gparted developer, I would create a temp directory under C:\ to use as a work directory during resizing, then delete it just before exiting. 3. My (mercifully) final question: does Partition Magic have this same problem?
Hey David ;) Like you mention it, the problem is to be set by dev. And the only dev is Plors, which sounds to be *very* busy atm (:-p). So make wishes for he looks at this bug. Can't give you any answer. :(
Hi David, Are you still experiencing this problem? After doing some research into this problem, I have some more information. This information does not necessarily identify the problem, but does pursue some other avenues of thought. IS A SECTOR OFFSET STORED IN THE FAT32 BOOT SECTOR? --------------------------------------------------- The NTFS file system stores the number of physical sectors before the partition at offset 0x1C in the boot sector. In this case, the boot sector is the starting sector of the file system, and not to be confused with the Master Boot Record at the start of the hard drive. The offset can be seen at the following URL: An Examination of the NTFS Boot Record Sector http://www.geocities.com/thestarman3/asm/mbr/NTFSBR.htm I found the following URL describing the FAT32 boot sector, but it does not appear to store an offset. The FAT32 Boot Record under Windows 2000 and XP http://www.geocities.com/thestarman3/asm/mbr/ntFAT32BR.htm Hence this would not appear to be the problem. If there were indeed an offset stored in the boot sector, then resizing back to the original size may have failed to work due to a bug in calculating partition cylinder alignment (bug #432525). This bug was fixed in GParted 0.3.8. IS THE ROOT DIRECTORY OF THE FAT32 FILE SYSTEM USED WHEN RESIZING? ------------------------------------------------------------------ GParted calls the function ped_file_system_resize() in the libparted library to perform a resize of the FAT32 file system. Libparted is produced by the Parted project. Parted Project http://www.gnu.org/software/parted From reading the Application Programming Interface for this function call, I am not aware how exactly the resize is performed for FAT32. Libparted API http://www.gnu.org/software/parted/api/group__PedFileSystem.html A direct review of the parted project's source code would be necessary to identify how the resize is performed. Hence the answer to this question is still unknown.
There was a bug in versions of GParted prior to 0.4.4 that could move the start of a partition, even though the user only intended to resize from the end of the partition. https://bugzilla.gnome.org/show_bug.cgi?id=571151 Perhaps this was the cause of the problem? Since I do not anticipate any further feedback on this bug report, I am closing this bug.
I am still quite sure that the key to this problem is as I suggested in my earlier comments, which are backed up by a Windows Knowledge Base article. After the gparted resize (which WENT OK according to observations of the Win XP partition from being logged in on the Linux partition and looking at the Win XP partition), I was UNABLE to boot Win XP from the hard disk, but WAS ABLE to boot Win XP from the floppy disk. What could possibly be the difference? The difference is in the Win XP boot code. It ASSUMES that there are only a few files in the root level of the C: drive, so only searches the FIRST BLOCK of the directory for NTLDR, and doesn't find it so dies with the error message. But if someone or somebody has temporarily vastly expanded the file index of the C: partition's root directory, the NTLDR (not being near the first of the alphabet) has been pushed way down into the second or third block of the index, but the stupid Win XP boot code has already given up and died with the error message, because it DIDN'T find NTLDR in the index's first block. What or who could have so vastly altered the geometry of the C: partition's root directory's index? Well, gparted could have, if gparted used the C: partition's root directory as temp storage for files during the resize AND the user (me) had a few very large directories, which I did. Being a photographer, I had a few directories with a few thousand small image files PER DIRECTORY. I may be wrong in some details, but I am sure this is the right track. Go read Knowledge Base #320397. I have to say I am rather disappointed with the gparted team's utter failure to even try to comprehend this bug (which no doubt still exists -- it's Win XP's stupid design at the root of the bug, but it is gparted's failure to program around the well known stupidity of the Win XP boot code that causes the failure). You guys cross this bug of as "non-existent" at your great personal risk. I wash my hands of it. Goodbye.
Thank you davide for responding and re-opening this bug. I can understand your frustration. My assumption was that since there was no response to my posting in 2008, that there was no one to further troubleshoot this bug. Your reply shows that my assumption was wrong. For background information, your first bug report unfortunately came in at a time when the original developer was moving away from GParted development. This left the whole project in the hands of a good person who did not have C++ programming experience, but who did valiantly learn how to build and maintain the GParted Live CD. As a result the application C++ code was not touched from late 2006 until early 2008 when I committed my first update. Now onto your problem. GParted uses the parted library libparted to perform the actual resize. I suspect that the source of the problem is within the parted project code. The FAT32 file system can be resized using parted from the command line. You can learn more about how to use parted at the following link: http://www.gnu.org/software/parted/manual/ The parted command to resize the first primary partition to 20 GB would be: parted /dev/sda 1 32.2kB 20GB Note that the commands can also be entered interactively as shown below using the most recent parted 2.0: $ parted /dev/sdd GNU Parted 2.0 Using /dev/sdd Welcome to GNU Parted! Type 'help' to view a list of commands. (parted) print print Model: ATA ST3160022ACE (scsi) Disk /dev/sdd: 160GB Sector size (logical/physical): 512B/512B Partition Table: msdos Number Start End Size Type File system Flags 1 32.3kB 32.2GB 32.2GB primary fat32 (parted) resize resize WARNING: you are attempting to use parted to operate on (resize) a file system. parted's file system manipulation code is not as robust as what you'll find in dedicated, file-system-specific packages like e2fsprogs. We recommend you use parted only to manipulate partition tables, whenever possible. Support for performing most types and operations on most types of file systems will be removed in an upcoming release. Partition number? 1 1 Start? [32.3kB]? End? [32.2GB]? 20GB 20GB (parted) print print Model: ATA ST3160022ACE (scsi) Disk /dev/sdd: 160GB Sector size (logical/physical): 512B/512B Partition Table: msdos Number Start End Size Type File system Flags 1 32.3kB 20.0GB 20.0GB primary fat32 (parted) quit Information: You may need to update /etc/fstab. $ As you might notice from the above warning, the parted code is not as robust as dedicated file system support tools. Unfortunately I am not aware of any other freely available linux tools for resizing FAT16/32 file systems. One challenge we may face is that the parted team is trying to focus on partition editing only, and removing themselves from file system specific stuff as can be seen in the following email thread: http://lists.alioth.debian.org/pipermail/parted-devel/2009-September/003164.html QUESTIONS: 1) Would you be able to test the problem directly using a recent version of parted? 2) If the problem still exists then would you please log a bug with the parted team? The parted web site can be found at the following link: http://www.gnu.org/software/parted/index.shtml 3) Which version of Windows XP are you using now and which version were you using then (e.g, which Service Pack)? The knowledge base article #320397 states: Note If you are using Windows XP with Service Pack 2 (SP2) or you are using Microsoft Windows 2000 with Service Pack 4 (SP4), this is not your issue. View the "More information" section for similar issues. 4) Does the "Bcupdate2.exe C: /F" command fix the problem for you?
I am sure, looking at the contents of article 320397, that bcupdate2.exe would fix the problem. However, the workaround of making a floppy disk boot disk also works. That is the solution I am using. As far as I know, the original bug in Microsoft's boot code has never been fixed. Why not, I cannot say. Ask Microsoft. It is completely stupid to have a long standing bug that requires downloading a utility program as a fix. Why not just fix the bootcode with a normal Windows XP Update??? Let me point out a few things: 1. I had the workaround working almost immediately, back in 2005. I don't have a problem. 2. The resizing done by gparted worked perfectly. There is no bug (that I know of) in gparted resizing code. So gparted doesn't really have a problem (it is Microsoft that has the problem). 3. What I suggested years ago, and am suggesting again for the final time, is that IF gparted triggers this Microsoft bug by using the C: root directory as a temp directory while resizing, THEN there is a very easy way to modify gparted code so Linux and freeware users never encounter the "NTLDR is missing" message after resizing with gparted: MAKE A TINY CHANGE IN GPARTED TO NOT USE THE C: ROOT DIRECTORY AS ITS TEMP SPACE. Use ANY other directory, e.g. Documents and Settings. Or make up a random name for a temp directory and delete it afterwards. Let me quote from article 320397: "SYMPTOMS After you copy many files to the root folder of a boot volume that uses the NTFS file system (and I would add, or the FAT 32 files system), you may receive the following error message the next time that you restart the computer: NTLDR is missing Press CTRL+ALT+DEL to restart. If you remove the files that you copied to the root folder, the master file table (MFT) does not reduce to its original size. "CAUSE This problem may occur if the MFT root folder is severely fragmented. If the MFT root folder contains many files, the MFT may become so fragmented that an additional allocation index is created. Because files are mapped alphabetically in the allocation indexes, the NTLDR file may be pushed to the second allocation index. When this occurs, you receive the error message...(since, I would add what the article does not say, the stupid boot code simply assumes that NTLDR will be found in the first allocation index--probably just an attempt of the idiot programmer to make his boot code smaller). "Typically, files are not written to the root folder..." END OF QUOTE FROM article 320397 My entire effort and interest in this bug (which is two bugs, a hideous Microsoft bug which went unfixed for years, and may still exist, and a gparted innocent usage of the C: root directory as temp space) is to try to get the gparted team to alter their code ever so slightly to sidestep this bug forever, rather than have every gparted user risk running into this same problem, over and over and over and over, forever. My efforts have been totally wasted. The gparted team STILL thinks I am complaining about an actual bug in gparted. I'm not. The gparted team STILL thinks I have a problem booting Win XP. I do not. The gparted team STILL thinks there is something wrong with gparted's resizing code. There probably isn't--I've never had it fail. That Win XP fails afterward is due to a Win XP bug which Microsoft refuses to fix. All I want the gparted team to do is CHECK THEIR CODE, AND IF THEY USE THE C: ROOT DIRECTORY AS TEMP SPACE, to stop doing that. If gparted never used the C: root directory as temp space, then the problem lies elsewhere, I have no idea where, but I am sure the actual bug is in Microsoft's code. Article 320397 admits that, though they don't use the word "bug". Why did I and not every user of gparted for resizing see the problem? Because, being a photographer as well as a software developer, I had several directories on that disk that had a few thousand image files each, and I can well imagine that if those files were copied to the C: root directory during resizing that the allocation indexes would grow much larger than the original Microsoft boot coder ever imagined would be possible. I keep my image files on other disks now. I am not going to copy my image files around on the C: drive like a crazy man, then resize the C: drive, to try to duplicate the problem. For the last time, just look at the gparted code and see if indeed it does use the C: root directory as temp space. If so, fix the problem once and for all.
Thank you davide for your persistence with this report. Following are some answers to your questions. (In reply to comment #15) > As far as I know, the original bug in Microsoft's boot code has never been > fixed. Why not, I cannot say. Ask Microsoft. It is completely stupid to have a > long standing bug that requires downloading a utility program as a fix. Why not > just fix the bootcode with a normal Windows XP Update??? From reading http://support.microsoft.com/kb/320397 I think that this problem might have been fixed with Windows XP Service Pack 2. I am inferring this conclusion from the following quote: Note If you are using Windows XP with Service Pack 2 (SP2) or you are using Microsoft Windows 2000 with Service Pack 4 (SP4), this is not your issue. View the "More information" section for similar issues. It is possible that the conclusion I have inferred is wrong. > All I want the gparted team to do is CHECK THEIR CODE, AND IF THEY USE THE C: > ROOT DIRECTORY AS TEMP SPACE, to stop doing that. If gparted never used the C: > root directory as temp space, then the problem lies elsewhere, I have no idea > where, but I am sure the actual bug is in Microsoft's code. Article 320397 > admits that, though they don't use the word "bug". Short Answer: I checked the GParted source code. It does not use the C: root directory as temp space. The problem lies elsewhere. Long Answer: To expand on the short answer, GParted is unable to resize FAT16 or FAT32 file systems by itself. Instead it relies on a separate, third party project called parted (no leading "G" in the title) to provide this functionality. See the following project link: http://www.gnu.org/software/parted/index.shtml The GParted project does not manage or control the code in the parted project. If changes are desired with the parted project code, then these requests must be communicated to the parted project. > For the last time, just look at the gparted code and see if indeed it does use > the C: root directory as temp space. If so, fix the problem once and for all. The gparted code does not use the C: root directory as temp space.
OK, Curtis, thanks for your persistence also. Please close the bug. I am not willing to try to replicate it since my personal problem was solved long ago, and successful replication would simply wreck a working Windows XP installation anyway, and Microsoft may or may not have fixed it anyway, and I am utterly unwilling to spend the next four years exchanging email with a whole different group of developers. Thanks for your efforts. You are not to blame for a single bit of this. In fact, you seem to be a first class developer yourself, persistent and professional the whole way. David E.