After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 697518 - gparted scans forever blank disk in virtualbox
gparted scans forever blank disk in virtualbox
Status: RESOLVED FIXED
Product: gparted
Classification: Other
Component: livecd
0.15.0
Other Linux
: Normal critical
: ---
Assigned To: gparted maintainers alias
gparted maintainers alias
Depends on:
Blocks:
 
 
Reported: 2013-04-07 23:00 UTC by westlake2012
Modified: 2013-04-24 16:30 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
gdb backtrace for "Searching /dev/sda partitions" hang (4.18 KB, text/plain)
2013-04-18 18:46 UTC, Curtis Gedak
  Details
Patch to fix gparted scans forever blank disk in virtual machine (1.34 KB, patch)
2013-04-18 19:23 UTC, Curtis Gedak
none Details | Review

Description westlake2012 2013-04-07 23:00:13 UTC
Now I have used gparted live cd in the past in virtualbox, but the last time I tried was few months back..  

Currently the following occurs
( iso's tried
gparted-live-0.15.0-1-i686-pae.iso
gparted-live-0.15.0-3-i486.iso
gparted-live-0.15.0-3-i686-pae.iso
)

There is not optimizing profile selected
(
literal options in "System/Basic" -- right-click machine vm on list and selected settings
no "Linux" optimization profile is used, which means it should load more securely- 
Operating System- "Other", Version "Other/Unknown" is used as well as choosing a non-64bit option for 2 other Linuxes.. still didn't pass :(
)

^ The mentioned three iso's was tried on two vbox app editions, a prior one, and the current one which as of now on my system as: 4.1.18_Ubuntu r78361 . 

I have decided to update Vbox after I noticed one Gparted Live cd was not fully completing a scan on a blank drive. 

I'm sorry this seems like a lame report, but I never had this problem before-- And the drive is completely blank.

When the drive (outside of gparted live cd), has been "initialized", then when I bootup with Gparted Live cd the scan of the drive is completed quickly&successfully.

If I'm the only one suffering from this bug, I would definitely have to upload a video because I really rely on using Vbox for testing Linux systems.

I hope it's vbox that's the problem and not Gparted.. Perhaps I can file a bug to Vbox? but I mean what good would that do? I can successfully run much larger iso projects..
Comment 1 westlake2012 2013-04-07 23:34:17 UTC
I do not get any problems at all with gparted-live-0.13.1-2.iso -- which was the gparted live cd I was using before, hmm something went wrong between this edition and 0.15.x 

When i boot with an 0.15.x cd, while the gparted program has been scanning for more than 30 seconds(like forever), i do ctl-alt-f1 and see 
"
..
Setting default value
<>
Failed to read: session.screen0.toolbarbar.XXXX
Setting default value
Failed to read: session.screen0.iconbar.XXXX
Setting default value
/dev/sda: unrecognized disk label
"

About 11 different session.screen0.XXX messages with a recurring "Setting default value" message before /dev/sda
Comment 2 Curtis Gedak 2013-04-07 23:38:33 UTC
Is the blkid command running?

You can check by opening a terminal window and running the following command:

    ps -ef | grep blkid

There have been some reports about blkid taking an exceedingly long time to 
finish scanning on some systems.


You can try running blkid yoursefor from a terminal window with the following command:

   sudo blkid -c /dev/null
Comment 3 westlake2012 2013-04-10 05:02:02 UTC
Yeah it does..
"
 <pid> tty2 S+ 0:0 \_ grep blkid SHELL=/bin/bash TERM=linux LC_ALL=en_US.UTF-8 USER=root COLUMNS=500 MAIL=/var/mail/root PATH=/usr/local/sbin:/usr/local/bin:/usr/local/bin/:/usr/sbin:/usr/bin:/usr/sbin:/sbin:/bin:/sbin/:/usr/sbin:/sbin:/usr/sbin PWD=/root LANG=en_US.UTF-8 SHLVL=1 HOME=/root LOGNAME=root _=/bin/grep
"
(..trivial, no aesthetic issues for me but I see a one or two redundancies for in $PATH)

(I made columns be 500, in order to see full grep line)

