GNOME Bugzilla – Bug 657118
Error while partitioning on USB-pendrive
Last modified: 2013-02-01 08:22:33 UTC
Created attachment 194433 [details] GParted error report See attachment.
From the attachment it appears that there is an inconsistency with the backup sector in the FAT file system. If you have Windows you might try running chkdsk on the drive to try to fix this problem. Alternatively you might try using the dosfsck command to see if it can resolve this discrepancy. Did either of these above approaches resolve the problem?
Thanks for your explanation. The original partition was created by Ubuntu's start-media creator, creating a life-USB-system with 3 GB persistent range, so the inconsistency seems to be caused by it. The intention was to shrink the single partition to 4 GB to have space for a 2nd 12 GB partition for data sharing. Unfortunately I have overwritten the media, so I can't give more info, except that I could boot Ubuntu from that broken media. Additionally, I'm wondering, that the error log reports Media byte 0xf8 (hard disk), because Windows determines "removable media", and for that Windows only mounts the 1st partition, regardless if there are more.
Now I tried again on my new Ubuntu-Live installation. First I run chkdsk /F /X from Windows which found 1 lost file, and corrected. The same error occurred, but I couldn't post it because of bug 657480.
Can you try to run "chkdsk" from Windows?
You mean to run "chkdsk" again after the failed GParted attempt? After it, "chkdsk" from Windows returned OK.
The inconsistency with the backup sector is preventing GParted from being successful in resizing the FAT file system. My hope was that chkdsk on this FAT file system would fix the inconsistency. Then when the discrepancy is fixed GParted should be able to continue with the resize operation. If Windows chkdsk will not fix the problem and dosfsck will not fix the problem then I don't know what tool will fix the inconsistency. Can you try the GParted resize operation after running Windows chkdsk?
> Can you try the GParted resize operation after running Windows chkdsk? I just did, see comment 3.
Created attachment 194976 [details] error details Another try
Created attachment 194977 [details] success details Surprise: The 4th attempt worked, regardless the inconsistency with the backup sector.
I am beginning to think that a hardware problem is the root cause. My reasoning is as follows: 1) The section of the log file in comment #8 indicates that the device /dev/sdc1 has somehow disappeared while GParted was working on it. This is highly unusual. <--- begin log snippet ---> dosfsck -a -w -v /dev/sdc1 dosfsck 3.0.9 (31 Jan 2010) dosfsck 3.0.9, 31 Jan 2010, FAT32, LFN open: No such file or directory <--- finish log snippet ---> 2) Another indicator is that the list of discrepancies seems to be changing since the first post. 3) The final clincher is that the 4th attempt worked. It is difficult to pin down the exact cause with absolute certainty. As a general rule software errors are almost always reproducible with the same set of steps. Hardware errors tend to be more random in nature. Are you able to test the device to see if it is failing or somehow not maintaining a good connection?
(In reply to comment #10) > I am beginning to think that a hardware problem is the root cause. I'm afraid, you're right. I did not have any problems copying data e.g. large mp3-files or videos on this device. All seemed ok. But I too had problems to install Ubuntu on this device, but in the end it seemed to work. Maybe the device has failures while _excessively_ writing/moving data on it, as it happens while installing Ubuntu of moving partitions. But how to verify this? > Are you able to test the device to see if it is failing or somehow not > maintaining a good connection? Don't know how to do this, maybe by chkdsk /F /R ? But I'm afraid stress my USB-flash-RAM too much.
Hardware problems can be tricky to isolate. If you have access to another computer I would suggest trying the same actions using the USB stick on the other computer. If all problems disappear, then the original computer is likely at fault. If the problems continue then it is likely that there is a problem with the USB stick. In the case of hard disk drives, the manufacturers often provide software for testing the disk drives. You might try searching for this test software for your USB stick. Another alternative would be to try overwriting the entire USB stick with zeroes to determine if there are any problems encountered while writing to all of the sectors on the device. To do this you can use the dd command and the special device /dev/zero as the input file. Please let us know how you make out.
Curtis, thanks for your excessive efforts. I will try to check all this error sources some day, and let you know the result. For now, I will go on with other work to do.
Ulf, ping, do you have any update for the bug ?
Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for. Thanks!
(In reply to comment #12) > Hardware problems can be tricky to isolate. > > To do this you can use the dd command and the > special device /dev/zero as the input file. Which block size you would suggest, e.g. to not over-stress the devices maximum write cycles.
(In reply to comment #16) > (In reply to comment #12) > > Hardware problems can be tricky to isolate. > > > > To do this you can use the dd command and the > > special device /dev/zero as the input file. > > Which block size you would suggest, e.g. to not over-stress the devices maximum > write cycles. Since this involves overwriting all of the sectors, I would suggest choosing a block size that is a multiple of the logical/physical sector size shown by the command: sudo fdisk -l -u
(In reply to comment #17) > sudo fdisk -l -u As you can see below, it says 512 bytes, but I can't believe that, as I remember to have read somewhere, that the segments, which are erased at once on a flash media are something about 32..64 KiB. But maybe 64 x 32 x 512 = 1 MiB would be secure. =========================================================================== XX:~$ sudo sfdisk -l -u /dev/sdb nicht erkanntes Format – benutze Sektoren Festplatte /dev/sda: 60801 Zylinder, 255 Köpfe, 63 Sektoren/Spur <snip> Festplatte /dev/sdb: 15600 Zylinder, 64 Köpfe, 32 Sektoren/Spur Warnung: Die Partition sieht aus, als sie gemacht worden für C/H/S=*/256/18 (anstelle von 15600/64/32). Für diese Auflistung nehme ich diese Geometrie an. Einheit = Sektoren von 512 Bytes, Zählung beginnt bei 0 Gerät boot. Anfang Ende #Sektoren Id System /dev/sdb1 * 3504 31950719 31947216 c W95 FAT32 (LBA) Anfang: (c,h,s) erwartet (0,194,13) gefunden (0,1,1) Ende: (c,h,s) erwartet (1023,255,18) gefunden (990,255,18) /dev/sdb2 0 - 0 0 Leer /dev/sdb3 0 - 0 0 Leer /dev/sdb4 0 - 0 0 Leer XX:~$ sudo sfdisk -g /dev/sdb /dev/sdb: 15600 Zylinder, 64 Köpfe, 32 Sektoren/Spur XX:~$ sudo sfdisk -G /dev/sdb /dev/sdb: 6933 Zylinder, 256 Köpfe, 18 Sektoren/Spur ich@Ulfuntu:~$
(In reply to comment #18) > As you can see below, it says 512 bytes, but I can't believe that, as I > remember to have read somewhere, that the segments, which are erased at once on > a flash media are something about 32..64 KiB. > But maybe 64 x 32 x 512 = 1 MiB would be secure. Yes, just use 1 MiB as the block size for dd. I've seen mention of erasure block sizes being between 128K and 4M over the years, presumably depending on the capacity and age of the device. I use a 1M block size when using dd to zero flash devices and spinning hard drives alike. It reduces overhead in the OS and sends big sequential writes to the underlying device which is always the best. Cylinders and heads are meaningless numbers on flash drives completely fictitious spinning hard drives.