install guide notes: bootloader

[Adam Williamson]

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.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

[Jack Reed]

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. 
-- 
Jack Reed
Content Author
Engineering Content Services

Red Hat Asia Pacific
Brisbane, Australia
Phone: [phone]

[Chris Murphy]

On Dec 2, 2012, at 11:52 PM, Jack Reed <jreed(a)redhat.com&gt; 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

[Adam Williamson]

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
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net