Red Hat Bugzilla – Bug 20006
Last modified: 2007-04-18 12:29:34 EDT
Traceback (innermost last):
line 20, in run
rc = self.todo.doInstall ()
File "/var/tmp/anaconda-7.0.1//usr/lib/anaconda/todo.py", line 1588, in
File "fstab.py", line 503, in umountFilesystems
isys.umount(mntPoint, removeDir = 0)
File "isys.py", line 113, in umount
raise ValueError, "isys.umount() can only umount by mount point"
ValueError: isys.umount() can only umount by mount point
Local variables in innermost frame:
Created attachment 4736 [details]
Could you please give the steps required to duplicate this problem?
I haven't reproduced it. When it happened, Anaconda asked me to report the
bug - so I did.
I think it happened when trying to install Linux 7.0 on my DELL Inspiron 7500
laptop. I had chosen Custom Install and all packages - the partition I was
installing too was too small. I can't remember the exact conditions, when I
enlarged the partition and tried again to install, all went fine.
I had a failed install that caused the same error. The cause was RAID0
partitions that had the partition types set to Linux (83) rather than Linux
raid autodetect (FD). The kernel's raid routines ignore the partition type and
check each actual disk partition for a signature, so the system under normal
circumstances will operate just fine like this. However, the installer tries
to mount the individual partitions of the RAID array as ext2 partitions. This
doesn't cause an error at first (see below), so the installer doesn't seem to
catch it. When it tries to unmount the partition, it's not mounted properly
and that causes an unhandled exception. This occurs with RHBA-2000:084-04.
Although the relase notes that it is supposed to fix crashes on mounting non-
Linux partitions, I don't think this situation was anticipated.
It appears that mount will successfully mount the first volume in a linear
(RAID0) set, but it won't operate correctly as a filesystem.
# mount -r -t ext2 /dev/hdb1 /mnt/foo
# ls -l /mnt/foo
?--------- 0 root root 0 Dec 31 1969 /mnt/foo
# umount /mnt/foo
# ls -l /mnt/foo
This crashes the installer. Setting the partition type to something besides
regular Linux makes the installer skip it.
Anyway, changing the partition types to FB resolved the error.
Er, correction, partition type *FD*.
*** Bug 20152 has been marked as a duplicate of this bug. ***
Please let us know if you are able to reproduce this error ... and thanks for
this sounds like a corner case, we'll consider that as an enhancement request
... thanks for your notes!
*** Bug 19979 has been marked as a duplicate of this bug. ***
No, I'm sorry, I haven't been able to reproduce it. What do you want me to do
next time it happens?
*** Bug 20672 has been marked as a duplicate of this bug. ***
*** Bug 22827 has been marked as a duplicate of this bug. ***
*** Bug 22733 has been marked as a duplicate of this bug. ***
*** Bug 24531 has been marked as a duplicate of this bug. ***
*** Bug 34738 has been marked as a duplicate of this bug. ***
*** Bug 36399 has been marked as a duplicate of this bug. ***
Created attachment 30154 [details]
Bug output traceback
I've experienced what appears to be the same problem. I have a RAID0 HPT370
configuration, and was able to recreate the problem twice (text and gui mode
install). I've attached the output from the installer when it croaked onto this
The traceback is not the same. The symptoms are the same. I will try to bypass
this now using alanh's comments. I reported this anyway cause perhaps my output
will do some good .. (or point me in another direction in case I am wrong about
the fact that it is a duplicate). Thanks !
*** Bug 67348 has been marked as a duplicate of this bug. ***