Description of problem: I do believe this work in F7 or F8 Preupgrade is affected by this as well 445650 This is something we need to add to Anaconda test cases both IDE, SATA and large USB keys ( 16 & 32GB ) Anaconda detects the usb external hd fine.. Installing and partitioning goes well.. Booting from the external does not work.. First the grub entry that Anaconda creates is wrong... It should be (hd0,0) Always I believe... ( That is if the user intended to boot from that externally connected HD ) The real problem i think is in the initrd img that gets created. This is easily recreated just install to an usb externally connected HD Do it and you will get my drift.. Version-Release number of selected component (if applicable): F9 to present How reproducible: Always Steps to Reproduce: 1. Insert dvd 2. Install to usb connected HD 3. Boot from usb externally connected HD.. Actual results: Failure. Expected results: Work Additional info: Tested with sata drive
Did you select your non-USB hard drive as the device to write the bootloader to?
Nope I wrote the boot loader on the external HD Booted of the external HD Grub loaded... Then when you try to boot the kernel shit goes wrong First the hd entry in grub seem to be wrong ( does not detect any img ) changing it to (hd0,0) gets me a step further then kernel fails to load What I would do to debug this issue would be to look at what's the difference between grub/kernel on an live usb vs the one anaconda creates when installing to an external usb connected HD. Because I think these setups should be identical..
Ok spoke a bit with wwoods on devel on and he as you as well mentioned on QA had tested installing to USB now the only difference from my installation testing from his is that I choose do a custom partition layout. We both chose default and we both choose to install the bootloader on the MBR of the USB device. I'm going to test doing it with the defaults and if successful test creating the exact same layout using custom partitioning. ( The reason I choose to do custom layout is because I want the disk to be strictly ext3/4 to avoid certain lvm extra steps ) I'll report back how things go.. Hopefully we can narrow this down to "custom partitioning"
Select which drive(s) to be used for installation My external usb connected HD got detected as "sdc" Which I selected to boot from as well.. Then I choose the default and begun installation. This has been Confirmed working. So we can narrow this down to "Custom partition layout" Node to self if not already existing a test cases for that.
Created attachment 330041 [details] Error..
Sorry to hasty The installation was a success booting from it was a failure...
Perhaps this should be moved to kernel. I asked around and got an explanation on what was happening there <cebbert> viking-ice: the disk is showing up after the system tries to mount it There was a bit more discussion on fedora-kernel irc channel last night. Anyway I recommend you move this bug to kernel since this has nothing to do with Anaconda.
How could this be a kernel bug? It takes time for USB disks to be discovered and mkinitrd is supposed to wait until they are...
So is this an mkinitrd bug? If so then just move the report against mkinird. Do we have some kernel parameter to slow down the boot process to allow all the "detection" to complete before proceeding We could then direct users to use that as a workaround until a proper solution is found.
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
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.