GParted hang while Scanning all devices for 10 to 15 mn

[Pascal Mons]

sudo blkid command hangs as well and does not return anything in an acceptable time.

when trying to launch gparted from the command line I get an error message.

If I close the hanging window of gparted "Scanning all devices..." then when attempting a relaunch it crash at startup.

I had this kind of behaviour before for blkid and later on it reverted to a normal behaviour. Now again blkid is not working and gparted is for the first time not working as well. e.g. I have to wait for 10 to 15 mn to get it up and running.

This erratic behaviour of blkid and gparted is unerving.

I am running Ubuntu 12.04 LTS

[Curtis Gedak (gedakc)]

Do you have a floppy device enabled in your BIOS, but no physical floppy drive in your computer?

See:
Why does "Scanning all devices..." take exceedingly long on some computers?
http://gparted.org/faq.php#faq-11

This has been a problem in the past.

[Pascal Mons (anton+)]

Thank you for your feedback. I was able to reproduce the bug today. It is not linked to any floppy device at all since I have used the same hardware for one year and that was working properly.

In fact this bug is appearing right during and after the installation of VMware Workstation 9.0.2 for Linux x64. I can see that :

sudo blkid

takes now in the 10 to 15 mn to complete vs. less than a second. This has the same effect on gparted. If I happen to close gparted while "Scanning for all devices" then a subsequent launch will have it to crash right after getting the system password. I need to restart Ubuntu to attempt a relaunch of gparted.

Unfortunately removing VMware Workstation does not solve the issue. They obviously tinker something in the Ubuntu file system to make this happen to 'blkid' and 'gparted'. This may be as well because of a weakness in the code of linux Ubuntu which is affected by something from the VMware installation process.

I am trying to find a way to report this bug to VMware ... Since I happen to have a working image of Ubuntu 12.04 made a month ago with CloneZilla I was able to pinpoint the problem. However it is quite unerving that a "commercial" program could derails basic functions of the OS and impact through it other applications.

If you have any other thought, please let me know.

[Phillip Susi (psusi)]

Does ls /dev/fd* show anything?

[John Buczek (johnb0647)]

I'm also seeing gparted (V0.12.1) spend 20+ min. Either there are two very similar problems or this is not directly related to VM ware.

I'm running Ubuntu 12.10 AMD64

Also VBox 4.2.0 r80737 but I have no direct evidence that's related.

I first noticed the problem after the most recent kernal update (3.5.0-27 generic) but may be related to a new mb installed about the same time. Prior to those changes gparted worked great.

There was no floppy activated on the old mb.
The new mb, Gigabyte 800GM-D2H has no fd controller and there are no fd options in the BIOS.

gparted has become unusable. After every operation it re-scans eating another 20 min.

[Phillip Susi (psusi)]

Please run sudo strace blkid > output and attach the resulting output file here. You can ctrl-c after a minute or two.

[Curtis Gedak (gedakc)]

John and Antonio19,

When this problem occurs, is there at least one disk device that does not contain a valid partition table?

You can check using the "sudo fdisk -l" command.

I am curioius because this might be related to a gparted upstream bug report:

Bug 697518 - gparted scans forever blank disk in virtualbox
https://bugzilla.gnome.org/show_bug.cgi?id=697518

[John Buczek (johnb0647)]

Even though I could not find any reference to fd0 in the usual tools, out of desperation I tried the "blacklist fd0" cure as recommended elsewhere.

The problem has vanished.

I'm assuming this is some obscure bug in the Gigabyte BIOS.

Thanks

John

[Pascal Mons (anton+)]

I can confirm today that it's not directly linked to VMware Workstation ... However I had an image restored from before this bug appeared and I was just free of this bug until a few days ago when I installed QEMU and today KVM. I suspect that QEMU did bring back the issue ...

I know that Oracle VirtualBox uses parts of QEMU, I don't know yet for VMware.

I am in contact with VMware about this issue and as of last week they were ot able to reproduce this bug.

I have an old graphic card ATI Radeon 3870 and an ASUS Motherboard P5Q3 Deluxe WiFi. I have a new nVidia card GTI 660 Ti which I will install my be next week.

Can other people affected by this bug post their hardware configuration ?

Can you please elaborate on the "blacklist fd0" ? Thank you.

[Phillip Susi (psusi)]

Antonio, do you have /dev/fd0? ( run ls /dev/fd0 ), and can you please run the strace I asked for?

[Pascal Mons (anton+)]

OK. No need to strace. I did the same trick as john Buczek. My system is working now. I did have a floppy appearing in fact on the left column of Nautilus. The following Command Lines made it disappear instantly.

I went to unix.stackexchange.com to get a solution : "Linux, disable /dev/fd0 (floppy)"
http://unix.stackexchange.com/questions/53513/linux-disable-dev-fd0-floppy

Namely :

$ echo "blacklist floppy" | sudo tee /etc/modprobe.d/blacklist-floppy.conf
$ sudo rmmod floppy
$ sudo update-initramfs -u

The result is immediate, no need to reboot and lasting. May be I will have to do it again at the next kernel update ?

The trouble came from the fact that although I have no floppy disk on my hardware system, the ASUS BIOS is declaring it. Hence the trouble with Linux. At least on Ubuntu the thing to do is to blacklist the module associated with /dev/fd0

I have re-install VMware in addition to QEMU-KVM and everything is working fine, gparted and the CL sudo blkid as well.

This is closing this bug.

[Phillip Susi (psusi)]

Rather than blacklist the driver in Linux, you should disable the floppy in the BIOS. Most BIOS factory default assumes there is a 1.44MB floppy, so you have to change the configuration to no floppy.