Bug 495156
Summary: | FSError: mount failed: (2, None) | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Jeffrey R. Evans <theshadow07> |
Component: | anaconda | Assignee: | David Cantrell <dcantrell> |
Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | low | ||
Version: | 11 | CC: | jrb, mmahut, mnowak, pjones, rmaximo, roger.a.luty, smcmackin, vanmeeuwen+fedora, yurigorokhov |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | anaconda_trace_hash:1b91c2741fc234e4298430942977b47dd7765f960376d60b0403dfe2c437fc41 | ||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2010-06-28 11:46:53 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Attachments: |
Description
Jeffrey R. Evans
2009-04-09 23:30:27 UTC
Created attachment 339020 [details]
Attached traceback automatically from anaconda.
Created attachment 339278 [details]
Attached traceback automatically from anaconda.
*** Bug 495369 has been marked as a duplicate of this bug. *** *** Bug 495290 has been marked as a duplicate of this bug. *** *** Bug 495416 has been marked as a duplicate of this bug. *** We can close this one. I acidentally had a filesystem mounted at the time anaconda was querying the storage devices. Once I unmounted the filesystem, anaconda behaved normally. I didn't have filesystems mounted and my bug was marked as a dupe of this one so I don't think that's the only issue here. Shannon this bug was not originally submitted by you. When I submitted the bug initially, I didn't accidentally have a file system mounted. No we can't close this one, it's still legitimate. Created attachment 339495 [details]
Attached traceback automatically from anaconda.
Sorry, I didn't realize they added my report to an existing bug... Created attachment 339503 [details]
Attached traceback automatically from anaconda.
Fix will be in anaconda-11.5.0.45-1 Created attachment 342110 [details]
Crash on customer partition install to SD card from LiveCD
I'm still seeing the attached crash using anaconda 11.5.0.48-2. Boot off a USB LiveCD on a eeePC and use it to install to a SD card. Also the partition anaconda created was still no properly aligned.
Anaconda 11.5.0.52 Still has this issue or a closely related one. We fixed this bug several times throughout this release cycle in anaconda, but we also discovered that a filesystem bug was giving us the same results. I do believe it was fixed there as well. Could you please test the final release and verify that this bug is well and truly dead? I'll try to test it today or tomorrow with the Final release. I tested it on 05-18-2009 with Anaconda 11.5.0.52 and it failed. Is there a particular version of anaconda that I should test with Chris? Created attachment 346076 [details]
Anaconda Installation errors "FakeRAID"
This is using the lastest build available today at my location.
This may seem like an all too obvious question. Why is it that we can't use the code from F9 x64 that works? F9 x64 tests AOK for an existing FAKE or SOFT RAID on either an Nvidia based chipset platform or an ICH10R Intel based chipset platform. Today's Test yields the following error. anaconda 11.5.0.59-1.fc11 exception report Traceback (most recent call first): File "/usr/lib64/python2.6/site-packages/parted/geometry.py", line 128, in intersect return Geometry(PedGeometry=self.__geometry.intersect(b.getPedGeometry())) File "/usr/lib/anaconda/storage/partitioning.py", line 501, in getBestFreeSpaceRegion free_geom = extended.geometry.intersect(_range) File "/usr/lib/anaconda/storage/partitioning.py", line 726, in allocatePartitions boot=_part.req_bootable) File "/usr/lib/anaconda/storage/partitioning.py", line 587, in doPartitioning allocatePartitions(disks, partitions) File "/usr/lib/anaconda/iw/partition_gui.py", line 1017, in refresh doPartitioning(self.storage) File "/usr/lib/anaconda/iw/partition_gui.py", line 1125, in editPartition if self.refresh(justRedraw=not actions): File "/usr/lib/anaconda/iw/partition_gui.py", line 974, in newCB self.editPartition(device, isNew=1) CreateException: Could not stat device /dev/mapper/nvidia_eefffbee - No such file or directory. Created attachment 346486 [details] See Comment #19 This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle. Changing version to '11'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping Please Update status to Assigned. I have reproduced this issue with the latest build of anaconda. This occurs on a RAID0 created on an Intel ICH10R or Nvidia C55 "Soft" RAID controller. The RAID0 Created initially using standard Windows install of either f6 and driver floppy for Windows XP or Thumb drive with Driver for Windows Vista or Windows 7. Let me list steps to reproduce: 1. Insert a LiveUSB Thumb drive or a Fedora 11 install DVD. 2. Reboot System. 3. Boot system to either the LiveUSB Thumb drive or DVD. 4. Select an existing partition. 5. Select Delete. 6. Click on the create button. 7. Select / for the mount point. 8. Select Ext3 or Ext4 for the partition type. 9. Enter the correct free space value of the available disk slice. 10. Press continue to allow the changes to take affect. 11. Observe. Result: Segmentation fault provides the attached debug. Expected result: Anaconda to partition the slice of the RAID0 array selected in the manner selected and for the installation to proceed. I was successful in Installing F11 by doing the following. Use the F9 Full Install DVD to create the partition on the RAID0 array. Perform a minimal F9 install. Reboot. Select the existing partition and instead of using the DELETE button, merely selecting that as the install target. This is not the expected behavior and requires a great deal of user intervention. I have this issue as well under Fedora 11, is this bug fixed in newer anaconda versions? I need to install Fedora 11 and am running into this bug. I was wondering if anybody had initrd and vmlinuz files handy (F11) with a fixed version of Anaconda? I tried using the F12 initrd and vmlinuz to install Fedora 11 but I got a bunch of different errors when it tried to run anaconda. So if anybody has initrd and vmlinuz for F11 handy I would really appreciate it. Yuri I think this is now fixed in F-12? I am confused about whether this issue has been resolved. I see several bugs reported about this and have not seen any definitive resolution. Just as the bug report indicates, I receive "mount failed: (2, None)" after copying the Live CD image to the virtual hard drive during installation as a QEMU-KVM guest. I am using Fedora 11 as my host and guest and built several KVM-enabled host kernels for testing. The preferred host kernel I use is 2.6.31.6-rt19 (PREEMPT_RT) along with qemu-kvm.0.11.0-rc2. I created a 10G raw disk image to use for the installation. I created a custom partition table on the disk image as follows: /dev/sda1 200M /boot /dev/sda2 8G / /dev/sda3 200M (swap) I would like to know if there is a solution to this issue. I tried using Fedora 12 as the guest but received an exception error at the same point during installation. If anyone has some suggestions or a solution to this problem, please let me know. This message is a reminder that Fedora 11 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 11. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '11'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 11's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 11 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping Fedora 11 changed to end-of-life (EOL) status on 2010-06-25. Fedora 11 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed. |