Gparted scan for device infinitely because of filesystem check (dosfsck)

[Saivann Carignan]

Binary package hint: gparted

Gparted freezes when starting while a external USB HD is connected and unmounted. It keeps scanning HD for hours and Dosfsck uses 100% of the CPU, even when Gparted is closed.

the USB HD contain 2 unmounted partitions, the first is Fat32 and the other is ext2. They were automounted and unmounted just before starter Gparted.

The steps to reproduce this are :

1. Connect a external HD with two partitions, 1 Fat32 and 1 ext2
2. Umount the partitions with sudo umount /dev/sdb1 and /dev/sdb2
3. Start Gparted

Gparted is now looking for HD for hours and the CPU keeps at 100% even when Gparted is closed.

ProblemType: Bug
Architecture: i386
Date: Sat Jun 23 19:27:32 2007
DistroRelease: Ubuntu 7.04
ExecutablePath: /usr/bin/gnome-panel
Package: gnome-panel 1:2.18.1-0ubuntu3.1
PackageArchitecture: i386
ProcCmdline: gnome-panel --sm-client-id default1
ProcCwd: /home/zxz
ProcEnviron:
 PATH=/home/zxz/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
 LANG=fr_CA.UTF-8
 SHELL=/bin/bash
SourcePackage: gnome-panel
Uname: Linux zxz-laptop 2.6.20-16-generic #2 SMP Thu Jun 7 20:19:32 UTC 2007 i686 GNU/Linux

[Saivann Carignan (oxmosys)]

I can't reproduce this bug anymore, I set it to invalid.

[Colin (colin-)]

I'm having trouble with this right now. GParted never seems to finish scanning all devices.

[Saivann Carignan (oxmosys)]

Thanks for your comment, can you tell which version of gparted you are using? You can know this by typing this on a terminal :
apt-cache policy gparted

Can you also reproduce this bug from within a terminal and copy all the outputs that you get here? If possible, use the latest version of Gparted which you can install within Linux Ubuntu Gutsy.

[vpribish (vpribish)]

This just happened to me too, I reformatted an old WD 205BA drive to a single primary fat32 partition and when I try to access it again dosfsck takes 100% cpu.

here is the info you sought in a prior comment:
vincent@gq:~$ apt-cache policy gparted
gparted:
  Installed: 0.3.5-1ubuntu3
  Candidate: 0.3.5-1ubuntu3
  Version table:
 *** 0.3.5-1ubuntu3 0
        500 http://us.archive.ubuntu.com hardy/main Packages
        100 /var/lib/dpkg/status
vincent@gq:~$ sudo gparted
======================
libparted : 1.7.1
======================

At this point gparted launches but never gets past "scanning all devices" and dosfsck takes 100%cpu.
when I kill dosfsck gparted proceeds and displays the usual stuff except that the offending partition has the triangle-with-and-exclamation point icon after the device name.

I've given up and put an ext3 partition on it instead - but I hope this helps because fat32 is sort of the lingua-franca of filesystems.

[Saivann Carignan (oxmosys)]

Since dosfsck seems to be the real problem here, I added dosfstools to the list so bug triagers for dosfsck can take a look at it. Thanks for reporting!!

[Onno Benschop (onno-itmaze)]

Which version of dosfsck?
What happens if you use dosfsck on the drive?
Is there any indication from your process-list which dosfsck command is being executed?

[Saivann Carignan (oxmosys)]

vpribish : Is it possible for you to try what Onno Benschop asked?

[markboo (markboo99)]

I'm having the same problems. I have a 2tb external drive connected by USB. Formated to fat32 using OSX Disk Utility, Connected to Intrepid, Unmounted, then started gparted.

Keeps spinning on "Scanning all devices..."

a ps -waux | grep dos gives these processes:

sh -c dosfsck -a -v /dev/sdc1

dosfsck -a -v /dev/sdc1

[Simon Ellwood (simonellwood)]

I have this problem today.

My System is an up to date 8.10 Ubuntu.

I have a attached a 2.5" USB enclosure with a 30GB drive in it.

The drive has a Primary FAT32 partition and a further extended FAT partition on it.

[oss_test_launchpad (oss-test-launchpad)]

I confirm this bug for Ubuntu 8.10 64-Bit with gparted 3.8.0 that ships with Ubuntu 8.10.

I tried to re-format an external Freecom HDD drive that had a broken filesystem, apparently due to a crash of Ubuntu's kvpm (http://www.kde-apps.org/content/show.php/kvpm?content=98298).

Trying to format this HDD with gparted in ext3, the first time gparted made my whole system freeze completely. After reboot, I tried to format the HDD again and gparted told me that everything had been formatted fine. However, after refreshing, gparted told me that this HDD had an "unknown filesystem". (Just to be complete: I then formatted it NTFS and gparted again told me everything was fine. Trying to copy some files onto this HDD, however, Ubuntu stopped copying and reported an I/O error. Checking on a Windows system as suggested by Ubuntu, I then noticed that the filesystem created by gparted was inconsistent (chkdsk /f).)

[oss_test_launchpad (oss-test-launchpad)]

PS Note that I had similar problems with a 0.4.1-2 gparted live cd, so this seems to be a severe bug in gparted itself.

[Fred Germain (frederic-germain)]

Happens also on live CD jaunty

