Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 588493 - Unable to select local BIOS RAID drive as boot drive
Summary: Unable to select local BIOS RAID drive as boot drive
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 13
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Hans de Goede
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: F13Blocker, F13FinalBlocker
TreeView+ depends on / blocked
 
Reported: 2010-05-03 19:56 UTC by James Laska
Modified: 2013-09-02 06:48 UTC (History)
4 users (show)

Fixed In Version: anaconda-13.40-1
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-05-05 17:26:50 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
Screenshot.png (deleted)
2010-05-03 19:56 UTC, James Laska
no flags Details
/tmp/*log (tgz) (deleted)
2010-05-03 20:01 UTC, James Laska
no flags Details

Description James Laska 2010-05-03 19:56:12 UTC
Created attachment 411107 [details]
Screenshot.png

Description of problem:

In cleardisksel, I have a local BIOS RAID device, and a remote iSCSI device.  I'm not able to select the local BIOS RAID device as my boot device.  It seems to only allow selecting the remote iSCSI device for boot.

Version-Release number of selected component (if applicable):
 * anaconda-13.39

How reproducible:


Steps to Reproduce:
1. Boot the installer on a BIOS RAID system
2. Manually add an iSCSI remote volume
3. Attempt to use the iSCSI volume as a data partition, and install to the local BIOS RAID adapter
  
Actual results:

See attached screenshot.

Expected results:

The same thing in the screenshot, but with the local BIOS RAID adapter selectable.

Additional info:

 * See attached tarball containing /tmp/*log files

Comment 1 James Laska 2010-05-03 20:01:12 UTC
Created attachment 411110 [details]
/tmp/*log (tgz)

Comment 2 Adam Williamson 2010-05-04 00:55:09 UTC
I have a case jlaska thinks is similar.

1. Write the F13 TC1 netinst.iso to a USB stick with livecd-iso-to-disk (to test #568343)
2. Boot the installer and proceed.
3. At disks-to-be-involved stage, check the system hard disk (you can't uncheck the USB stick, so both are checked as you proceed).
4. At the 'Data Storage Devices' / 'Install Target Devices' selection stage, note that you cannot set the system hard disk as the Boot device, whether you add only the system disk to the 'Install Target Devices' set, or both the system disk and the USB stick. Only the USB stick can have the 'Boot' radio button clicked. If you try to proceed with only the system hard disk in the 'Install Target Devices' set, anaconda refuses as nothing has 'Boot' clicked.

I can't proceed further in the install with both devices selected and the USB stick set to 'Boot', and see what ultimately happens, as I can't really install anything to the hard disk in the test system. Sorry.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 3 Adam Williamson 2010-05-04 00:59:22 UTC
Not sure whether the above is serious enough to make this a blocker...

Note that this seems specific to the netinst.iso-written-to-USB-stick scenario; if I boot from a normally-burned DVD of the full DVD ISO, with the USB stick connected, and select both the USB stick and the system hard disk as storage devices, I don't hit the bug: at the 'DSD' / 'ITD' stage I *can* set the system hard disk as the boot device. Haven't tested with netinst.iso-written-to-DVD, but I rather suspect it'd work.

Comment 4 Hans de Goede 2010-05-04 08:35:20 UTC
Have you actually tried to click on the radio button in the selection ?

The radio button gets automatically set to the 1st boot device, which when booting of a usb stick is the usb stick, if you've filtered out the usb stick then we will use the next first boot device as indicated by the BIOS. It could be the BIOS does not provide EDD info for the raid set when booting from usb stick and then we will determine which is the 1st boot device by sorting by name. So the iscsi disk comes first.

You can however change the default selection by clicking the radio button.

Comment 5 James Laska 2010-05-04 12:19:50 UTC
(In reply to comment #4)
> Have you actually tried to click on the radio button in the selection ?
> <snip>
> You can however change the default selection by clicking the radio button.    

As noted in comment#0, "I'm not able to select the local BIOS RAID device as my boot device."  The radio button is not selectable for some reason.

Comment 6 Adam Williamson 2010-05-04 13:22:40 UTC
impact:

<hansg> Any time we get the boot disk wrong (which we do as we use heuristics) and any time the user does not want to select what we think will be the  boot disk for installation the user looses

makes it clearly a blocker.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 7 Hans de Goede 2010-05-04 14:09:51 UTC
This is fixed in anaconda-13.40-1, moving to modified.

Comment 8 James Laska 2010-05-04 14:26:26 UTC
Confirmed fix using anaconda-13.39-1 + http://people.fedoraproject.org/~jwrdegoede/f13-updates.img

Comment 9 Adam Williamson 2010-05-05 16:58:27 UTC
We should now be able to confirm that this bug is fixed using the images here:

http://alt.fedoraproject.org/pub/alt/stage/13.0505/Fedora/i386/os/images/

if we have not yet confirmed the fix, can anyone able to reproduce this bug please test with one of those images and check that the bug is fixed? Thanks.

Comment 10 James Laska 2010-05-05 17:26:40 UTC
Confirmed fix using vmlinuz, initrd.img and install.img from the URL in comment#9.

Comment 11 Adam Williamson 2010-05-05 17:40:53 UTC
I confirm that this works with the 0505 image in my situation too.


Note You need to log in before you can comment on or make changes to this bug.