Traceback (innermost last): File "/var/tmp/anaconda-7.0.1//usr/lib/anaconda/iw/progress_gui.py", line 20, in run rc = self.todo.doInstall () File "/var/tmp/anaconda-7.0.1//usr/lib/anaconda/todo.py", line 1588, in doInstall self.fstab.umountFilesystems(self.instPath) 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: what: /mnt/sysimage/win98 removeDir: 0 ToDo object: (itodo ToDo p1 (dp2 S'method' p3 (iimage CdromInstallMethod p4 (dp5 S'currentDisc' p6 I1 sS'tree' p7 S'/mnt/source' sS'device' p8 S'hdc' sS'progressWindow' p9 <failed>
Created attachment 4736 [details] ANACDUMP.TXT
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 total 0 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. ***
c.abeln, Please let us know if you are able to reproduce this error ... and thanks for your report! alanh, 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 bug report.
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. ***