When gparted is in "Searching /dev/sda partitions" state, which take a while, the result of a ps -efH gives :
ubuntu 10921 1 0 20:53 ? 00:00:00 gksu /usr/sbin/gparted
root 10922 10921 0 20:53 ? 00:00:00 /bin/sh /usr/sbin/gparted
root 10929 10922 0 20:53 ? 00:00:00 hal-lock --interface org.freedesktop.Hal.Device.Storag
root 10930 10929 12 20:53 ? 00:00:11 /usr/sbin/gpartedbin
root 11056 10930 0 20:53 ? 00:00:00 sh -c dosfsck -a -v /dev/sda5
root 11057 11056 36 20:53 ? 00:00:32 dosfsck -a -v /dev/sda5

/dev/sda5 is an umounted FAT partition.

gparted really should not call dosfsck at this part of partition scanning. dosfsck -a might modify the partition without user consent !

I think I also have the problem at ubuntu install, which is blocked at the "scanning for partition" step but I'm not 100% sure about this.

[Geoffrey G Wright (geoffreygwright)]

I get the same issues with the internal HDD. There's an NTFS partition and if it's not mounted I can't run Gparted. It will hang at "searching /dev/sda partitions". If I close Gparted I can't access any NTFS partitions on that drive. There's no dosfsck running but I do notice ntfsresize is running. When I kill that I can access my partitions again. I can't unmount the NTFS partition using Gparted because as soon as it tries it does the above.

I resized this partition using Gparted a few days ago - Gparted indicated the process was successful. Windows can access it.

Seems like a problem caused by Gparted invoking ntfsresize - why should it do that? I noticed this problem when trying to install Mint and Ubuntu - the install process never reaches the disk partitioning stage. Obviously a nasty issue if first-time Ubuntu users come across it.

[Curtis Gedak (gedakc)]

The source of this problem is that GParted uses the "dosfsck -a -v" command to determine the number of used sectors in a FAT16/32 file system. This value is important to GParted when determining the smallest value to which a FAT16/32 file system can be shrunk.

A similar problem exists for NTFS partitions. Gparted uses the "ntfsresize --info --force --no-progress-bar" command to determine the smallest size to which the NTFS file system can be shrunk.

If the partition is mounted, then GParted can retrieve this information by another method (using a statvfs system call). Otherwise GParted must resort to other methods such as the above commands.

This bug report is related to a problem reported in GParted upstream at the following:
http://bugzilla.gnome.org/show_bug.cgi?id=569921

Does anyone know a better way to determine the number of used sectors in a FAT16 or FAT32 file system?

[Geoffrey G Wright (geoffreygwright)]

Thanks for that info, it's very interesting. I ran "sudo ntfsresize --info --force --no-progress-bar /dev/sda8" and it took over 6 minutes. Then I opened GParted with the NTFS partition unmounted and it hung for 6 minutes. Then I started GParted with the NTFS partition mounted then used GParted to unmount it - it hung for ... 6 minutes.

I suppose I was being a *little* impatient before, however I did abort two installs and killed GParted numerous times before I found out what was going on here so it seems like something in this interaction between GParted and ntfsresize needs to be fixed.

[Curtis Gedak (gedakc)]

Out of curiousity, does the "sudo ntfsresize --info --force --no-progress-bar /dev/sda8" command run faster after the drive has been defragmented?

[Geoffrey G Wright (geoffreygwright)]

You could be onto something! I'd just assumed the partition wouldn't be fragmented cos it was only created last week and it was less than 50% full. All I'd done was restored a load of files, reduced the size by 3GB, then left it.

However I just booted into XP, ran the defragmenter and it's in atrocious state. Just the 'Anlayse' portion took several minutes. After deleting loads of files (down to 30% of 300GB) and 90 minutes defragmenting the progress had only reached 6% - I'm not sure whether to continue with that.

Note I backed up and restored using Rsync - I guess that was a bad idea.

[Curtis Gedak (gedakc)]

It will be informative to learn the results of your defragmentation testing.

[Geoffrey G Wright (geoffreygwright)]

My method of defragmenting was to delete everything - the regular method seemed a bit intensive and I was worried I'd do irreparable damage. After that the ntfsresize command took about 30 seconds. I then used GParted to delete and recreate the partition. The command completed in one second. Then I restored all the files in Windows (114GB or 280GB used) - Win XP's defrag utility now shows no defragmentation - the command takes 20 seconds.

[Curtis Gedak (gedakc)]

Thanks for the extra information regarding running the command on a non-fragmented file system.

Your testing confirms that it is beneficial to have the file systems defragmented before using GParted to manipulate the partitions.

[Jan Claeys (janc)]

It would be useful if we could determine the number of unused blocks in another way... :-/

As I told @gedakc on IRC before, it seems like the FAT filesystem header (? I need to investigate some more) has an optional field that may store that number, but the fact that it's optional doesn't sound like we can count on it...

And I guess something similar is true for NTFS: seems like detecting free space (sometimes?) requires us to walk all over the whole filesystem...

[Samir AMARY (samir-amary)]

I had the same issue.

The workaround I found :

Remove dosfstools package. (sudo aptitude remove dosfstools).

Hope that will help.

Cheers

[Curtis Gedak (gedakc)]

Samir, the disadvantage to removing the dosfstools package is that operations on FAT16/32 file systems will no longer be supported.

[Umang Varma (umang)]

Removing dosfstools fixed it for me also.

Regardless of what may be causing the issue, I feel that this bug requires higher priority since gparted is unusable without the workaround (which isn't a very good one given that FAT16/32 files systems will stop working).

[wolfen69 (wolfen69)]

Gparted scans for devices with no end.

[wolfen69 (wolfen69)]

Just tried Samir's suggestion of removing dosfstools, and it did not help. It still scans for devices endlessly.

[Curtis Gedak (gedakc)]

An extremely fragmented NTFS file system will also cause this delay. Be sure to try defragmenting first.

[Phillip Susi (psusi)]

Closing gparted task since this is a dosfstools problem.