Bug 635332 - On system with multiple disks, anaconda does not offer target device selection screen
On system with multiple disks, anaconda does not offer target device selectio...
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
14
i386 Linux
low Severity high
: ---
: ---
Assigned To: David Lehman
Fedora Extras Quality Assurance
:
Depends On:
Blocks: F14Beta/F14BetaBlocker
  Show dependency treegraph
 
Reported: 2010-09-18 23:13 EDT by John Watzke
Modified: 2013-01-10 01:13 EST (History)
7 users (show)

See Also:
Fixed In Version: anaconda-14.17.4-1.fc14
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-09-22 00:07:49 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Anaconda logs from install (67.80 KB, application/x-bzip-compressed-tar)
2010-09-19 14:04 EDT, John Watzke
no flags Details
F14 Alpha Boot Loader Select (563.22 KB, image/png)
2010-09-19 23:20 EDT, John Watzke
no flags Details
F14 Alpha Bios Order (638.20 KB, image/png)
2010-09-19 23:22 EDT, John Watzke
no flags Details
F14 RC2 Bios Order (510.50 KB, image/png)
2010-09-19 23:22 EDT, John Watzke
no flags Details

  None (edit)
Description John Watzke 2010-09-18 23:13:50 EDT
Description of problem:
I installed 14BetaRC2 i386 on a system for testing.  After installation, the system fails to boot.  I get "Error 17: Cannot Mount Partition".

Version-Release number of selected component (if applicable):
FC14 Beta RC2 netiso i386

How reproducible:
Always (I tried two installs)

Steps to Reproduce:
1. Install i386 netiso
2. System fails to boot after install
  
Actual results:
System fails to boot after install

Expected results:
System should boot into FC14 Beta RC2

Additional info:
Other items that may or may not be of interest.  My system has 4GB of ram so I'm trying to boot a PAE kernel.  In addition, I'm booting off a USB hard drive (although this worked just fine in RC1).
Comment 1 Adam Williamson 2010-09-19 02:54:55 EDT
We're going to need more data here. What install layout did you choose, and did you wipe the USB stick before installing to it? Can you get any more detailed log than that? (Try booting without the 'rhgb quiet' parameters). Can you attach the details of the partition layout of both the USB stick and any drives in the machine you're testing on? (the 'print' output of parted or fdisk's display or whatever). I will try and test this later also. Thanks.
Comment 2 John Watzke 2010-09-19 14:01:30 EDT
Okay, so I've tested x86_64 netinstall and also the i386 DVD install and both end up with this issue.

I have an external hdd case that has a USB connection so I'm using that rather than a USB flash.  I use this same setup for all of my testing so this seems to be a new issue.

When I'm going through the various iterations of install media, I always select "Custom Partition Layout" so I can specifically choose the layout of the drive.  I've got an internal disk at /dev/sda which is my working OS @ F13 so I want to make sure the partitioner doesn't touch it.  I've already got /dev/sdb (my USB attached hdd) laid out as ~300GB / and 4096MB swap.  So on each install, I select them and set the / mount point and set both / and swap to reformat.

---------------------------
Here's the layout straight from fdisk:

Disk /dev/sdb: 320.1 GB, 320072933376 bytes
255 heads, 63 sectors/track, 38913 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x0007b964

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1   *           1       38245   307200000   83  Linux
/dev/sdb2           38245       38914     5369856   82  Linux swap / Solaris

Disk /dev/sda: 320.1 GB, 320072933376 bytes
255 heads, 63 sectors/track, 38913 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xc23bc23b

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1               1        7649    61440000    7  HPFS/NTFS
/dev/sda2   *        7649        7675      204800   83  Linux
/dev/sda3            7675       38913   250923841   8e  Linux LVM

---------------------------

I'm a bit green with diagnostic log on boot issues so if you could point me to a specific log I can pull I'll get it from the USB hdd.  For now, I'll wrap up at least all anaconda logs so you can see if there is anything interesting in there.
Comment 3 John Watzke 2010-09-19 14:04:27 EDT
Created attachment 448303 [details]
Anaconda logs from install
Comment 4 John Watzke 2010-09-19 16:05:54 EDT
I know what is wrong.

It's something that changed between RC1 and RC2.  The bios boot order of the disks is detected differently when it comes time to install the bootloader.  RC1 was autoselecting /dev/sdb MBR as the place to install grub so I just went with the defaul.  RC2 is autoselecting /dev/sda MBR (which I don't want) and then I have to go change the "Bios Boot Order" in the options to get a chance to select /dev/sdb.  Previously, I was inadvertently installing to /dev/sdb1 which is why it wouldn't boot.

