Bug 478824

Summary: Installing to an external usb connected HD fails...
Product: [Fedora] Fedora Reporter: Jóhann B. Guðmundsson <johannbg>
Component: kernelAssignee: Kernel Maintainer List <kernel-maint>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 11CC: kernel-maint
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-06-28 11:03:50 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 Flags
Error.. none

Description Jóhann B. Guðmundsson 2009-01-05 13:09:54 UTC
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

Comment 1 Chris Lumens 2009-01-26 18:52:03 UTC
Did you select your non-USB hard drive as the device to write the bootloader to?

Comment 2 Jóhann B. Guðmundsson 2009-01-26 20:05:58 UTC
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..

Comment 3 Jóhann B. Guðmundsson 2009-01-26 20:54:29 UTC
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"

Comment 4 Jóhann B. Guðmundsson 2009-01-26 22:48:55 UTC
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.

Comment 5 Jóhann B. Guðmundsson 2009-01-26 22:59:54 UTC
Created attachment 330041 [details]
Error..

Comment 6 Jóhann B. Guðmundsson 2009-01-26 23:05:08 UTC
Sorry to hasty 

The installation was a success booting from it was a failure...

Comment 7 Jóhann B. Guðmundsson 2009-01-27 09:46:21 UTC
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.

Comment 8 Chuck Ebbert 2009-01-28 00:23:04 UTC
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...

Comment 9 Jóhann B. Guðmundsson 2009-01-28 10:13:55 UTC
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.

Comment 10 Bug Zapper 2009-06-09 10:34:58 UTC
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

Comment 11 Bug Zapper 2010-04-27 12:40:44 UTC
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

Comment 12 Bug Zapper 2010-06-28 11:03:50 UTC
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.