Red Hat Bugzilla – Full Text Bug Listing
|Summary:||Installing livecd from usb stick, formatting/partitioning does not complete|
|Product:||[Fedora] Fedora||Reporter:||Traxtopel <traxtopel>|
|Component:||anaconda||Assignee:||Anaconda Maintenance Team <anaconda-maint-list>|
|Status:||CLOSED DUPLICATE||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||rawhide||CC:||anaconda-maint-list, rmaximo, vanmeeuwen+fedora|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2009-05-27 10:25:02 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Traxtopel 2009-05-27 03:08:06 EDT
Created attachment 345569 [details] failed installed log 20090527 This bug is still not resolved, when installing a livecd from a USB stick the partitioning does not complete, i.e. partitioning/formatting does not complete. The USB Key boots correctly, just installation will not take place. Notes If I use the img file and boot with vmware fusion it will install. Problem seems unique when booted from an actual usb stick. The same image will install from cdr/iso. Livecd was created using ext4, usb stick formatted with ext3 Irrespective whether I choose "Use entire drive" or "Replace existing linux system", the installer never moves further, just waits spins, with the next dialog enabled. I have 2 netbooks, a Lenovo S10 & Medion Akoya e1210, both same issue. If I manually create paritions, format then select the partitions but not format the installation will take place. I do notice that mke2fs is defunct. In anaconda.log 04:55:58 DEBUG : Ext3FS.create: device: None ; status: False ; type: ext3 ; 04:55:58 DEBUG : Ext3FS.doFormat: device: /dev/sda1 ; mountpoint: /boot ; type: ext3 ; Thats the last entries and it does not move from there. I even grabbed the git from 26 May 2009, problem still exists. New log 20090527 attached. +++ This bug was initially created as a clone of Bug #501428 +++ Created an attachment (id=344560) anaconda error log If I create a usb stick from a live cd iso(rawhide/f11 - 20080515). Boot from the usb stick, try to install using "liveinst". Partitioning never completes after clicking on Next. Eventually if I do click next i.e. 20 minutes later a error dialog appears. Asks me to format "/" Then I get an Exception Occured Dialog. Error attached to ticket. Note The same image booted from iso installs correctly. This method worked previously with Fedora 10. If I manually format the partition from the console and only assign a mount point in anaconda, it installs correctly. anaconda-22.214.171.124 --- Additional comment from firstname.lastname@example.org on 2009-05-19 01:00:05 EDT --- Created an attachment (id=344563) Using anaconda-126.96.36.199-1 --- Additional comment from email@example.com on 2009-05-19 01:02:02 EDT --- Missed my entry, I tested using anaconda-188.8.131.52-1, anaconda fails now before I can partition. See log. --- Additional comment from firstname.lastname@example.org on 2009-05-19 14:30:14 EDT --- This will be fixed in the next build of anaconda for F11. Thanks for the bug report. --- Additional comment from email@example.com on 2009-05-20 01:33:49 EDT --- So I updated to anaconda-184.108.40.206-1 & pykickstart-1.54-1 from koji. Not sure if the initial bug would be fixed in this. Also seeing this which I am sure is related to the drive not getting formatted. If I select "replace existing Linux system" or "Use entire drive". The following errors occurred with your partitioning: Your / partition does not match the the live image you are installing from. It must be formatted as ext3. This can happen if there is not enough space on your hard drive(s) for the installation. Press 'OK' to choose a different partitioning option. "Use entire drive" should just nuke everything right? --- Additional comment from firstname.lastname@example.org on 2009-05-20 04:54:17 EDT --- Another finding. When you have selected the partitioning of the harddisk, clicked next and waiting for the install to start. The NEXT button is still clickable, if you click on this by mistake or think the install is not running, it will fail. Perhaps this is only present on slower machines. Would it be possible to disable Next after paritioning starts, so this cannot fail? --- Additional comment from email@example.com on 2009-05-25 11:09:15 EDT --- Created an attachment (id=345329) Install Error Log
Comment 1 Traxtopel 2009-05-27 03:09:00 EDT
Created attachment 345570 [details] Failed install log 20090527
Comment 2 Traxtopel 2009-05-27 09:25:35 EDT
I wonder if this is a e2fsprogs bug, seems to be that after formatting the mke2fs becomes defunct.
Comment 3 Chris Lumens 2009-05-27 10:25:02 EDT
*** This bug has been marked as a duplicate of bug 498553 ***
Comment 4 Eric Kerin 2009-07-09 15:41:19 EDT
Created attachment 351139 [details] patch to allow early-exiting when the monitored process exits This appears to be a different bug than 498553. Installing on a netbook where anaconda goes into full-screen mode because the screen is so small, the progress dialog goes full-screen as well (and remains hidden too), it looks like because of this, it takes a long time for the progress pulses to return. (FYI - my machine also happens to be running maximus) Since iutil.py's execWithPulseProgress method reads one character at a time, in cases where the progress.pulse() method takes a long time to return, it slows up the reading of data, and the eventual reaping of the process. Which manifests as a defunct mke2fs process. If you give it long enough, it will continue the install. Long enough being 10 minutes or so, depending on your system. There's a loop in gui.py that smooths the pulses if it took a long time between calls, that's where a lot of the delay is spent, doing processEvents() The attached patch does two things, only the change to iutil.py is really necessary - it just checks to see if the child process has exited already, and breaks if it is, since we don't need the output of the child process anyway.
Comment 5 Chris Lumens 2009-07-09 15:45:35 EDT
I wonder if you wouldn't mind sending your patch to firstname.lastname@example.org? It looks interesting, but I'm probably the only person who will notice it in a bug report, and it'd be nice to get more eyes looking. If not, I'll do the patch review thing here myself. Thanks.