Red Hat Bugzilla – Bug 478824
Installing to an external usb connected HD fails...
Last modified: 2010-06-28 07:03:50 EDT
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
Steps to Reproduce:
1. Insert dvd
2. Install to usb connected HD
3. Boot from usb externally connected HD..
Tested with sata drive
Did you select your non-USB hard drive as the device to write the bootloader to?
I wrote the boot loader on the external HD
Booted of the external HD
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]
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
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:
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:
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.