So, if this default MBR install location change was intentional, then there is no bug and I need to pay more attention when installing.  If the change was not intentional and the default selection of /dev/sda MBR and /dev/sdb1 is not correct then there is a slight problem which is probably not a beta blocker.
Comment 5 John Watzke 2010-09-19 16:09:25 EDT
satellit_ on #fedora-qa pointed me to his bug 621414.  I've set that as a see also since it seems related to this issue I'm seeing.
Comment 6 Adam Williamson 2010-09-19 17:36:04 EDT
it's almost impossible for this to be a change from rc1 to rc2. the rc1->rc2 delta is just:

https://admin.fedoraproject.org/updates/fedora-logos-14.0.0-1.fc14
https://admin.fedoraproject.org/updates/sugar-chat-67-1.fc14

neither of those packages could affect this bug, so it's almost certainly some change in how you're doing the install.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 7 John Watzke 2010-09-19 20:54:01 EDT
I'm sure you're right that it didn't happen between RC1 and RC2.  I was looking at the test wiki and over what I had done.  I think that RC2 came out before I had actually finished burning all of the disks for each install type and verified the disks.  I don't think I had completed an install before that point.

Let me go get a DVD for Alpha to test this out for sure.  I am positive that I didn't have to muck with the bootloader bios boot ordering to get it to show /dev/sdb MBR.
Comment 8 John Watzke 2010-09-19 23:12:14 EDT
Okay, it was my mistake that the change happened between RC1 and RC2.  The change actually happened between the original Alpha and RC2.

I have an ATI card so I had to do the basic video driver install for Alpha.  There was a screen that appeared during the install that asked me to select the disk where the bootloader would live.  I've attached that as "F14 Alpha Boot Loader Select".  After that, I've attached the screenshot showing that the bootloader will be set to /dev/sdb and the bios order was switched correctly, "F14 Alpha Bios Order".

Next I installed using F14 RC2.  I tried both the default graphical and vesa install modes. In both instances I never saw a screen where I was asked which drive to install the bootloader.  Once I got to the screen showing the bootloader settings, it was set to /dev/sda and the bios order was set so /dev/sda was first.  See "F14 RC2 Bios Order".

I've asked around and people have said that when two drives are detected, that "Boot Loader Select" screen is shown to ask which drive to install the bootloader.  If that is true, then in RC2, it isn't seeing both of my drives when it makes the decision to show that screen but there are certainly two drives on my system in the partitioning screen and booloader settings screen.
Comment 9 John Watzke 2010-09-19 23:20:44 EDT
Created attachment 448332 [details]
F14 Alpha Boot Loader Select
Comment 10 John Watzke 2010-09-19 23:22:18 EDT
Created attachment 448333 [details]
F14 Alpha Bios Order
Comment 11 John Watzke 2010-09-19 23:22:54 EDT
Created attachment 448334 [details]
F14 RC2 Bios Order
Comment 12 James Laska 2010-09-20 12:54:26 EDT
Renaming this bug for the specific issue about the installer disk selection screen not appearing.  Any bios drive order changes can be filed as a different issue.
Comment 13 James Laska 2010-09-20 13:37:06 EDT
I have retested this on a virt guest with 2 disks (vda and vdb).  Test results are listed below.  To summarize, I'm not able to find any serious problems where an installer screen is not presented to the user.

= PASS - Replace Existing linux system(s) =
 1) Choose "Basic Storage Devices", click next
 2) Choose Fresh installation (do not upgrade existing install), click next
 3) Enter a hostname, timezone and rootpw, click next
 4) Choose default "Replace Existing Linux System(s)", click next
 5) I get to choose which disks to install to, and where to install bootloader ... expected behavior

= PASS - Use All Space =
 1) Choose "Basic Storage Devices", click next
 2) Choose Fresh installation (do not upgrade existing install), click next
 3) Enter a hostname, timezone and rootpw, click next
 4) Choose default "Use All Space", click next
 5) I get to choose which disks to install to, and where to install bootloader ... expected behavior

= PASS - Use Free Space =
 1) Choose "Basic Storage Devices", click next
 2) Choose Fresh installation (do not upgrade existing install), click next
 3) Enter a hostname, timezone and rootpw, click next
 4) Choose default "Use Free Space", click next
 5) I get to choose which disks to install to, and where to install bootloader ... expected behavior

