Red Hat Bugzilla – Bug 502771
Installing livecd from usb stick, formatting/partitioning does not complete
Last modified: 2009-07-09 15:45:35 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.
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.
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.
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.
--- Additional comment from firstname.lastname@example.org on 2009-05-19 01:00:05 EDT ---
Created an attachment (id=344563)
--- Additional comment from email@example.com on 2009-05-19 01:02:02 EDT ---
Missed my entry, I tested using anaconda-126.96.36.199-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-188.8.131.52-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 ---
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
Created attachment 345570 [details]
Failed install log 20090527
I wonder if this is a e2fsprogs bug, seems to be that after formatting the mke2fs becomes defunct.
*** This bug has been marked as a duplicate of bug 498553 ***
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.
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.