Description of problem: Using an uptodate FC6, runing the 2.6.19-1.2911.6.5.fc6xen kernel, the installation of a xen guest using the virt-managner (0.2.6) fails with an 'exec of anaconda failed: Access a corrupted share library' error. See attachement Version-Release number of selected component (if applicable): How reproducible: all the time Steps to Reproduce: 1. use virt-manager to create a xen guest 2. point the install Media URL at 'nfs:bigpapi:/vol/engineering/redhat/rawhide-i386' 3. Use a "Normal Disk Partition" 4. set "VM Startup Memory to 336 5. Click Finish to get things rolling 6. Take all the default until anaconda crashes. Actual results: Expected results: Additional info:
Created attachment 153435 [details] Screen Shot of the error
I was going to report a different problem, when I was trying to install FC7 under FC6 Xen. But on my case, nothing was being shown in the virtual machine display or the VM serial console. Not even the loader messages. I have tried previous Test versions of FC7 as install media, and FC7-Test2 have worked for me. I will try to reproduce the problem here. I hope the loader will run, today, otherwise I will have to debug the loader problem before I get the "Accessing a corrupted shared library" error. :)
I have not been able to reproduce exactly your problem, but the problem I am having here may be related: - Using virt-install from rawhide-20070502 (I don't have a more recent FC7 installation media available yet) doesn't work. Nothing is shown, not even the "running /sbin/loader" messages in the console - Using virt-install from FC7-Test2 works (the installer dialogs are shown) - Using initrd.img from rawhide-20070502 and kernel from FC7-Test2 works - Using initrd.img from FC7-Test2 and kernel from rawhide-20070502 doesn't work So, it seems that the kernel has a problem, or the installer doesn't like the newer kernel. I am investigating what could be wrong with the newer kernel.
Just to check if the problem I am having can really be related with your problem, could you check what is the behaviour when using FC7-Test2 and FC7-Test3 as installation media? If it shows the same behaviour I have here (it doesn't work on Test3 but works on Test2), then the cause of the problem I am seeing here may be the same. If the results are different, then probably we have two different bugs to investigate and solve.
Created attachment 155201 [details] Screen shot of test2 hang Test2 hung much earlier that Test3
Created attachment 155243 [details] screen shot of F-7 Test4 Failure Well test4 is failing an a different place... not sure if that is a step ahead or back... but it is different...
Steve, were you installing fully virt or paravirt? Can you reproduce off other install media, just to validate that it's not something like a corrupt mirror?
The F7 test4 kernels still have all the horrible data corruption bugs we recently fixed. Though we mostly saw them on Dom0, we never ruled out the possiblily of them impacting DomU too. I'd not bother trying any of the testN releases of F7 and go straight to very latest rawhide which is very nearly GA now.
change QA contact
paravirt to the installing question.... So would install f7 and using KVM be a better option at this point? I do have correct hardware...
steved - has anyone stopped by to take a look at your machine / use it for testing?
No... but I was thinking of moving on to F7, but I would be more than willing to wait if that would help this out.... Question: Should I be able to install a F7 Client with the latest FC6 xen kernel?
(In reply to comment #14) > Question: Should I be able to install a F7 Client with the > latest FC6 xen kernel? Yes, you are. Not being able to install it under FC6 is a bug on either F7 or FC6. However I don't know how much time we will take to find the cause and fix this.
Fedora apologizes that these issues have not been resolved yet. We're sorry it's taken so long for your bug to be properly triaged and acted on. We appreciate the time you took to report this issue and want to make sure no important bugs slip through the cracks. If you're currently running a version of Fedora Core between 1 and 6, please note that Fedora no longer maintains these releases. We strongly encourage you to upgrade to a current Fedora release. In order to refocus our efforts as a project we are flagging all of the open bugs for releases which are no longer maintained and closing them. http://fedoraproject.org/wiki/LifeCycle/EOL If this bug is still open against Fedora Core 1 through 6, thirty days from now, it will be closed 'WONTFIX'. If you can reporduce this bug in the latest Fedora version, please change to the respective version. If you are unable to do this, please add a comment to this bug requesting the change. Thanks for your help, and we apologize again that we haven't handled these issues to this point. The process we are following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp We will be following the process here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this doesn't happen again. And if you'd like to join the bug triage team to help make things better, check out http://fedoraproject.org/wiki/BugZappers
This bug is open for a Fedora version that is no longer maintained and will not be fixed by Fedora. Therefore we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen thus bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.