Hey, folks (Jack especially). I have it on my (very long) todo list to look through the changes to the installation guide and see if I can contribute anything, but we were talking about this in #anaconda this morning and I thought I'd outline it for the install guide before I forget the plan again. Handling of bootloader install is somewhat different in newUI. This is all about BIOS - UEFI is completely different.
So what newUI is capable of is either installing the bootloader to a partition MBR, or not installing the bootloader at all. Currently there is no option to install bootloader to a partition, which was possible in oldUI. Installing the bootloader to a partition is done only by those who multiboot various OSes using a 'chainload' system - they have a bootloader in the MBR which 'chainloads' bootloaders for each of their OSes, each of which resides in the / or /boot partition for that OS.
The plan is for those who have such setups to just not install a bootloader at all, and then do their bootloader configuration manually post-install. Anyone who for some reason doesn't want a bootloader installed to an MBR gets to do their own configuration.
In the UI you are able to specify which disk the bootloader should be installed to (or that it shouldn't be installed at all). You do this on the 'disk selection' screen - the first screen you see after clicking on the 'Installation Destination' spoke. You have to click on 'Full disk summary and options...' and you get a dialog that lets you pick the target disk for the bootloader. To set it to not install a bootloader at all, right now, this is the procedure:
"highlight whatever disk has the bootloader check, click the button, and it'll unset that device for receiving the bootloader. Thus, you should not get a bootloader installed."
clumens notes that this isn't the best UI, but changing it would break string freeze. See https://bugzilla.redhat.com/show_bug.cgi?id=867469 for details.
If you do not select a target disk, anaconda will default to installing the bootloader to the MBR of the first disk (of those selected as 'install target disks' on the picker screen) that appears to be a viable target, in enumeration order (so it'll try sda, then sdb, then sdc, and so on, and the first one which passes the 'bootloader target' tests gets the bootloader). This part is unchanged from F17.
Hope that's useful! Thanks.
Hi Adam,
Thanks very much for this. Your continued enthusiasm for keeping us informed in such clear detail is hugely appreciated. And your thoughts on the F18 draft of the Installation Guide when it eventuates will be extremely welcome if your schedule permits. :)
Incorporating these points into the Installation Guide won't be a problem. I'll clarify what bootloader options we now provide. How can we expect UEFI to differ though, and will this need to be documented?
Also, I tried to unset my drive for receiving a bootloader but had no luck. Maybe this is because I can only muster one drive in my VM and the button in the instructions you quoted isn't displayed in such a case. But if the button in question is the 'Set as Boot Device' button, then it's not working for me as it should. The tick that marks the drive as the boot device remains.
Let me know if that's bug-worthy. In the meantime, I'll document the rest.
Thanks again!
Jack
On 12/01/2012 08:19 AM, Adam Williamson wrote:
Hey, folks (Jack especially). I have it on my (very long) todo list to look through the changes to the installation guide and see if I can contribute anything, but we were talking about this in #anaconda this morning and I thought I'd outline it for the install guide before I forget the plan again. Handling of bootloader install is somewhat different in newUI. This is all about BIOS - UEFI is completely different.
So what newUI is capable of is either installing the bootloader to a partition MBR, or not installing the bootloader at all. Currently there is no option to install bootloader to a partition, which was possible in oldUI. Installing the bootloader to a partition is done only by those who multiboot various OSes using a 'chainload' system - they have a bootloader in the MBR which 'chainloads' bootloaders for each of their OSes, each of which resides in the / or /boot partition for that OS.
The plan is for those who have such setups to just not install a bootloader at all, and then do their bootloader configuration manually post-install. Anyone who for some reason doesn't want a bootloader installed to an MBR gets to do their own configuration.
In the UI you are able to specify which disk the bootloader should be installed to (or that it shouldn't be installed at all). You do this on the 'disk selection' screen - the first screen you see after clicking on the 'Installation Destination' spoke. You have to click on 'Full disk summary and options...' and you get a dialog that lets you pick the target disk for the bootloader. To set it to not install a bootloader at all, right now, this is the procedure:
"highlight whatever disk has the bootloader check, click the button, and it'll unset that device for receiving the bootloader. Thus, you should not get a bootloader installed."
clumens notes that this isn't the best UI, but changing it would break string freeze. See https://bugzilla.redhat.com/show_bug.cgi?id=867469 for details.
If you do not select a target disk, anaconda will default to installing the bootloader to the MBR of the first disk (of those selected as 'install target disks' on the picker screen) that appears to be a viable target, in enumeration order (so it'll try sda, then sdb, then sdc, and so on, and the first one which passes the 'bootloader target' tests gets the bootloader). This part is unchanged from F17.
Hope that's useful! Thanks.
On Dec 2, 2012, at 11:52 PM, Jack Reed jreed@redhat.com wrote:
How can we expect UEFI to differ though, and will this need to be documented?
The main thing I'm aware of is GRUB Legacy is dropped in favor of GRUB 2. So the references to GRUB Legacy examples and limitations can be dropped.
The command to install GRUB 2 differs between BIOS and UEFI: UEFI destination must be specified, whereas there is a default/assumed location for BIOS.
Also, I tried to unset my drive for receiving a bootloader but had no luck. Maybe this is because I can only muster one drive in my VM and the button in the instructions you quoted isn't displayed in such a case. But if the button in question is the 'Set as Boot Device' button, then it's not working for me as it should. The tick that marks the drive as the boot device remains.
This appears to be a bug in -29. It worked for me in -32 and is still working for me in -34. However I'm finding a small UI bug where once I deselect it, I can't reselect it until I close the modal dialog and then reenter by clicking on Full disk summary and options.
On 12/01/2012 08:19 AM, Adam Williamson wrote:
Currently there is no option to install bootloader to a partition, which was possible in oldUI. Installing the bootloader to a partition is done only by those who multiboot various OSes using a 'chainload' system - they have a bootloader in the MBR which 'chainloads' bootloaders for each of their OSes, each of which resides in the / or /boot partition for that OS.
Documentation could state this change in anaconda's behavior, and what's needed to work around this…
The plan is for those who have such setups to just not install a bootloader at all, and then do their bootloader configuration manually post-install. Anyone who for some reason doesn't want a bootloader installed to an MBR gets to do their own configuration.
Documentation could state step by step:
- How to choose to not install GRUB at system install time in anaconda. - Before rebooting after successful install, chroot the newly installed system. - Use grub2-install --force and specify disk+partition. - Optionally use grub2-mkconfig so there's a base grub.cfg that should just work.
I have a rough step by step in my head, to make it easy for a user to do this, including identifying the correct disk+partition to install GRUB into.
There is a difference for the command to install to a partition depending on file system: ext4 needs the --force flag; whereas btrfs does not (and cannot as block lists are proscribed on btrfs and merely "not recommended" on ext4).
Chris Murphy
On Mon, 2012-12-03 at 16:52 +1000, Jack Reed wrote:
Incorporating these points into the Installation Guide won't be a problem. I'll clarify what bootloader options we now provide. How can we expect UEFI to differ though, and will this need to be documented?
This is almost an essay in itself! I don't know what you have in the install guide about UEFI already, but bootloading with UEFI is just entirely different to bootloading with BIOS.
So with UEFI there's this concept called the 'EFI boot manager': a useful way of thinking about it is that there's a boot loader in the firmware itself. The 10,000ft overview of how it's supposed to work is pretty simple: as an OS, you should install a bootloader that only loads yourself (to a standardized location in something called the 'EFI system partition'), and then add an entry to the EFI boot manager which is called 'Fedora 18' or 'Windows 8' or 'Bob's Raptoriffic Linux' or whatever your OS happens to be called, which points to your own bootloader.
No OS gets to 'control' bootloading for everyone, there's none of this chainloading malarkey or different bootloaders on different disks' MBRs and partition headers and BIOS drive boot orders and who knows what else: there's just supposed to be one list of 'things that can be booted', which lives in the firmware, and each OS is only supposed to fiddle with its own entry in that list and with the bootloader that loads itself and only itself.
Of course it can get a bit messier in practice; in practice all the messy stuff about BIOS booting - chainloading, and bootloaders associated with one OS also being capable of booting other OSes - is still actually possible and some bugger somewhere has probably come up with some reason to do them, and you also have the case of hybrid systems to consider - most UEFI firmwares shipped today have a 'BIOS compatibility mode', whereby they can boot from a disk MBR and look to the booted system very much like a BIOS would do. So a typical EFI boot manager on a current system has entries for any UEFI-native OS installs, *and* entries for each hard disk, which result in BIOS compatibility boot from that disk. (There are other ways of representing BIOS compatibility mode, but this is one of the most popular). It is, not surprisingly, a bit confusing. Sigh, computers.
Still, the overview is worth keeping in mind. What Fedora 18 actually *does* when installed as a native UEFI OS is to install the shim and grub2-efi bootloaders to the EFI system partition (I have heard a report that it doesn't actually detect an existing EFI system partition if there is one but just creates a new one, which would be a bug, but I'm not 100% sure of that) and add an entry named 'Fedora' to the EFI boot manager, pointing to shim: shim in turn loads grub2-efi, which loads Fedora. shim is our Secure Boot solution, which really *is* an essay in itself, I can pass you that essay if your head isn't spinning yet.
Fedora 17, for comparison, installed grub-efi to the ESP and wrote an entry to the EFI boot manager called 'Fedora', which loaded grub-efi, which loaded Fedora. shim is just an extra step in essentially the same chain, and we switched from grub-efi in F17 to grub2-efi in F18.
If you're paying attention you may notice a shortcoming of this design, which is that it doesn't allow for multiple native UEFI Fedora installs to a single system, and you'd be correct. If you have a native UEFI Fedora install already, and you do a new one, it just overwrites the EFI boot manager entry associated with the existing install. You won't be able to get into the existing install any more without some manual poking of the EFI boot manager (or configuring grub2-efi to allow access to the existing install as well, which I suppose might work, though I don't know if it really ties in with the 'intended' use of the EFI boot manager). I filed a bug on this a while back - https://bugzilla.redhat.com/show_bug.cgi?id=759303 - which was closed as 'wontfix' back in July, though I rather hope that may change at some point, as it seems a shame.
This is all, of course, just the incomplete and probably often incorrect understanding of the idiot monkey, I am not a lawyer, errors and omissions excepted, final sale, no refunds, does not constitute medical advice or professional investment advice, and I strongly and heartily recommend that you get a second opinion from someone who knows what the hell he's talking about - pjones and/or mjg59, for preference - before accepting any of this as actually bearing the slightest resemblance to the truth. Seriously, some of the above I know to be a simplification, and some of it is probably also simplified without me knowing about it, by the poor sods who have to try and educate me.
-
Adam Williamson -
Chris Murphy -
Jack Reed