Description of problem: When installing Fedora 16 Beta TC2, the only places allowed to install the boot loader were /dev/sdb and /dev/sda1. The desired target, /dev/sda, wasn't an option. Version-Release number of selected component (if applicable): How reproducible: Observed once, but only attempted once. Steps to Reproduce: 1. Write Fedora 16 Beta TC2 (Desktop) Live to a USB flash drive using UNetbootin. 2. Boot F16 and begin installation, and successfully complete all prompts to install F16 to /dev/sda until the install boot loader prompt is reached. (A custom partition layout was successfully used.) 3. Observe the locations the boot loader can be installed to. Actual results: The boot loader was installed to /dev/sdb, the USB flash drive the live image was on. Expected results: The boot loader would be installed to /dev/sda, the location F16 was installed to. Additional info: Partition layout /dev/sda Size Dir FS Format 512 /boot btrfs Yes 16384 / ext4 Yes 8192 /home btrfs Yes 4096 swap swap Yes /dev/sdb Size Dir FS 998 EFI System Partition No
Can you attach /tmp/storage.log, /tmp/anaconda.log, and /tmp/program.log to this bug report? If so, please attach them individually as text/plain. Thanks.
Created attachment 530869 [details] storage.log I'm having the same problem trying to upgrade from F15 to F16 RC2. I'm using the net installer iso on a USB flash drive. I had the choice of skipping the bootloader or creating a new one, no updating. I assume this is because of the change to GRUB2. When I get to the point of actually installing the bootloader, the drives are switched as they have always been, so that the flash drive is primary and the bootloader will go to /dev/sdb. However, I have always been able to switch the drive order and the bootloader then switches to default to /dev/sda. But now it doesn't change. I still only have the choice of /dev/sdb or /dev/sda1. I will attach the requested log files, but they may not be complete as I didn't actually finish the install because of this issue. I found these lines in the storage.log: 16:22:46,451 DEBUG storage: _gpt_disk_has_bios_boot(sda) returning True 16:22:46,451 DEBUG storage: is_valid_stage1_device(sda) returning True I wonder if anaconda just isn't updating the settings any more when the drives are re-ordered.
Created attachment 530871 [details] anaconda.log
Created attachment 530873 [details] program.log
Dupe of 744088, essentially. Writing live images with unetbootin isn't supported, note. I think, however, the fixed filtering code in final should also prevent anaconda from considering a unetbootin-written live stick as a bootloader target at all. so this should be fixed two ways. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers *** This bug has been marked as a duplicate of bug 744088 ***
I may be misunderstanding your comment. What I'm doing is taking the net install iso image and using livecd-iso-to-disk to put it on a USB flash drive. I then tried to do an upgrade using that. Is this method not supported or are you saying I should now have an option to pick the right drive?
writing the images with unetbootin is not supported, as it's a third party tool we have no control over and frequently does the wrong thing. the recommended tool is livecd-iso-to-disk . but the issue ought to be fixed in final, if you test it. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
what i'd expect to happen in final is for the usb stick to be filtered out, so it should give you the hard disk as the only available bootloader location.
I tested with RC4 and I get the exact same results as before. It will only give me /dev/sdb.
hum, that's a shame. can you please attach the logs from the installation? -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
okay, so it looks like upgrades are still suffering from the 'usb install stick looks like a valid bootloader target' bug. :( closing as dupe of a similar report. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers *** This bug has been marked as a duplicate of bug 750469 ***