I see a new pids when i retry the pf|grep command -- When I retry it, it is always a new pid no matter when. (I see as low as every second I get a new pid--  I can see the pid# increases by 2 for every second)




(In reply to comment #2)
> Is the blkid command running?
> 
> You can check by opening a terminal window and running the following command:
> 
>     ps -ef | grep blkid
> 
> There have been some reports about blkid taking an exceedingly long time to 
> finish scanning on some systems.
> 
> 
> You can try running blkid yoursefor from a terminal window with the following
> command:
> 
>    sudo blkid -c /dev/null
Comment 4 westlake2012 2013-04-10 05:03:54 UTC
^ tried with gparted-live-0.15.0-3-i686-pae.iso, 
during the above session(comment#3), if I type 'blkid<enter>' I see /dev/sr0 and /dev/loop0 and I get a prompt again in shell right away..
Comment 5 westlake2012 2013-04-10 05:09:28 UTC
For sudo blkid -c /dev/null, the output is exactly the same as Comment#4

"
/dev/sr0: LABEL="GParted-live" TYPE="iso9660"
/dev/loop0: TYPE="squashfs"
"

(trivial- I tried both with root account and from '$ prompt+sudo' -- same result)
Comment 6 Curtis Gedak 2013-04-10 14:43:09 UTC
The output in comment #3 above appears to be grep finding itself running.  I do find it odd that it lists a bunch of environment variables.  'Haven't seen that myself before.

Would you be able to try:

   ps -ef | grep blkid | grep -v grep

This above command should remove grep finding itself running.  :-)

Also, do you have a floppy device configured in the BIOS but no physical floppy drive on the computer?

If you you might be encountering a problem listed in our FAQ.

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


Note that running "blkid" without the "-c /dev/null" will simply retrieve information from a cache file (if available).  The extra parameters are to instruct blkid to perform a fresh scan.  The concern is if a fresh scan is taking longer than a few seconds.
Comment 7 westlake2012 2013-04-10 18:06:38 UTC
"See, FAQ point 11:
Why does "Scanning all devices..." take exceedingly long on some computers? 
http://gparted.org/faq.php#faq-11"


lol.. dude I mention virtualbox on the original post :))

This physical computer runs Virtualbox, and I use gparted within the vm (My physical computer was bought back in 2008)..

I use the same VM, i simply swap iso's from 0.15 back to 0.13 .. I 've been using 0.13 for a long time before deciding to try 0.15 about a week ago.. 

I also tried non-optimized Linux profile, as 'Other/other' with vbox..

In any way, having gparted to work in Vbox is very critical to me because I demonstrate Linux videos on how to use gparted.. and right now I feel crippled.. I want to know what else I can do...
Comment 8 Curtis Gedak 2013-04-10 18:30:42 UTC
(In reply to comment #7)
> "See, FAQ point 11:
> Why does "Scanning all devices..." take exceedingly long on some computers? 
> http://gparted.org/faq.php#faq-11"
> 
> 
> lol.. dude I mention virtualbox on the original post :))

Many virtual machines can also have floppy devices defined and optionally hooked to an image file or physical floppy drive, so the question still stands - do you have a floppy defined in the BIOS?
Comment 9 Patrick Verner 2013-04-10 18:47:16 UTC
I'm running Virtual Box 4.2.10 r84104 and gparted-live-0.15.0-3-i486.iso. It works for me.

* New disks (no partition table)
* Formatted disks
* Floppy controllers (with and without actual floppy drives)
* With and without real USB drives

That version seems a little old. I would update VB and see if that fixes the issue. If Ubuntu doesn't have a newer package, maybe you could install it manually. This looks like a VB bug. For fun you could always test System Rescue CD or Parted Magic and see if you get the same result.
Comment 10 westlake2012 2013-04-11 00:20:49 UTC
I discovered something that was causing it.