= PASS - Create Custom Layout =
 1) Choose "Basic Storage Devices", click next
 2) Choose Fresh installation (do not upgrade existing install), click next
 3) Enter a hostname, timezone and rootpw, click next
 4) Choose default "Create Custom Layout", click next
 5) I am taken to the partition screen where I can create/update/delete partitions on all disks.  I understand that this is expected when selecting 'Create Custom Layout'
 6) After format, at the bootloader step, I can choose where to install the bootloader (MBR or partition), and which device (vda, vdb)

= FAIL - Create Custom Layout, Back, Use All Space = 
 1) Choose "Basic Storage Devices", click next
 2) Choose Fresh installation (do not upgrade existing install), click next
 3) Enter a hostname, timezone and rootpw, click next
 4) Choose default "Create Custom Layout", click next
 5) I am taken to the partition screen where I can create/update/delete partitions on all disks.  click 'back' to return to the previous screen
 6) Choose default "Use All Space", click next
 7) I am prompted for confirmation of partitioning (NOTE, if I selected to 'review partitioning' I am taken to the partition detail screen instead

I think this might be an error in the next/back/next workflow.  Based on my testing, the last scenario tested is worthy of a bug report.  I'm not yet clear whether that scenario matches the issue reported here.
Comment 14 James Laska 2010-09-20 13:45:49 EDT
(In reply to comment #13)
> = PASS - Create Custom Layout =
>  1) Choose "Basic Storage Devices", click next
>  2) Choose Fresh installation (do not upgrade existing install), click next
>  3) Enter a hostname, timezone and rootpw, click next
>  4) Choose default "Create Custom Layout", click next
>  5) I am taken to the partition screen where I can create/update/delete
> partitions on all disks.  I understand that this is expected when selecting
> 'Create Custom Layout'
>  6) After format, at the bootloader step, I can choose where to install the
> bootloader (MBR or partition), and which device (vda, vdb)

While retesting The above scenario against F-14-Alpha, the behavior has changed between F-14-Alpha and F-14-Beta.  In F-14-Alpha, I am presented with the screen to select "Install Target Devices" no matter what partition option I choose (Custom, Use all space, free space etc...)

So the behavior has changed, but I don't know if that's good or bad
Comment 15 James Laska 2010-09-20 14:01:53 EDT
(In reply to comment #14)
> So the behavior has changed, but I don't know if that's good or bad

The behavior change is intentional, see bug#620647.

The issue that remains with this bug is when it doesn't show the Target Device selection dialog in the following workflow ...

 1) selecting Custom and click Next
 2) click Back
 3) select Use All Space and click Next
Comment 16 David Lehman 2010-09-20 14:06:07 EDT
I think this patch will do the trick:

diff --git a/pyanaconda/iw/autopart_type.py b/pyanaconda/iw/autopart_type.py
index 121f1da..fee55ba 100644
--- a/pyanaconda/iw/autopart_type.py
+++ b/pyanaconda/iw/autopart_type.py
@@ -175,6 +175,7 @@ class PartitionTypeWindow(InstallWindow):
                 self.storage.clearPartType = CLEARPART_TYPE_NONE
 
             self.dispatch.skipStep("autopartitionexecute", skip = 0)
+            self.dispatch.skipStep("cleardiskssel", skip = 0)
 
             if self.encryptButton.get_active():
                 self.storage.encryptedAutoPart = True
Comment 17 Adam Williamson 2010-09-20 17:02:30 EDT
Not sure if this is a blocker but I'd certainly say it's nice-to-have, so please go ahead and include it in the next anaconda build for the Beta.
Comment 18 Fedora Update System 2010-09-20 19:31:50 EDT
anaconda-14.17.4-1.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/anaconda-14.17.4-1.fc14
Comment 19 Fedora Update System 2010-09-20 23:50:50 EDT
anaconda-14.17.4-1.fc14 has been pushed to the Fedora 14 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update anaconda'.  You can provide feedback for this update here: https://admin.fedoraproject.org/updates/anaconda-14.17.4-1.fc14
Comment 20 Fedora Update System 2010-09-22 00:07:13 EDT
anaconda-14.17.4-1.fc14 has been pushed to the Fedora 14 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 21 Fedora Update System 2010-10-06 18:02:36 EDT
anaconda-14.18-1.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/anaconda-14.18-1.fc14

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