Description of problem: installer stalls Version-Release number of selected component (if applicable): mageia3 beta4 (dvd) How reproducible: (tested in vbox) two blank drives of 8 gigs /dev/sda /dev/sdb Set two physical raid partitions on each drive create md0 for /dev/sda1 and /dev/sdb1 (each raid array is level1, aka raid1) On seeing the raids tab, I selected the md0(red rectangle) and when I clicked on 'ext4' the partition window exited/closed and returned me to a new dialog of partitioning. The drives were blank again. I tried to repeat what I did, but instead this new dialog window closed and a 'Partitioning' small box showed up and stayed.. (I tried to recreate a physical raid partition on /dev/sda) Reproducible: Steps to Reproduce:
/dev/sda1 and /dev/sdb1 were 7 gigs in size, so the md0 array would be a raid1 where I tried to create a 7 gig partition to host '/' I know that if I used 1 or 2 gigs to host /, might be insufficient for the dvd installer
Scott, As we discussed on irc, I can't recreate this bug, so I'm going to close it, as "works for me". Feel free to reopen it, if you can recreate it.
Status: NEW => RESOLVEDCC: (none) => davidwhodginsResolution: (none) => WORKSFORME
Keywords: (none) => TriagedAssignee: bugsquad => thierry.vignaud
Can you try again, then plug an usb key to the VM, go to console 2 when you see the bug (alt+ctlr+f2), then run the "bug" command. Then attach the report.bug.xz file you'll found on the usb key
Keywords: (none) => NEEDINFO
I tried to reproduce it and couldn't. Not sure why it was occurring.. I've noticed something similar, I just reported this, but does Mageia's installer partitioning tool use a similar library as gparted? https://bugzilla.gnome.org/show_bug.cgi?id=697518 -- I get something where the a 'scan' of a blank drive just stalls.. (0.15+, but with 0.13 iso's never stalls -- some of you probably use gparted live cd, and I know it's a valuable tool to compare against what the installer does)
I filed a bug to both vbox and gparted Apparently with Vbox, one can use gparted 0.15 live cd in a Linux/OtherLinux setup, but not Other/other (Vm settings, 1st tab General/Operating System) gparted-live-0.15.0-3-i686-pae.iso This can be helpful to know.. current version i'm using is 4.1.18-- and I know that if I used Other/other it would be problematic with gparted So from my experience I guess I can say I'll have to wait to find out if this is indeed expected -- but meanwhile for anything Linux I will always use 'Linux/*' -- despite the fact from my understanding 'Other/other' should work for everything(but it doesn't) Perhaps I was using Other/other with the Mageia installer.. If you guys want me to verify this one more time and report if I can reduplicate this bug#9598 I can do that..but I wouldn't see much gain, and vbox would be the one to blame if i can reduplicate it.. However I have used Other/other multiple times in the past with Linux iso'z without issue, this would be the first time (with the gparted 0.15 cd).. Anyone has something to add to this? From my understanding it's important because i'm sure more than myself depends on using Vbox for testing..and anything that can add an insight can help optimize settings to look at.. I never had done this(referencing another bugzilla's url), but I believe I had to because Gparted is a very must tool for using.. and I was having a very unexplained problem which I think is related.. (and I hope it's a bug with Vbox-- off-topic, would anyone happen to know if 'System/Linux, Version/*' performs optimizations of some sort vs Other/other ?) https://bugzilla.gnome.org/show_bug.cgi?id=697518 " 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 "
Status: RESOLVED => REOPENEDResolution: WORKSFORME => (none)
I was able to reproduce this bug.. but it's dam hard to keep track what i do.. just a minute ago it reoccurred (I believe I was also using divider=10 with boot cd kernel argument)
will try this (In reply to Thierry Vignaud from comment #3) > Can you try again, then plug an usb key to the VM, go to console 2 when you > see the bug (alt+ctlr+f2), then run the "bug" command. > Then attach the report.bug.xz file you'll found on the usb key
(sorry, cant reproduce, i'll just create a new bug report if it ever occurs again, but i'll make sure i have exactly what took place-- I'll also make sure i've been using divider=10.. but I do know that the current version of Vbox that i'm using if I don't use Linux/OtherLinux rather than Other/other in the Vm system settings(I'm going to try to see if I can upgrade Vbox that's not avail in my current repositories, Gparted disk scan will stall.. in any case, I try to use divider=10 as i think dave suggested to make sure i dont have a stall issue)
Status: REOPENED => RESOLVEDResolution: (none) => FIXED