Other/other (Vm's settings, 1st tab, 'General/Operating System'->Other, 'Version'->other)  does not work   (A)


Linux/otherLinux does not cause any stall..   (B)


I believe 'other' in (A) is meant for 32-bit.. I narrow it down between A and B I must of been using this setting for another Linux boot cd..


Weird this fails.. 0.13 doesn't complain.. must be related to the kernel

I believe (B) is supposed to work with anything, albeit a slower VM for anything hosted within it

This must be a bug with either Vbox or Gparted

fwiw, if anyone wants to add something to this, please do, I'll refrain this thread to a vbox bug report..
Comment 11 Patrick Verner 2013-04-11 01:26:29 UTC
Virtual Box 4.2.10 r84104 does not display this behavior. I can set it to "Other" and "Other" and it works without any hang. I really don't believe this is a GParted Live bug. It looks like VB already fixed this upstream.
Comment 12 westlake2012 2013-04-11 03:01:37 UTC
That's what I'm thinking(I indeed tried to search for a similar bug on vbox's tickets but couldn't). btw thanks for your feedback but I do hope you were trying 0.15 and not 0.13 -- 0.13 does not cause this issue on the current vbox i'm using with Other/other -- if you can see it under my light it would be concerning for anyone to wonder what is the culprit.. so far I narrowed it down to those settings so I'm pretty sure it's vbox


(In reply to comment #11)
> Virtual Box 4.2.10 r84104 does not display this behavior. I can set it to
> "Other" and "Other" and it works without any hang. I really don't believe this
> is a GParted Live bug. It looks like VB already fixed this upstream.
Comment 13 westlake2012 2013-04-11 03:04:25 UTC
"Patrick Verner 2013-04-10 18:47:16 UTC
I'm running Virtual Box 4.2.10 r84104 and gparted-live-0.15.0-3-i486.iso. It
works for me."

Patrick you tried the same iso I'm trying? (gparted-live-0.15.0-3-i686-pae.iso , and not the i486 one)
Comment 14 Patrick Verner 2013-04-11 14:14:50 UTC
You said in your first post that gparted-live-0.15.0-3-i486.iso didn't work.

I have tried these with no problems:
gparted-live-0.15.0-3-i486.iso
gparted-live-0.15.0-3-i686-pae.iso

4.1.18 is almost a year old. In the software world, that is a long time. Reporting bugs on an old version really doesn't make much sense. If you do report a bug to VB, the first thing they are going to tell you to do is upgrade to the newest version. I don't understand why you can't just upgrade VB and see if they fixed it.

I do nearly 100% of all my livecd and software tests with VB. I am very familiar with it. I tweaked every possible option and no matter what I do, GParted works without error.
Comment 15 westlake2012 2013-04-11 23:39:33 UTC
I discovered that the problem was related to the Vm's settings. Where System and Version were set to 'other'.. This is a bug in 4.1.18.

When I set System/version to Linux/otherLinux, Gparted does not stall when scanning a blank drive (Gparted stalls when scanning a blank drive when the VM settings System/version is set to 'Other'/'Other Linux' 'exact' literals. I bug reported to vb's bugtracker)(all 3 iso'z that didn't work, now work)

Thank you for your feedback Curtis..but I still can't tell exactly what's causing this because afaik someone told me System/version doesn't perform optimizations(perhaps I was misinformed on that).  Currently I'm awaiting feedback on my Vbox bugreport and I can relay the bugtrack-id to you if you think vbox isn't the problem.. 

-Scott


(In reply to comment #2)
> Is the blkid command running?
> 
> You can check by opening a terminal window and running the following command:
> 
>     ps -ef | grep blkid
> 
> There have been some reports about blkid taking an exceedingly long time to 
> finish scanning on some systems.
> 
> 
> You can try running blkid yoursefor from a terminal window with the following
> command:
> 
>    sudo blkid -c /dev/null
Comment 16 Curtis Gedak 2013-04-12 14:34:08 UTC
Thank you westlake2012 and Patrick for your work to investigate this problem.

It sounds like there is some sort of incompatibility between GParted Live (which is based on Debian Live), and some settings in versions of Virtual Box.

To try to identify what might be causing the GParted scanning to run for a long time, would you be able to attach a file to this report listing all of the processes that are running while GParted is scanning?

The output from "ps -ef > all-processes.txt" might help to identify what process is taking so long.
Comment 17 Curtis Gedak 2013-04-18 18:46:09 UTC
Created attachment 241843 [details]
gdb backtrace for "Searching /dev/sda partitions" hang

While testing gparted-live-0.16.0-beta1-i486.iso in a brand new VMware Player (5.0.2 build-1031769) virtual machine I encountered this exact problem.

The VM was configured with two new disks that have never been written to an hence did not contain a partition table.

I tried recreating the problem on a physical machine using dd to "zero" the initial sectors of the drive, but the problem did not occur.

Next I installed the necessary compile and debugging tools into the virtual machine to get a stack trace.

The important part of the stack trace is repeated here:

Thread 3 (Thread 0xb5d8ab70 (LWP 20857))

  • #0 pthread_cond_wait
    from /lib/i386-linux-gnu/libpthread.so.0
  • #1 g_cond_wait
    from /lib/i386-linux-gnu/libglib-2.0.so.0
  • #2 Glib::Cond::wait(Glib::Mutex&)
    from /usr/lib/i386-linux-gnu/libglibmm-2.4.so.1
  • #3 GParted::GParted_Core::ped_exception_handler
    at GParted_Core.cc line 3527
  • #4 ??
    from /lib/i386-linux-gnu/libparted.so.0
  • #5 ped_exception_throw
    from /lib/i386-linux-gnu/libparted.so.0
  • #6 ped_disk_new
    from /lib/i386-linux-gnu/libparted.so.0
  • #7 GParted::GParted_Core::get_device_and_disk
    at GParted_Core.cc line 3372
  • #8 GParted::GParted_Core::set_devices_thread
    at GParted_Core.cc line 279

This lead Phillip Susi and I to look at the ped_exception_handler code again, and Phillip noticed we were missing the mutex.lock/unlock around the other cond.signal in the exception handler.

This fixed the problem for me.  A patch is coming shortly for inclusion in the GParted 0.16.0 release.
Comment 18 Curtis Gedak 2013-04-18 18:51:00 UTC
Setting this bug status to "NEW" because the problem has been confirmed.
Comment 19 Curtis Gedak 2013-04-18 19:23:36 UTC
Created attachment 241852 [details] [review]
Patch to fix gparted scans forever blank disk in virtual machine

Attached is a patch to fix gparted scans forever blank disk in virtual machine problem.

Mike,

Could you please review and commit if okay?

I would like to include this patch in the official GParted 0.16.0 release.

Thanks,
Curtis
Comment 20 Mike Fleetwood 2013-04-19 10:22:40 UTC
I've reproduced this fault too.  VitrualBox 4.1.22 with CentOS 5.9
installed on the first virtual hard drive and a second virtual hard
drive which had been zeroed.  GParted gets stuck forever at:

    Searching /dev/sdb partitions       [ #######              ]

Stack trace for the relevant thread looks the same as from comment #17
above.

Fix works.  Tested on virtualised CentOS 5.9 and physical Fedora 14.


I'll apply the fix to GParted GIT repo later today.  I haven't go access
to my private key until about 19:00 UTC today.
Comment 21 Mike Fleetwood 2013-04-19 10:33:27 UTC
Whilst testing on Fedora 14 I just happened to see this one off:

    (gpartedbin:25259): GLib-CRITICAL **: g_source_unref: assertion `source != NULL' failed

I can't re-produce it.  I was just generally switching between drives 
and refreshing.  Makes me think that there might be another subtle
currency heap issue lurking somewhere.  Definitely not caused by this
patch.
Comment 22 Mike Fleetwood 2013-04-19 17:05:39 UTC
Patch from comment #19 has been applied to the git repository for
inclusion in the next release of GParted.

The commit can be viewed here:

Fix gparted scans forever blank disk in virtual machine (#697518)
https://git.gnome.org/browse/gparted/commit/?id=51b8e241bcf674cde34495df9b0af07ffcdf9ac2
Comment 23 Curtis Gedak 2013-04-24 16:30:13 UTC
The code change to address this report has been included in GParted 0.16.0 released on April 24, 2013.