GNOME Bugzilla – Bug 697518
gparted scans forever blank disk in virtualbox
Last modified: 2013-04-24 16:30: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..
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
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
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
^ 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..
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)
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.
"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...
(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?
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.
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..
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.
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.
"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)
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.
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
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.
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:
+ Trace 231813
Thread 3 (Thread 0xb5d8ab70 (LWP 20857))
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.
Setting this bug status to "NEW" because the problem has been confirmed.
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
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.
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.
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
The code change to address this report has been included in GParted 0.16.0 released on April 24, 2013.