GNOME Bugzilla – Bug 539035
growing a FAT32 parition results in invalid file-system
Last modified: 2010-04-24 10:25:34 UTC
Please describe the problem: When I use gparted to increase the size of a FAT32 partition from 12Gb to 40Gb, (or if I copy a 12Gb FAT32 partition to a brand new 40Gb partition) then the resultant partition has an error. A small yellow warning sign is displayed and "Info" gives an error about being unable to read some information. The resultant file-system seems to almost work at first, but scandisk crashes on trying to check the volume, and there are other errors. Steps to reproduce: 1. by growing a 12Gb partition to a 40Gb one 2. by copying a 12Gb partition on one disk to a 40Gb partition on a second disk 3. by creating a new 40Gb partition and then copying a 12Gb partition into it Actual results: It appears to work, says "Growing file-system" etc, but on completion there is a small ywllow warning sign by the partition, and "Info" says it cannot read some information. Expected results: it to work. Does this happen every time? yes. Other information: The resultant file-system mostly works under windows. However scandisk under windows immediately fails with "not enough memory" error. Scandisk under DOS fails immediately saying the last cluster of the partition is inaccessible and suggests there may be a problem with LBA mode or something.
GParted uses the libparted library from the Parted project to grow FAT32 partitions. To try to diagnose this problem we'll need some more information. 1) Which version of libparted was used? When GParted is started from the command line it will print out the version in use. You could also save the details of the operation and post them here. 2) Did the original FAT32 partition that was copied also display the yellow warning sign? 3) What was the exact text displayed in the information section for the yellow warning sign? 4) Was the original FAT32 partition created by GParted, or by some other program?
Moving this bug from livecd to gparted because the livecd is not likely to be the cause.
Ping jk... Can you answer the questions from comment #1? I have tried creating a 12 GB FAT32 partition, then resizing it to 40 GB, but I have not been able to reproduce the problem. The resize operations completes successfully.
Created attachment 140497 [details] GParted Details for growing 12 GB FAT32 partition to 40 GB See attached GParted details file from successfully growing a 12 GB FAT32 partition to 40 GB.
Hi Curtis, 1) I am using Gparted 0.3.6 2) No the original partition did not display the yellow warning 3) ! Warning: unable to read the contents of this filesystem! Because of this some operations may be unavailable. 4) Original partition was created by FDISK I have just done the whole business again, and it happens again, every time. Exactly same problem. Kind regards, John Kruiniger
Would you be able to post the output from the following command so that we can determine the cluster size of the original partition? NOTE: When running the fsck command, please make sure that the file system is not mounted. You can check which file systems are mounted by simply typing in "mount" at a command prompt. E.g., mount <-- Ensure file system is not mounted fsck.vfat -v /dev/??? <-- Where ??? is the device name for the partition Also, would you be able to try the latest version of GParted (0.4.6)? You can download this new version on the testing branch of GParted Live 0.4.6-1.
Hi Curtis I am now using the latest Gparted live CD 0.4.5-2 I have managed to work out how to save details to a floppy. So I have done a 'check' on the original 12Gb partition and saved the details and I have done a 'check' on the resultant 40Gb partition and saved the details I have attached the two details (original and target) here - hopefully it will tell you all you need to know. Performing the fsck command you requested on the original partition produces: dosfsck 3.0.1, 23 Nov 2008, FAT32, LFN /dev/hdb1: 7144 files, 281338/3170642 clusters Performing the fsck command on the resultant (faulty) partition produces: malloc:Cannot allocate memory Hope all this info helps. Anything else I can do? Kind regards, John Kruiniger
Created attachment 140721 [details] details of check on original partition
Created attachment 140722 [details] details file of check on resultant (faulty) partition
Thank you John for posting these results. Following is a response to your email question, and a suggested next step. EMAIL QUESTION: John Kruiniger wrote: > I suspect it may be something to do with the size of the original disk. > The original disk is a relatively small disk, so has a small cluster > size. When this cluster size is maintained when the partition is > copied or grown to a larger partition on a larger disk, then you end > up with a very large number of clusters on the resultant disk. Too > many clusters for some data structure in the FAT system? ANSWER: From the attachment in comment #8, I can see that the size of a cluster is 4096 bytes. We can determine the maximum size for the volume using information from wikipedia on the File Allocation Table: http://en.wikipedia.org/wiki/File_Allocation_Table Max Volume Size = (Max # of Clusters) * (Size of Cluster) = 268,435,437 * 4,096 = 1.09958527795e+12 Bytes ~= 1,024 GB Hence the cluster size of 4096 bytes does not appear to be a limitation for growing the 12 GB file system to 40 GB. SUGGESTED NEXT STEP: It would be very informative to see the original details log from gparted when you first performed the action of copying/growing the 12 GB partition to 40 GB. Would you be able to reproduce the steps, save the gparted_details.html file, and attach it to this bug report? I also find it interesting from the attachment in comment #9 that dosfsck failed to allocate enough memory while performing a file system check. I wonder if the original file system is severely fragmented, and/or perhaps we have found a bug in the dosfsck command?
Further to the above request for reproducing the steps, would you be able to try it with the latest GParted 0.4.6 and parted 1.9.0? Both gparted-0.4.6 and parted-1.9.0 are packaged on the System Rescue CD: To download SystemRescueCd-x86-1.2.3, visit: http://www.sysresccd.org/Download
Created attachment 140921 [details] details file from original copy and grow operation
(In reply to comment #11) > Further to the above request for reproducing the steps, would you be able to > try it with the latest GParted 0.4.6 and parted 1.9.0? > Both gparted-0.4.6 and parted-1.9.0 are packaged on the System Rescue CD: > To download SystemRescueCd-x86-1.2.3, visit: > http://www.sysresccd.org/Download Hi Curtis, I am now using version 0.4.5-2 which was listed as the latest stable version of the gparted live cd on the download site I used. (Will try the System Rescue CD when I get a chance). I have reproduced the copy and grow operation and attached the details file here. Note that this copy and grow operation APPEARS to work correctly. It says all ok, and I save the details file, it's only after I ok to close that screen, that gparted rescans all the partitions, and then comes up and puts a yellow warning sign on the partition. As to the original partition, it is very clean. I just ran it up under windows and scandisk says no errors. I am now doing a windows defrag on it, and will repeat the operation, but I expect no change. Cheers, JK
Hi, I defragged original partition and repeated operation. Same behaviour. I have attached the details of the copy+grow operation here. Cheers, JK
Created attachment 140929 [details] details file of copy+grow operation, after defrag partition
Created attachment 140931 [details] copygrow details under systemrescue CD Ok I have tried the whole thing using the Systemrescue live CD same behaviour on the copy+grow operation (details file attached) also shows up with the yellow warning sign on the new partition but in this environment when I try to check the new partition it crashes the gparted program! regards, JK
Thank you John for all of the additional testing. I know that copying many gigabytes of data can take quite a long while. As you correctly point out, the details log indicates success at every step of the copy and resize operation. This has me puzzled as to exactly what went wrong such that the destination partition has a corrupt file system. The crash with the latest GParted is a new development with this problem too. With debugging problems of this nature, it is very helpful if I can recreate the problem on my computer. So far I have been unable to recreate the problem, so I will try again. Approximately how much space is in use in the original 12 GB partition?
Another thought I had is that perhaps there are some bad sectors on the destination hard drive. Are you able to test the drive for bad sectors? Many hard drive manufacturers have testing software available for download on their web sites. Be forewarned though that some hard disk tests are destructive and will overwrite the data on the drive. As such you would want a backup of the information before performing such tests.
Another thought that I have is to try to isolate the problem further. For instance, if the 12 GB partition is copied (and the size is kept the same), does the partition show the exclamation point beside it? Then try the grow operation separately to see if that causes the partition to show the exclamation point beside it. Since the source partition (/dev/hdb1) starts at the beginning of the drive and has 63 sectors reserved, then the destination partition should also begin at the start of the drive (/dev/hda) so that the same 63 sectors will be reserved for the Master Boot Record. As you can see I am trying to come up with ways to explore this problem further. It think this last suggestion to try to isolate the problem might be our best bet so far.
Hi Curtis, > Another thought I had is that perhaps there are some bad sectors on the > destination hard drive. I have reproduced the problem copying to several different hard disks, so it's not a problem with bad sectors on the target disk. > Approximately how much space is in use in the original 12 GB partition? 1.05Gb > Another thought that I have is to try to isolate the problem further. For > instance, if the 12 GB partition is copied (and the size is kept the same), > does the partition show the exclamation point beside it? No, this works completely fine, and there are no errors on the destination drive. (So this is what I have been doing - the original 12Gb partition is a clean system disk for a whole bunch of my PCs with identical hardware. I use gparted to quickly put a perfectly working system onto one of these PCs. Now I don't grow the partition to fill the remainder of the hard disk and thus just waster the rest of the space on the hard drive - which is typically 40Gb or 80 Gb nowadays.) > Then try the grow operation separately to see if that causes the partition to > show the exclamation point beside it. > Yes it does. > Since the source partition (/dev/hdb1) starts at the beginning of the drive > and > has 63 sectors reserved, then the destination partition should also begin at > the start of the drive (/dev/hda) so that the same 63 sectors will be reserved > for the Master Boot Record. > > As you can see I am trying to come up with ways to explore this problem > further. It think this last suggestion to try to isolate the problem might be > our best bet so far. I appreciate your efforts. Please bear in mind Curtis, I can't remember the genesis of the original 12Gb partition. I may have actually created the original system disk on a 2.1Gb or even 1.2Gb disk. The original may have even been FAT16 instead of FAT32. I don't know if this makes any difference. The 12Gb partition is currently sitting on a 40Gb disk. Can I send you an image of the 12Gb partition? If you have a 40Gb disk then you should be able to reproduce the problem. Kind regards, JK
Hello, I tried a couple more tests: as I said before, copying the 12Gb partition to a new disk without changing the size works fine. So I tried shrinking the partition to 1.79Gb - worked fine. Then I tried growing the partition to 34.81Gb (not quite the maximum size of the disk) - failed as before, i.e. appeared to work successfully but resulted in a faulty partition with a yellow warning sign on it. hope this helps, regards, JK
Hello I did some further testing - I tried copying the 12Gb partition and growing it to a 300Gb partition on an external USB disk drive I've got. This failed with some out of memory error so that got me thinking. So I doubled the RAM in the PC from 256Mb to 512Mb and retried the 12Gb -> 40Gb copy+grow - it succeeded! the copy+grow from 12Gb to 300Gb still fails though (but does not now report the out of memory error - just dies). Hope this helps, JK
Thank you for your persistence with this problem John. From your testing, it would appear that GParted is able to correctly copy the partition from one drive to another. The difficulty arises when the partition is grown from the original size of 12 GB to something larger (e.g., 40 GB). Now we know that the problem is in growing the partition. :-) AND with your most recent testing the problem appears to be related to the amount of RAM too. It is interesting to note that shrinking the partition worked correctly, but growing the partition to ~34 GB did not result in a working file system. To grow a partition, GParted uses the library libparted from the parted project. Hence we should be able to simulate the problem using parted alone. If this works then we will have isolated the problem to something in the parted code. Following are the commands I used to grow a 12 GB FAT32 partition to 40 using Parted. 1) Start up parted with: parted 2) Select the disk device with: select /dev/sdd 3) Choose MB for default display units with: unit mb 3) Display the partition table with: print <--- print output ---> print Model: ATA ST3160022ACE (scsi) Disk /dev/sdd: 160042MB Sector size (logical/physical): 512B/512B Partition Table: msdos Number Start End Size Type File system Flags 1 0.03MB 13012MB 13012MB primary fat32 <--- end of print output ---> 4) Grow the first partition which starts at 0.03 MB to 40 GB (40960 MB) with: resize 1 0.03 40960 5) Display the partition table with: print <--- print output ---> print Model: ATA ST3160022ACE (scsi) Disk /dev/sdd: 160042MB Sector size (logical/physical): 512B/512B Partition Table: msdos Number Start End Size Type File system Flags 1 0.03MB 40960MB 40960MB primary fat32 <--- end of print output ---> 6) Exit from the parted application with: quit 7) Start up GParted and check if there is a problem with the FAT32 file system in the partition. Ideally, GParted should not show an exclamation point beside the partition.
Created attachment 141023 [details] partition table printout prior to growing
To make it easier to follow the train of thought, I have done my best to copy the relevant parts of our email conversation into this bug. :-) ----- clipped from email 1 ----- > I started up parted from the command line > > I noticed a couple of differences > > Mine says the partition table is "loop" whereas yours says "msdos" > > Mine says the partition starts at 0.00 (not 0.03) even though the > first 63 sectors are unused > > I can't use that resize command - it won't let me resize to a number > beyond 13012 - it just says "the location 35000 is outside of the > device /dev/hda1" ----- clipped from email 2 ----- > Oh that's annoying - I notice that "print all" gives different output > than does "print" > > when I do "print all" it says the partitions are "msdos" not "loop" > and they start at 0.03 > > ooooooh, ok, I get it, I was supposed to select "/dev/hda" not > "/dev/hda1" > > ok here goes again > > ok I tried resize 1 0.03 35000 > > seemed to work fine, print now says the size is 35000Mb > > start up gparted ... no yellow warning on the partition! > > So where does that leave us? ----- clipped from email 3 ----- > Ah, but even though Gparted doesn't put a yellow warning on it, and > indeed it passes a parted "check" > > it still fails a scandisk under windows with insufficient memory ?! > Even now my lab machine has 512Mb! From reviewing all of your testing John, it appears that the source of the problem with the FAT32 file system originates with the resize operation. This problem occurs when using either GParted or Parted. Since GParted uses the library libparted from the parted project, the common ground where the problem likely exists is in the parted code base. The next step is to report this problem to the parted team mailing list at bug-parted@gnu.org. I believe the relevant details are: 1) Growing a 12 GB FAT32 partition with 4096 byte clusters to 40 GB 2) Using a computer with only 256 MB of RAM (and no swap since a live CD was used) --- We suspect that the operation runs out of RAM at some point but does not appear to report an error. 3) The resultant file system fails a Windows scandisk and dosfsck. 4) Problem exists with parted version 1.9.0 (and earlier) Would you be able to report this bug to the parted team? It might be useful to include a link back to this bug report.
For the purpose of record keeping, the post on the bug-parted@gnu.org maling list can be found at: http://lists.gnu.org/archive/html/bug-parted/2009-08/msg00026.html
Many enhancements have been made to parted since this problem was first reported. Would you be able to test the problem with the latest GParted Live 0.5.2-1 which includes parted-2.2?
jk, I'm closing as per last comment. Please reopen if this is still an issue. Thanks in advance.