Bug 860430 (ana-newui-bootloader)

Marking as an 18 Beta blocker, on general principles for now, but I'll try and provide more specific grounds later: experience from F16 indicates there's all sorts of nasty cases that rear their heads when we don't offer at least a choice of which disk the bootloader should be installed on. The argument for installing to /boot is more extra credit stuff and I'm not proposing that bit should block Beta, this is more for 1).

Discussed at 2012-09-26 blocker review meeting: http://meetbot.fedoraproject.org/fedora-qa/2012-09-26/f18-beta-blocker-review-1.2012-09-26-16.03.log.txt . Agreed to delay decision on this one as I didn't yet come up with a clear proposal.

1. Disks in the Selected Disks window, by default, are not highlighted blue. If the user clicks one, it's highlighted. The meaning of this highlighting is obscure, and is made more confusing when there are two selection indication behaviors: highlighting, and radio button. 

2. Using highlighting to choose the location of the bootloader, with a mouseover explaining this would be nice. I should also be allowed to shift or control click on a highlighted disk to deselect it indicating no bootloader installation.

3. Radio button UI implies I must have a bootloader installed. Is it valid for the user to intentionally (but not by default) create a potentially unbootable system? The handful who don't want their MBR clobbered might prefer this.

chris: we considered 3 but we don't really want to expose it. people who don't really want a bootloader can just use the argument described in 2) in mo's description, we figured. we could have a separate parameter for 'no bootloader at all', but we couldn't really think of a case where having a bootloader installed to the /boot partition would be a problem.

Well I'm confused because /boot defaults to ext4 and grub2-install rejects embedding core.img on ext[234] formatted partitions saying it doesn't support embedding. Same for xfs. I think the least risky option is embed to MBR gap, or GPT BIOS Boot, or no embedding at all.

Created attachment 618203 [details]
Updated mockup for boot device selection

Hi Chris,

Re: your #1 in comment 3, you make a really good point. I've modified the mockup to help address the selection confusion; would you mind taking a look and letting me know what you think? (attachment 618203 [details])

Re: #2, using highlighting to display the bootloader will not work because highlighting to show the currently selected disk to take action on. Before in the initial mockup there was just a remove button you could use to take action on the selected item, now there is a set as boot device button as well. 

Re: #3 I think Adam has addressed this appropriately, you can read more about the rationale here: http://blog.linuxgrrl.com/2012/09/25/anaconda-bootloader-reusing-home-assigning-partitions-to-disks/  But please let us know if we missed anything.

#1 I think that's fine. Because of #3 below, I think inevitably you're going to need a way to uncheck the boot device so that GRUB2 isn't stepping on other bootloaders.

#3 I've read the rationale and I've read Adam's explanation. The thing I think you're missing, is that GRUB2 is refusing to embed in any ext[234] partition, including /boot which by default is ext4.

Hi Chris, that sounds like a grub issue that should be fixed in grub, and not be band-aided by UI. Let's look into it from that angle?

grub2-install /dev/sdb2    {sdb2 is ext4}
/usr/sbin/grub2-bios-setup: warning: File system `ext2' doesn't support embedding.

What is there to fix? Does not seem to be a bug.

Users specifying partition embedding of grub in anaconda, since Fedora 16, have received bootloader install failure messages at the very end of system installation. This is not a new problem as far as I know, it's an inherent function of GRUB2.

The GRUB2 documentation and on the dev list has made it pretty clear to me that embedding in partitions is not recommended. Now maybe they've just made it that much more explicitly disallowed for certain filesystems that can't handle it, I'm not sure.

Chris, is that a warning or an actual error? Is it not actually doing the embedding, or is it doing it and just being bitchy about it?

Nothing is being embedded. When I search for this error message, I get many results implying it's a bug, attempts to fix, but it keeps resurfacing. One suggestion was to use --force to use blocklists (?) but in my case it's still not working. This is grub2-2.00-5.fc18.x86_64.

Test method was to create a new ext4 filesystem, hexdump -C /dev/sdb1 > output.bin, install grub with and without --force, creating additional hexdump files after each, then  using diff to compare. No differences.

(In reply to comment #9 through #13)
Filed Bug 861192.

Discussed at 2012-10-03 blocker review meeting: http://meetbot.fedoraproject.org/fedora-qa/2012-10-03/f18-beta-blocker-review-2.2012-10-03-16.00.log.txt . Again I didn't yet get time to go through the F16 archives and figure out what big problems we hit with lack of bootloader selection back then, so we agreed to delay evaluation again. The only known consequence at present (dual booting support) is Final stuff, not Beta.

Taking all the fun bugs today.

anaconda-18.14-1.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/anaconda-18.14-1.fc18

Package anaconda-18.14-1.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing anaconda-18.14-1.fc18'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-15707/anaconda-18.14-1.fc18
then log in and leave karma (feedback).

Discussed at 2012-10-10 blocker review meeting: http://meetbot.fedoraproject.org/fedora-qa/2012-10-10/f18beta-blocker-review-3.2012-10-10-16.05.log.txt . I still wasn't able to come up with solid rationale for Beta blocker status, so we agreed this is NTH for Beta and accepted blocker for Final, criterion "The installer must be able to install into free space alongside an existing clean single-partition Windows installation and either install a bootloader which can boot into the Windows installation, or leave the Windows bootloader untouched and working".

I can confirm there's an option to set this in the 'Full disk summary and options...' screen. It seems a bit funny to have that separated out from the disk picker screen, not like it's short on real estate and a bit hard to find, but that's just UI quibbling, the feature is present. Was implemented in 18.14 which went stable a long time ago, so closing.

We talked about the ability to set it in the disk picker screen too, Adam, by right-clicking on the disks in the picker.