Bug 264041 - Anaconda reports problem in umounting /mnt/source in FC7.90
Anaconda reports problem in umounting /mnt/source in FC7.90
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Anaconda Maintenance Team
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2007-08-29 12:24 EDT by cdputnam@ucsd.edu
Modified: 2007-11-30 17:12 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-09-21 13:54:20 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description cdputnam@ucsd.edu 2007-08-29 12:24:46 EDT
Description of problem:

I'm trying to install Fedora 7.90 from a DVD on my Dell Optiplex
GX270 (replacing, not upgrading an older unimportant Fedora core 
installation that was wiped during a crashed Fedora 7 installation).

During the checking package dependencies (the progress bar does not
reach completion), I consistently get the error:

"An error occurred unmounting the disc.  Please make sure you're
not accessing /mnt/source from the shell on tty2 then click OK to

When I switch to tty2 (ctrl-alt-2), I am able to determine that the
current working directory 'pwd' is '/'.  Intriguingly, issuing the
command "ls" seems to hang this shell (which could not be recovered with
^C to kill the command or ^Z to put it in the background).

Version-Release number of selected component (if applicable):

Installation from Fedora 7.90 DVD

How reproducible:

Completely reproducible

Steps to Reproduce:
1.  Boot from FC7.90 installation DVD
2.  Select install options
3.  Tell installation to install
Actual results:

Error message listed above

Expected results:

Installation to proceed to writing to the ext3 / partition

Additional info:
Comment 1 cdputnam@ucsd.edu 2007-08-29 15:51:47 EDT
I have been able to work around this problem by adding "noshell" to the
boot commands.  I'm having additional problems later on:

File "/usr/lib/python2.5/pickle.py",
     line 971, in load_string
File "/usr/lib/python2.5/pickle.py",
     line 858, in line dispatch[key](self)
Comment 2 Jeremy Katz 2007-08-31 14:51:12 EDT
HAve you verified your media using the mediacheck/
Comment 3 cdputnam@ucsd.edu 2007-08-31 16:50:31 EDT
The media passed the mediacheck that runs prior to install (I presume 
it check the entire DVD).  I did not check the SHA1SUM of the downloaded  
iso image used to burn the DVD. 
I currently believe that the media was at fault as the install logs  
(under "noshell") complained about not being able to recognize the  
format of some png images. 
Because I was having DVD issue, I tried to and successfuly installed 
Fedora 7 using the LiveCD (which I did test via SHA1SUM).  The Fedora 7  
DVD iso, which I also only checked via the media test, had also given  
me a lot of grief. 
So sorry for the noise. But I am curious as to why the media test prior 
to install didn't flag either DVD as bad--does it use a less sophisticated 
algorithm than SHA1SUM?. 
Comment 4 Jeremy Katz 2007-09-21 13:54:20 EDT
Unfortuantely, it's just that different access patterns cause drives to act
differently.  The medaicheck is an md5sum across the data area of the CD -- but
sometimes complete linear reads work fine and it's only seeking back and forth
across the disc that causes problems :(

I'd suggest trying different DVD media and/or burning at lower speeds as often
that helps in cases like this.

Note You need to log in before you can comment on or make changes to this bug.