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).
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.
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.
Created attachment 448303 [details] Anaconda logs from install
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.
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.
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
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.
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.
Created attachment 448332 [details] F14 Alpha Boot Loader Select
Created attachment 448333 [details] F14 Alpha Bios Order
Created attachment 448334 [details] F14 RC2 Bios Order
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.
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.
(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
(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
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
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.
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
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
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.
anaconda-14.18-1.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/anaconda-14.18-1.fc14