As I understand the above description, if /boot is on a partition other than the MBR partition, then the current version of anaconda will not honor installing to the /boot partition.  If this is so, then this is a serious shortcoming for any of us who dual or multiboot.

So I was *sure* we had a bug for this already, but I can't find one. We have discussed it though, at length (I have the IRC logs if you like, but they're painful). IIRC, the general agreement was that we would make this possible through a command line parameter rather than the UI, as it's only necessary for people who manage their own multiboot chainloading configurations and we don't want to have the problem where people who don't really understand pick the 'install to /boot partition' option by mistake and wind up with non-bootable installs.

I am not sure if this has actually been implemented yet, though, and as I can't find the other bug, let's track it here for now. Brian, David - did we actually implement the parameter for this yet, or is it still on someone's todo list?

clyde: it's simpler than that, there just isn't a UI option to install to a partition instead of the MBR any more.

Bug 861192 is the conversation I think you recall, Adam.

I'm still not clear if a chrooted system on another drive constitutes cross-installation. If it does, grub-install --force isn't going to work, even if permitted.

FWIW, ext4 (and XFS) lack a region for embedding grub's core image. grub-install --force will break it up using block lists, so it's inherently fragile. If you don't want GRUB in the MBR gap, use a different bootloader and bootmanager.

(In reply to comment #4)
> Bug 861192 is the conversation I think you recall, Adam.
> 
> FWIW, ext4 (and XFS) lack a region for embedding grub's core image.
> grub-install --force will break it up using block lists, so it's inherently
> fragile. If you don't want GRUB in the MBR gap, use a different bootloader
> and bootmanager.

Fragile yes, but it works.  Used it for F16 and F17.  Keeping a legacy grub mbr also works for multibooting windows and grub2 installations.

I now recall something about the cmd line parm.  Hope it gets in soonish if not already.

"Bug 861192 is the conversation I think you recall, Adam." It was related to it, but most of the discussion happened on IRC.

Any chance of this being NTH for Final?

(Installing in the Fedora partition is what I have done for years too.)

well sure, bit early for that though.

See also:
Bug 868664 - DVD installl owerrites MBR on disk not install selection

So I asked in #anaconda today when this was going to be implemented, and was given the impression by mjg59 and pjones that they believe chainloading is fundamentally broken and should not be supported in the installer, therefore they do not want to implement this.

Anaconda team, could you please clarify your intentions in this case, and either address the bug or close it as wontfix? Thank you.

OK, so update:

It is now possible (at least on master, this may not be in Beta) to not install a bootloader at all through the UI. See https://bugzilla.redhat.com/show_bug.cgi?id=867469 .

The general consensus is that we don't really want to offer an option to do the install to a partition header, as upstream grub considers it dangerous and unsupported, and even if we do that part for those who have chainload multiboot setups, they still have to edit the master bootloader config manually before they can boot Fedora.

So the current plan is that if you want to use a chainload setup, you install F18 with no bootloader, and then install a bootloader to the / or /boot partition yourself, manually, after install. We're assuming those who chainload are capable of that.

Is this OK for you chainloaders, or would you still strongly prefer to have an option to have anaconda do the bootloader install for you?

If this plan seems OK, we can close this bug as a dupe of 867469.

"they still have to edit the master bootloader config manually before they can boot Fedora." - not if this was used previously...

It's imho not the most user-friendly solution but with 867469 beeing fixed it's
actually possible to do chainloading with f18. So yes I for my part am ok with this.

I guess I'll have to read some documentation now and finally learn to how to do
grub2 manual setups...lilo-style bootloaders were soo easy to understand.

I think you really just have to chroot into the installed Fedora system and run 'grub2-install --force /dev/sda1' or whatever the /dev name is. You could actually do this from ctrl-alt-f2 before you reboot from the installer, if you remember. That's just from memory, though, I don't chain boot.

(In reply to comment #13)
> I think you really just have to chroot into the installed Fedora system and
> run 'grub2-install --force /dev/sda1' or whatever the /dev name is. You
> could actually do this from ctrl-alt-f2 before you reboot from the
> installer, if you remember. That's just from memory, though, I don't chain
> boot.

Correct.  Works nicely.  You can also setup multibooting to another grub2 installation by setting root to that boot parition and then configfile=/grub2/grub.cfg.

*** Bug 882513 has been marked as a duplicate of this bug. ***

(In reply to comment #13)
> I think you really just have to chroot into the installed Fedora system and
> run 'grub2-install --force /dev/sda1' or whatever the /dev name is. You
> could actually do this from ctrl-alt-f2 before you reboot from the
> installer, if you remember. That's just from memory, though, I don't chain
> boot.

OK, thanks for your hints. I feared I have to do the configuration myself but according to your comments it's just the installation of the bootloader.

(In reply to comment #14)
> Correct.  Works nicely.  You can also setup multibooting to another grub2
> installation by setting root to that boot parition and then
> configfile=/grub2/grub.cfg.

oh..so maybe I don't even have to use chaninloading at all. Nice

(In reply to comment #13)
> I think you really just have to chroot into the installed Fedora system and
> run 'grub2-install --force /dev/sda1' or whatever the /dev name is. You
> could actually do this from ctrl-alt-f2 before you reboot from the
> installer, if you remember. That's just from memory, though, I don't chain
> boot.

That was exactly me solution to. But sounds really scary for a not so much experienced user. Anaconda should offer this options.

The bootloader options are not easy to find in Anaconda to:
Even for an experienced Fedora admin not guessable texts like "1 storage device selected" are really worse! Even Gnome does not hide it's options in such a puzzling kind. The bootloader options should really be called "bootloader-settings" and not "1 storage device selected" or "selected disks".

Anaconda should not offer options that are expressly stated as not recommended by upstream. The problem is ext4's boot sector is only 512 bytes, which is not enough space. The use of --force fragments GRUB, and installs the pieces into free space without informing the file system. At any future time the file system can step on any one of those block lists and render the system unbootable.

Btrfs on the other hand, has a 64KB gap at the start. grub-install will happily install GRUB diskboot+core into this region without complaints, and without using block lists. So it seems if there is really a need for boot loaders being installed into partitions, that the file system really needs to support it with a sufficiently large reserve area. And the fact of the matter is, ext4 (and XFS) do not support this. It's not a flaw with GRUB or anaconda.

Whatever the outcome of this discussion might be, it should be made very clear to the user that the bootloader will be installed in the mbr, and that the other option would be to NOT install it at all and do it manually. I think this will be a bad surprise to a lot of users having parallel linux setups.

I for one would still prefer the automated bootloader install through Anaconda, though maybe in a 'subscreen' with the proper warnings. (Someone suggested a per screen 'Advanced settings' button)

I still use ext2 boot partitions; if I understand it correctly, the partition header problem does not apply?

tapani: 'not so experienced users' will not have chainloading multiboot configurations.

Another bugzilla entry dealing with GRUB2 inside a partition is bug 804835. From there you can see, that there are two ways of chainloading from the primary GRUB:

1. using "chainloader +1"

This is fragile, because it relies on block lists. The above discussion focuses on this.

2. using "kernel /boot/grub2/core.img"

This is not fragile, because it directly reads the file system and even does not need the boot block program.

Conclusion: Using GRUB2 in a partition is not fragile (just use "kernel" instead of "chainloader"). What is fragile is "chainloader".

Proposal: Please allow installation of GRUB2 into a partition (by using --force) as it is not fragile. If you are concerned about fragility, then tell the user to use "kernel" instead of "chainloader".

Over the weekend, I installed a new disk set up for multiboot, and the directions that I read in 'info grub2 Configuration' under the 'Multi-boot manual config' chapter from F18 were very informative:

   First create a separate GRUB partition, big enough to hold GRUB.
Some of the following entries show how to load OS installer images from
this same partition, for that you obviously need to make the partition
large enough to hold those images as well.  Mount this partition
on/mnt/boot and disable GRUB in all OSes and manually install
self-compiled latest GRUB with:

   `grub2-install --boot-directory=/mnt/boot /dev/sda'

   In all the OSes install GRUB tools but disable installing GRUB in
bootsector, so you'll have menu.lst and grub.cfg available for use.
Also disable os-prober use by setting:

   `GRUB_DISABLE_OS_PROBER=true'

   in /etc/default/grub

   Then write a grub.cfg (/mnt/boot/grub2/grub.cfg):

     menuentry "OS using grub2" {
        insmod xfs
        search --set=root --label OS1 --hint hd0,msdos8
        configfile /boot/grub2/grub.cfg
     }

As long as the the initial grub menu uses 'configfile' to route to the grub.cfg of each subsequent OS grub menu, rather than 'chainloader', then things worked great.  All that remains is to ensure that the initial install of a chained OS still sets up its grub.cfg in a manner the that first grub.cfg can find the chained configfile, without installing grub to the MBR.

ah, that's interesting. So not installing a bootloader at all is actually what upstream recommends us to do for those who want to set up a chainload-like multiboot config, though this is certainly more by luck than by judgement...:)

There is a small difference between comment 23 and 24:

"configfile" means, that the primary grub reloads its configuration from the given configfile. But still it is the same version. It does not load a secondary grub. It has the same set of modules with the same capabilities.

"kernel /boot/grub2/core.img" will load the second GRUB instead of the primary. This will load all modules and functionality from this second grub.

I would recommand "kernel", because otherwise you will not gain any new modules, which might be necessary to boot your new fedora from the partition. 

In any case, there must be the GRUB2 rpm package installed on the partition and setup to be present in /boot/grub2 (modules and config files). However, it must not be installed into the boot sector of the partition or embedded into a hole or used with a block list.

What I _don't_ know is whether anaconda will _still_ create a useful grub.cfg even when told to not install grub anywhere (and that's because I was unable to get F18 installed at all over the weekend; just F17, where the installer still let me force grub into the /boot partition - but my F18 installation woes are the subject for another bug).  Maybe this bug needs to be about ensuring that anaconda has a way to set up /boot/grub2/grub.cfg even when GRUB is not installed to the MBR, so that the pre-existing grub in the MBR can then 'configfile' into the just-installed F18's grub.cfg, and preserve my ideal setup where each of my multiboot OS see their own configuration file without trying to probe all other partitions.  It would also be nice to have a selection at anaconda time whether installation of grub.cfg should default to using GRUB_DISABLE_OS_PROBER, instead of me having to add it after the fact and regenerate my grub.cfg.

(In reply to comment #22)
> Proposal: Please allow installation of GRUB2 into a partition (by using
> --force) as it is not fragile. 

--force compels GRUB to break up core.img using block lists. That is fragile. Using kernel /boot/grub2/core.img presumes that a different core.img is already loaded to have the ability to run that kernel command to load a different non-block listed GRUB core.img.

If you mean a way to create a core.img within e.g. /boot/grub2/ but not install it into any boot loader code regions (MBR or partition boot sector) then there's a different command to make a core.img only and that could be useful. But it assumes you have some other boot loader already installed capable of finding and loading that core.img.

(In reply to comment #21)
> tapani: 'not so experienced users' will not have chainloading multiboot
> configurations.

May you got me wrong. To be a Linux-newbees, don't means to know nothing about chainloaders. Multi-boot is not unusual for Linux-newbees.

> So the current plan is that if you want to use a chainload setup, you install 
> F18 with no bootloader, and then install a bootloader to the / or /boot 
> partition yourself, manually, after install. We're assuming those who 
> chainload are capable of that.

Of coarse, I can dot that easily. But may user will just stop using Fedora, if such basic things don't work out of the box. Not everybody know RedHat and Feodra for years like me.

--force or not... The funtionalety is missing and the one or tow OS will may not be bootable.

eric: I'll check that, it's a reasonable question. I think we ought to write a config even if we don't install the loader, but I'll check if we currently do.

Created attachment 658111 [details]
anaconda program.log

Anaconda-18.34 and .35 still install grub2 to the MBR and MBR gap, even when the destination disk has the green checkbox for Boot deselected.

anaconda.program.log (attached) reveals the call to grub2-install, and grub2-mkconfig are still being made with bootloader installation deselected.

Chris: can you file a new bug? The bug is no longer that there's no option (there is), but that the option plain doesn't work...

(In reply to comment #31)
Bug 885240.

See also bug 886502 for steps on how to create grub.cfg even when not installing into the MBR or partition gap (it would be nice if anaconda can do that part automatically, but even knowing what the steps are will make it easier for those doing it by hand if anaconda does not get it done in time).

On the basis of previous comments indicating that grub2 no longer recommends this setup, I'm closing this as WONTFIX.  We have other bug reports dealing with the last several comments in this report.

*** Bug 889724 has been marked as a duplicate of this bug. ***

Suggest this bug be added to Release Notes, with proposed title and text:

TITLE
There is no longer an option to install boot loader (GRUB) to a partition.

BODY
Embedding GRUB to a partition contain an ext[234] file system is not recommended by upstream GRUB development, and in Fedora 18 is no longer an option. Suggested alternatives: 1. Allow Fedora 18 to install GRUB2, to become your primary boot manager/loader (default). 

If you don't want your primary boot manager replaced, in anaconda you need to deselect boot loader installation from the Installation Destination > Click on Full disk summary and options to reveal the Selected Disks dialog. Select disks and click "Do not install bootloader". Your system will not be bootable without additional post-install configuration. It's suggested you do this after installation has successfully finished, but before you reboot.

2. Create GRUB2 core.img, suppress embedding in the MBR, produce grub.cfg.
-Confirm the whole /dev/sdX device Fedora 18 is installed on.
mount | grep sysimage
chroot /mnt/sysimage
-Install GRUB, using whole /dev/sdX device from previous step, not including partition number.
grub2-install --grub-setup=/bin/true /dev/sdX
grub2-mkconfig -o /boot/grub2/grub.cfg

3. If you already have a GRUB2 instance, you can now add a menu entry to that distribution's grub.cfg, using 'configfile' to load the Fedora 18 grub.cfg created in step 2 above.

If you use a boot manager other than GRUB2, including GRUB Legacy, you can have it find and execute /boot/grub2/i-386-pc/core.img for example a GRUB Legacy entry with Fedora 18 /boot found on the 3rd partition:

title   Load GRUB2, Fedora 18
root    (hd0,2)
kernel  /boot/grub/i386-pc/core.img

I have tested this whole sequence (in VM).

This is not a release blocker.

(In reply to comment #36)
> BODY
> Embedding GRUB to a partition contain an ext[234] file system is not
> recommended by upstream GRUB development, and in Fedora 18 is no longer an
> option. Suggested alternatives: 1. Allow Fedora 18 to install GRUB2, to
> become your primary boot manager/loader (default). 

Provide link to upstream GRUB documentation.

> 3. If you already have a GRUB2 instance, you can now add a menu entry to
> that distribution's grub.cfg, using 'configfile' to load the Fedora 18
> grub.cfg created in step 2 above.
> 
> If you use a boot manager other than GRUB2, including GRUB Legacy, you can
> have it find and execute /boot/grub2/i-386-pc/core.img for example a GRUB
> Legacy entry with Fedora 18 /boot found on the 3rd partition:
> 
> title   Load GRUB2, Fedora 18
> root    (hd0,2)
> kernel  /boot/grub/i386-pc/core.img
> 
If f18 is installed to hole disk using default options 
then 
kernel  /boot/grub/i386-pc/core.img
does not work
but 
kernel  /grub/i386-pc/core.img

Additional 
to regenerrate old boot options fore example fore F14 then
in F14
#grub-install --recheck /dev/sdx

(In reply to comment #38)

> If f18 is installed to hole disk using default options 
> then 
> kernel  /boot/grub/i386-pc/core.img
> does not work
> but 
> kernel  /grub/i386-pc/core.img
> 

I use in grub.conf in F14 to boot F18 on hole disk
title Fedora F18 RC3
	root (hd1,0)
	kernel /grub2/i386-pc/core.img
	boot

(In reply to comment #20)
> Whatever the outcome of this discussion might be, it should be made very
> clear to the user that the bootloader will be installed in the mbr, and that
> the other option would be to NOT install it at all and do it manually. I
> think this will be a bad surprise to a lot of users having parallel linux
> setups.
> 
> I for one would still prefer the automated bootloader install through
> Anaconda, though maybe in a 'subscreen' with the proper warnings. (Someone
> suggested a per screen 'Advanced settings' button)
> 
> I still use ext2 boot partitions; if I understand it correctly, the
> partition header problem does not apply?

EXACTLY!

The "bad surprise" just happened to me. :(

Me too! Is this like the bug that killed access to Windows partitions? Shame on you boys.

(In reply to comment #41)
> Me too! Is this like the bug that killed access to Windows partitions? Shame
> on you boys.

To be this condescending, you have to be wholly ignorant of the issue. Clearly you didn't bother to read the comments, to understand this bug.



(In reply to comment #20)
> I still use ext2 boot partitions; if I understand it correctly, the
> partition header problem does not apply?

Incorrect, the 1K boot loader limitation applies to ext[234]. XFS has no boot loader region. Btrfs has a 64KB boot loader region, so a future anaconda could actually legitimately stuff GRUB2's core.img on a partition containing a Btrfs volume.

Actual I did read the comments. You are going to disrupt all the user that don't have time to spend following the pre-release development. It does not matter what the issue is. Most users will have problems installing 18. Most of the boys at work dual boot. Most don't even know any shell scripting must less UEFI dual booting with grub2. I have already had two people come to me and ask for another distro. Both just did not have time to make it work. 

So what would you suggest I tell them. If I fix the install for them I'll have to do it for everyone.

(In reply to comment #43)
> Actual I did read the comments. You are going to disrupt all the user that
> don't have time to spend following the pre-release development.

You don't have time to test, but you have time to complain about the result.

> It does not
> matter what the issue is. Most users will have problems installing 18.

This is highly speculative. Considering how maybe a dozen people in prerelease testing wanted to install GRUB into a partition ran into this problem, it seems far fewer than "most users" need to do this.

> So what would you suggest I tell them. If I fix the install for them I'll
> have to do it for everyone.

To get the same behavior as before:
chroot /mnt/sysimage
grub2-install --force /dev/sdXY
grub2-mkconfig -o /boot/grub2/grub.cfg

Not difficult.

But as this bug describes, this is not recommended by GRUB upstream. Instead you should consider replacing the current boot manager/loader with the Fedora GRUB, which detects other OS's, and includes a GRUB menu item for booting them.

I give up. You don't understand and as you said I only "have time to complain".

(In reply to comment #45)
> I give up. You don't understand and as you said I only "have time to
> complain".

Oh you can dish it out but you can't take it? You should have given up the moment your brain indicated it was a good idea to chastise developers with "shame", before you hit Submit. Starting with such a snotty comment, with nothing value added for what behavior you do expect, is such a great way to start an argument. 

If you want to change that, present a coherent suggestion how developers can address the problem you're running into that does not involve breaking with upstream's express non-recommendation.

Have you even tried using Fedora's GRUB2 as a replacement for your existing boot manager/loader? If so, and it didn't work, where is the bug report? Because that is what needs to be improved, not more weird hacks like --force which stuffs boot loaders into file systems that aren't actually designed to accept them that way, and in a manner that the file system doesn't even know they're there. It's inherently fragile.

(In reply to comment #46) It's inherently fragile.

As a multi-system multibooter since long before the start of this century who:

1-limits Grub2 installation to *buntu root partitions
2-exclusively uses EXT[2,3,4] partitions for Linux distro installations and Linux data
3-uses only generic MBR code on all HDs

I often wonder when I see comments like this, what is required to expose the purported fragility of Grub installation to a partition.

Since Anaconda dropped the option to install Grub Legacy, I choose no bootloader, and boot Fedora from a non-Fedora Grub Legacy, which I may or may not install to the Fedora root, before or after installing Fedora. What I miss is kernel updates not updating a bootloader menu on the Fedora installation, since its preferred kernel cmdline options differ from those of other distros I use. 

It is from the above context that leaves me perplexed why upstream's dire warnings cannot be ignored and an install to partition option be provided.

I think my first copy was on 4 floppy's and cost $ 15 dollars from a company named ACC and was called Red had Linux. That was a media fee. Red Had Linux was free. But I degrees.

I am one of those 4 M + Fedora user that greatly appreciate the work that happens not only here but the hold Open Source Universe.  I did not mean to pull your string Chris. I have six users with UEFI boards of those six the only two that have tried to install F18 have bombed. That is a 100% err rate from my view. So relax I am on your side. I am downloading 18 now the see if the problem can be narrowed down. I had problems with the beta and just did not get back on the problem to help solve it. When I have something constructive I'll post.

See comment #13. There is all ready a workaround. It works without any problems. But it is just a workaround and no solution. Fedora should be bootable in a chainloader setup without the use of the rescuedisk.

To use MBR only makes a multi-distro setup very inflexible, since the gub2 setup of each distro is really different. With a chainloader setup, each distro can updaten its bootlader without any influence to any other installation. If it comes to Win how act like it would be alone on the computer, the most painless setup is usually a chainloader setup with BCD in the MBR.

To override MBR, reminds me at the bad habitats of systems from Redmond. Fedora should not act like it is the only true operating system. There are too many systems that all ready do that.

If installing a chainloader setup does break with upstream's recommendation, or not, does no matter. The fact is, a working functionality was removed and is missing now. May anaconda could offer a grub1 setup for users how like to install the boot loader in to a VBR... 

I can't see any reason, way it should be a problem or unsafe to install grub2 to a VBR. May the fedora developer could ask the grub2 developers to remove this advice. 

Pleas don't hide you behind a upstream project. Pleas don't use the grub2-preject in as an excuse. The fact is, a working functionality was removed and is missing now.

(In reply to comment #47)
> It is from the above context that leaves me perplexed why upstream's dire
> warnings cannot be ignored and an install to partition option be provided.

It's not a matter of can't, it's a matter of won't. There is no room on ext[234] to embed grub in a boot loader area, so block lists must be used to chain load the grub2 core.img. The file system is not notified of these block lists. At any time the file system can write to a sector compromising a block list and instantly render the system unbootable. It's quite easy to reproduce with smaller file system with less than a dozen writes. Subjecting many hapless users to such a "feature" is far worse than inconveniencing a handful of people who purportedly know so little about how this works that they can't use the --force flag to install grub the way they want themselves, and take the risk.

(In reply to comment #48)
This bug doesn't apply to UEFI. There's no such thing as installing a boot loader to a partition on UEFI computers. Each OS's boot loader has a prescribed location on the EFI System partition. The computer's firmware itself offers a built-in boot manager to choose which loader and thus which OS should be booted.

(In reply to comment #49)
> To use MBR only makes a multi-distro setup very inflexible, since the gub2
> setup of each distro is really different.

There are multiple ways to address this. It's possible to include in one distro's /etc/grub/default, the kernel command line for all other distros. grub-mkconfig calls os-prober, which can locate other distros, create entries for each one, while using the proper distro specific command line. Another way is for a primary grub.cfg include menu entries using the 'configfile' command to load the grub.cfg of other distros.

> With a chainloader setup, each
> distro can updaten its bootlader without any influence to any other
> installation.

Chainloading core.img is fragile. No one wants to maintain this. Not upstream devs. And not Fedora devs. Denying the fragility while repeating the request Fedora/Red Hat deves do things they simply don't believe in is a pointless conversation.

> If it comes to Win how act like it would be alone on the
> computer, the most painless setup is usually a chainloader setup with BCD in
> the MBR.

I've tested this scenario extensively. The most painless dual boot scenario for Windows + Fedora is for GRUB2 to replace the Windows boot loader which cannot boot Linux. By default, since Fedora 16, anaconda calls grub2-mkconfig which creates the proper grub menu entries too boot Fedora and Windows.

> To override MBR, reminds me at the bad habitats of systems from Redmond.

Nice. To get what you want, you're going to use slurs? Outstanding.
 
> If installing a chainloader setup does break with upstream's recommendation,
> or not, does no matter. The fact is, a working functionality was removed and
> is missing now.

This is a horrible logical fallacy that a bad idea from the past that has been determined to be no longer easily maintainable must not be removed, and for all time other people's bad habits must be coddled. I don't agree. If you want the old behavior, learn to install grub with the --force flag. Easy.

> Pleas don't hide you behind a upstream project. Pleas don't use the
> grub2-preject in as an excuse. The fact is, a working functionality was
> removed and is missing now.

No, what you're arguing for is "I do things this crazy way that has worked fine for me, and I want other people to spend their development time making sure I can keep doing this easily so that I don't have to learn how to do it myself, or learn a better and proper way to get the behavior I want."

There's a case to be made against GRUB2 as a boot manager when it comes to UEFI, but that discusssion belongs elsewhere.

You got it now. We are using UEFI disks. When the download is complete(I am at home now. it is slow) one of the boxes is here and I will post as soon as I can try an install and get some data on the problem. From what I was told the fault is selecting the correct EFI boot disk and partition. That may not be correct. I have not seen the problem from the users box. I was just looking earlier for a proper install with GPT and MBR disk when I saw this bug and became Concerned that this bug was closed. I promise to not be so long winded from now on. If this is the case I will open a new bug. This is probably the wrong place to work that problem out.

(In reply to comment #50)
> It's not a matter of can't, it's a matter of won't. There is no room on
> ext[234] to embed grub in a boot loader area, so block lists must be used to
> chain load the grub2 core.img. The file system is not notified of these
> block lists. At any time the file system can write to a sector compromising
> a block list and instantly render the system unbootable. It's quite easy to
> reproduce with smaller file system with less than a dozen writes.

Yada, yada. Always "blocklist fragility" is the response to those wishing for VBR installation. Why in hundreds of Grub Legacy installations I haven't seen this happen was the reason for my as yet unaddressed comment 47 "what is required to expose the purported fragility of Grub installation to a partition". Is it Grub2's larger size increasing this putative risk? What's required to experience this dastardly result?

What is the real risk on multiboot systems if one VBR installation's "fragile" block list is corrupted? All that would be necessary if and when it occurred would be to choose another stanza that doesn't require access to the corrupted location, or to drop to Grub's shell to load via cmdline to boot whatever's required to clear the corruption problem.

Furthermore, the balance of the boot track is reserved on my systems for my use only. Putting any portion of a bootloader there is trouble I don't need or want that Grub Legacy does not impose.

If Fedora's goals include driving itself down in popularity and eroding its reputation, leaving this bug in this state should be rather effective.

> If you want the old behavior, learn to install 
> grub with the --force flag. Easy.
Sorry, but I used the --force flag more than once. Read above.

Yes, UEFI fixes this problem. But to many Linux distros still can't handle UEFI well. This is still no option so fare. Because you often depend on the BIOS-mode if you use Linux. Sadly. (No problem of fedora!)

> Chainloading core.img is fragile. No one wants to maintain this.

All right, but why is it maintained in lilo, grub1, ntldr and BCD?

> There are multiple ways to address this. It's possible to 
> include in one distro's /etc/grub/default, the kernel 
> command line for all other distros. grub-mkconfig calls 
> os-prober, which can locate other distros, create entries 
> for each one, while using the proper distro specific
> command line.
It's the way how f18 anaconda makes other distros bootable. 
To include the kernel command lines of other distros, causes the problem, that new kernels of the other distros are not added automatic. 

> Another way is for a primary grub.cfg include menu entries 
> using the 'configfile' command to load the grub.cfg of other distros.
This is the way I'll may setup next time. But why doesn't anaconde use this solution bay default. It would be safe in your eyes and the different distros wouldn't influence each other to much. (This may be an other bug...)

(In reply to comment #53)

The context is GRUB2, Grub Legacy is no longer maintained at all. Fedora on x86 uses GRUB2. Reproducing the problem is not difficult, see comment 50. Using a larger 500MB boot, the likelihood of a problem is reduced but not eliminated, it becomes something like Big Sky Theory in aviation, which is simply not appropriate to hand over to everyone. It's like giving them razor blades and telling them to go play on the freeway. You can still do what you want by installing grub to a partition using --force. That anaconda doesn't hand you the razor blade is appropriate.


> What is the real risk on multiboot systems if one VBR installation's
> "fragile" block list is corrupted? All that would be necessary if and when
> it occurred would be to choose another stanza[snip]

You don't understand how grub or block lists work. Core.img is what is block listed with --force. If a single sector comprising any core.img block is overwritten, core.img fails to load and you don't even reliably get a grub rescue prompt, let alone a regular working shell which requires 100% of core.img to load, in order to find normal.mod.

The fundamental problem is that ext[234] only has 1024 bytes of bootloader space, and that's not enough for core.img.


(In reply to comment #54)
> Sorry, but I used the --force flag more than once. Read above.

I have no idea what this means. If you want a response, be more specific.


> > Chainloading core.img is fragile. No one wants to maintain this.
> 
> All right, but why is it maintained in lilo, grub1, ntldr and BCD?

GRUB Legacy is not maintained for ~ six years. NTFS has a significantly larger boot loader area, 16 sectors, compared to 2 for ext[234]. And I can't speak to lilo as I don't know much about it.


> It's the way how f18 anaconda makes other distros bootable. 
> To include the kernel command lines of other distros, causes the problem,
> that new kernels of the other distros are not added automatic.

Does any distro do this correctly, in your view? Which ones?


> This is the way I'll may setup next time. But why doesn't anaconde use this
> solution bay default. It would be safe in your eyes and the different
> distros wouldn't influence each other to much. (This may be an other bug...)

Anaconda's job strictly is to install the system. Not go hunting for other distros. Anaconda simply calls grub2-install and grub2-mkconfig. So it seems your complaint, and a solution rest largely with GRUB2. Not anaconda. And perhaps upstream grub2 would be inclined to take patches to enable the rather more sophisticated inter-distribution GRUB management you're proposing.

(In reply to comment #55)
> The context is GRUB2, Grub Legacy is no longer maintained at all.

A yada I left out of comment 53. It's mature, needs no upstream maintenance, and should need no Fedora maintenance. Subject to its well known limitations, Grub Legacy just works.

> Fedora on x86 uses GRUB2.

Exclusively, which is precisely the problem. Until after it supplanted Grub Legacy, Fedora's drivers didn't find it necessary to omit the function about which this bug.

> Reproducing the problem is not difficult, see comment 50.

As a response to reading comment 50, I repeated part of comment 47 in comment 53, which as yet I fail to see addressed. 

> > What is the real risk on multiboot systems if one VBR installation's
> > "fragile" block list is corrupted? All that would be necessary if and when
> > it occurred would be to choose another stanza[snip]
 
> You don't understand how grub or block lists work.

I don't need to understand how Grub2 works. I understand what I need to such that Grub Legacy works well enough to do everything I need, and without looking up constantly morphing docs applicable to a magnitudes less mature replacement bloated by features many have no need for.

> Core.img is what is block
> listed with --force. If a single sector comprising any core.img block is
> overwritten, core.img fails to load and you don't even reliably get a grub
> rescue prompt, let alone a regular working shell which requires 100% of
> core.img to load, in order to find normal.mod.

That's a design failure of the complete rewrite of Grub that should have been called something else and added as an option for those who require something not previously available, rather than replacing for everyone what works well enough for the majority of users.
 
> The fundamental problem is that ext[234] only has 1024 bytes of bootloader
> space, and that's not enough for core.img.

That's an upstream design choice that needn't and shouldn't be foisted on every Fedora user.

(In reply to comment #56)
Now that all of your criticisms are the domain of GRUB2, ext4, and FESCo, further posting to this bug seems distinctly moot.

(In reply to comment #57)
> Now that all of your criticisms are the domain of GRUB2, ext4, and FESCo,
> further posting to this bug seems distinctly moot.

I don't see how. The bug is as it has been from the beginning that Anaconda offers no option to install _any_ bootloader to a partition, not that Anaconda offers no option to install Grub2 to a partition. Grub Legacy is not the only alternative to Grub2 that could be installed to a partition without annoying upstream. See e.g. http://lists.fedoraproject.org/pipermail/devel/2013-January/176732.html

In reply to some earlier comments:

The GRUB2 documentation itself says that "... installing to a filesystem ... is quite fragile ..." and gives examples:

3.4 BIOS installation
http://www.gnu.org/software/grub/manual/grub.html#BIOS-installation

$ info grub2 Installation

(In reply to comment #58)
> Grub Legacy is
> not the only alternative to Grub2 that could be installed to a partition
> without annoying upstream.

Grub Legacy is not an alternative at all. It's been made clear Fedora isn't going to use an non-maintained GRUB. And syslinux is likewise too big to install into 1K for ext[234].

As I've said before, anaconda could support installing GRUB to a partition formatted with Btrfs because grub2-install will do this without complaint, as Btrfs has a 64KB pad expressly for this purpose.

OK, we don’t like to use a VBR, because of a to large image. (which is really bad work of the upstream)  We don't look for an alternative to Grub2, because in (hopefully near) future the UEFI-partition gonna fix all the here discussed problems. 

So fare I agree. 

But todays you often still depend on a BIOS-mode setup. And there is still the problem, that the anaconda of Fedora18 brakes the automatic kernel update of other RedHat-related distros. (RHEL5 and others too..)

Anaconda (f18) only copies a snapshop of the boot-configurations of the other ditros.  If a distro writes a new kernel into its grub.cnf, (Grub Legacy or Grub2) the F18-grub does not know about it. The user would have to run grub2-mkconfig manually. If he/she don’t do it, he runs into security problems sooner or later, because he uses still an old kernel… 

Until now I worked around this problem with chainloading. I see the configfile option of Grub2 as an good alternative. (see http://members.iinet.net/~herman546/p20/GRUB2%20Configuration%20File%20Commands.html#configfile_boot_entry ) 

But the way it's done in anaconda fedora 18 causes sooner or later problems for all other installed distros. That shouldn't be.

If anaconda would create "configfile entries" in place of coping  the howl  boot options of other distros, everything would work without any pain. Way did you not implement such an solution?

Should I open an new bug to ask for "configfile entries"?

(In reply to comment #61)

> But todays you often still depend on a BIOS-mode setup. And there is still
> the problem, that the anaconda of Fedora18 brakes the automatic kernel
> update of other RedHat-related distros. (RHEL5 and others too..)
> 
> Anaconda (f18) only copies a snapshop of the boot-configurations of the
> other ditros.  If a distro writes a new kernel into its grub.cnf, (Grub
> Legacy or Grub2) the F18-grub does not know about it. The user would have to
> run grub2-mkconfig manually. If he/she don’t do it, he runs into security
> problems sooner or later, because he uses still an old kernel… 

It's been that way in Arch linux for some months now.  I suspect it's the way of the future that cannot be avoided indefinitely.

I believe that users of multiple linux boot setups will be able to run grub2-mkconfig manually without too much fuss as they are not likely to be newbies.  It's a niggle, but not a deal breaker.  I've been doing this for awhile in my triple-linux boot setup, as I have been using Arch linux's GRUB2 for over a year,

Single linux boot systems (with or without Windows) should not need to run grub2-mkconfig manually.

That said, Mageia 2 is still using GRUB legacy and the way they update the kernel does not change the kernel boot line.  If other distros could incorporate a similar method with GRUB2, that would be the best.  [We'll have to see how Mageia 3 handles GRUB2 when Mageia 3 is released]

FTR, my issue with Anaconda was stated previously in comment #40.

There is also a legacyconfigfile command in GRUB2 which can read a GRUB Legacy grub.conf/menu.lst file. I haven't tested this myself. But the point is, you can have distro specific configuration files, maintained by those distros as kernels are updated, and choose to standardize on a single GRUB2 instance with a primary grub.cfg which is never touched by any distribution; it merely points to the configfile of each distro.

I still think it's better to go to the effort of culling all the distros for their unique kernel parameter lines, and adding them to one distros /etc/default/grub, and allowing that distro, which should have the most up to date version of grub2, produce the "master" grub.cfg. It's inelegant that after a kernel update for any distro, that the user would have to boot the primary distro and manually run grub2-mkconfig. But unless every distro has the same version of GRUB2, you can't guarantee the resulting grub.cfg has the proper syntax, as through the entire prerelease phase of grub2, the syntax of the cfg was changing.

Also, at least on Fedora, while anaconda initially creates the grub.cfg by calling grub2-mkconfig; subsequent kernel updates use grubby. And grubby merely templates a line in the grub.cfg, addds a new entry, and then starts deleting other entries. The new entry has a different prose, i.e. it doesn't just say Fedora, it says Fedora and the kernel version. Eventually grubby mucks up the grub.cfg such that other menu entries are messed up. So I end up using grub2-mkconfig after every kernel update anyway, because grubby is simply too unsophisticated to properly/cleanly update a grub.cfg.

The reality is, multiboot is messy. To do this better is quite a project, and one that's outside the scope of anaconda.

"The reality is, multiboot is messy. To do this better is quite a project, and one that's outside the scope of anaconda."

it's done and fixed and called UEFI boot manager, and the sooner we all start using it the better for my sanity. ;)

(In reply to comment #64)
> "The reality is, multiboot is messy. To do this better is quite a project,
> and one that's outside the scope of anaconda."

Messy like the art of painting, and in the case of F18's Anaconda, like trying to paint real life using only half a palette. Sometimes you can, sometimes you can't.

> it's done and fixed and called UEFI boot manager, and the sooner we all
> start using it the better for my sanity. ;)

I fear for your sanity. :-) One can only speculate on how long it will take until "all" are using it, as UEFI is no option without cooperation from firmware that doesn't exist on most PCs in current use. Eradicating BIOS boot will likely be more like eradicating the floppy disk than the ISA bus, which is to say not a few of us are unlikely to live to see it happen.

(In reply to comment #50)

> It's not a matter of can't, it's a matter of won't. There is no room on
> ext[234] to embed grub in a boot loader area, so block lists must be used to
> chain load the grub2 core.img. The file system is not notified of these
> block lists. At any time the file system can write to a sector compromising
> a block list and instantly render the system unbootable. It's quite easy to
> reproduce with smaller file system with less than a dozen writes.

The blocklist contains the numbers of blocks occupied by "core.img" on the file system, correct? So unless "core.img" is unlinked and regenerated, or otherwise relocated in any way, the blocklist should remain valid. I don't understand how the blocklist would get corrupted with a dozen writes unless these writes go directly to "core.img". Could you please explain that?

The situation has changed, as FESCO decided to allow boot loaders in partitions with ext2/3/4 (see Feature 19: https://fedoraproject.org/wiki/Features/SyslinuxOption). As Extlinux uses blocklists to boot from an ext2/3/4, I conclude, that blocklists for booting from a partition are OK for FESCO. 

So I would like to re-open this entry, to include GRUB2 as a boot loader for a partition with ext2/3/4 simliar to extlinux from the above FESCO approved feature.

I don't think the inclusion of that feature should be read as any general policy decision.

*** Bug 907676 has been marked as a duplicate of this bug. ***

That is an extreme stretch indeed. The question is not what's 'OK for FESCo' - FESCo is hardly a corporate expert on the field of bootloaders, and likely did not consider this issue at all in approving the above feature.

I am also not too happy with this issue but I can see the arguments for not installing grub to a partition using blocklists. Even though https://bugzilla.redhat.com/show_bug.cgi?id=908118 and https://bugzilla.redhat.com/show_bug.cgi?id=886502 make it worse for me ;)

While discussing, could someone please take a few minutes to answer my question in comment #66?

(In reply to comment #72)
> While discussing, could someone please take a few minutes to answer my
> question in comment #66?

This issue is beyond my expertise, but the following wiki page seems to explain it well.  It also shows a work-around by using the immutable flag on core.img.  Setting the immutable flag is similar to what takes place with immovable files encountered in Windows I imagine.

https://wiki.archlinux.org/index.php/GRUB2#Install_to_Partition_or_Partitionless_Disk

(In reply to comment #73)

> This issue is beyond my expertise, but the following wiki page seems to
> explain it well. It also shows a work-around by using the immutable flag on
> core.img.  

Indeed, rather than explaining why it can't be done, that page provides a neat trick to avoid corruption of the block list. The two bugzilla references on the Wiki page don't provide any further insight.

Block lists will be broken when core.img itself gets rewritten. This is the case whenever grub2 is updated, but that's no problem because "grub2-install" will re-run "grub2-setup" anyway whenever such update happens. It would be easy to add chattr [+-]i statements in the grub2 tools to make sure nobody else messes with core.img by mistake.

But how would anything else but rewriting core.img itself corrupt the blocklist?? I'd appreciate some enlightenment by the folks who claim that this corruption can be achieved with just a few writes to the file system.

The GRUB2 documentation says that "GRUB is vulnerable to its blocks being moved around by filesystem features such as tail packing, or even by aggressive fsck implementations"[1], but it is not clear how to induce those ...

I tried to demonstrate that core.img blocks could be moved by resizing the ext4 file system to a minimum and then back to the size of the partition, but that procedure doesn't seem to affect booting.

This is the closest I could get:[2]

Install grub2 to a partition using the grub2-install "--force" option.
Verify that booting by chainloading works.

# cp -p /boot/grub2/i386-pc/core.img /root/core.img.BAK1 # make a backup copy
# rm /boot/grub2/i386-pc/core.img

Reboot.
This reboot succeeds.

# cat /dev/zero > /root/x1.dat # fill the file system

Reboot.
This reboot fails.

# rm /root/x1.dat # free space on file system
# cp -p /root/core.img.BAK1 /boot/grub2/i386-pc/core.img # restore core.img from the backup copy.

Reboot.
This reboot also fails.

[1] 3.4 BIOS installation
http://www.gnu.org/software/grub/manual/grub.html#BIOS-installation

[2] For brevity, I have omitted numerous details.

(In reply to comment #75)
Thanks a lot. This is in line with what I thought.

> The GRUB2 documentation says that "GRUB is vulnerable to its blocks being
> moved around by filesystem features such as tail packing, or even by
> aggressive fsck implementations"[1]

It also says "There is no way to reserve space in the embedding area with complete safety", that's a tie between embedding vs. block list. (AFAICS, the only Linux FS supporting tail packing is ReiserFS).

Still waiting for instructions how to corrupt the block list without corrupting core.img itself. Until I see those, I don't buy the argument that block lists are too fragile for production use.

(In reply to comment #76)
> Still waiting for instructions how to corrupt the block list without
> corrupting core.img itself. Until I see those, I don't buy the argument that
> block lists are too fragile for production use.

The way I read it, GRUB2 prefers (in a strong sense) to write core.img to the MBR rather than to a blocklist.  If one forces core.img to be written to a blocklist (rather than the MBR), then the OS filesystem under normal operation, in certain circumstances, may fragment core.img.  Core.img would still be accessed as a complete single file by the filesystem, but GRUB2 (because of not having access to the filesystem pointers) would not get the complete core.img file.  In fact there may be fragments of unrelated files interspersed within.  The filesystem of the OS has the data to reconstruct core.img as a whole complete file, even though it is fragmented across the disk.  GRUB2 cannot reconstruct core.img since it does not have the filesystem pointer information of the file fragment locations across the disk.

However if core.img is labeled as immutable that would seem to side-step the problem (as long as the filesystem always saw core.img as immutable).  All filesytem tools that one might use would have to see core.img immutable as well.

The first part of what I just wrote isn't right.

Here is the edited version:

The way I read it, if GRUB2 is not installed to the MBR, then GRUB2 writes the pointers to core.img in a blocklist in the boot sector.  The OS filesystem under normal operation, in certain circumstances, may fragment core.img, as it is in the filesystem's domain.  Core.img would still be accessed as a complete single file by the filesystem, but GRUB2 (because of not having access to the filesystem pointers) would not get the complete core.img file. GRUB2 would be relying on outdated blocklist pointers. The problem is that the blocklist is never updated with new pointers if the OS file system moves any portion of core.img.

(In reply to comment #76)
> Still waiting for instructions how to corrupt the block list without
> corrupting core.img itself. Until I see those, I don't buy the argument that
> block lists are too fragile for production use.

Ask on grub-devel. The devs have wanted to get rid of blocklists for a while, I've seen emails going back to at least 2008 saying this. When the developers themselves don't want to support it, I don't see the point in arguing, but the argument is with them, not red hat, not Fedora Project. Use GRUB the way they intend it to be used: core.img goes in the MBR gap, or BIOS Boot, or ESP. If that doesn't work for your use case, use extlinux on BIOS; gummiboot/rEFINd on UEFI. Simple.
https://lists.gnu.org/mailman/listinfo/grub-devel

(In reply to comment #73)
Reading that wiki page, I wonder how the following ties in with the discussion:
(The important parts are enclosed by >> and <<)

----
The reason why grub-setup does not by default allow this is because in case of partition or a partitionless disk is that grub-bios relies on >>embedded blocklists in the partition bootsector<< to locate the /boot/grub/i386-pc/core.img file and the prefix dir /boot/grub.

[snip]

The immutable flag on /boot/grub/i386-pc/core.img needs to be set >>only<< if grub-bios is installed to a partition boot sector or a partitionless disk, >>not in case of<< installation to MBR or >>simple generation of core.img without embedding any bootsector<<.

To populate the /boot/grub directory and generate a /boot/grub/i386-pc/core.img file >>without embedding any grub-bios bootsector code in the MBR, post-MBR region, or the partition bootsector<<, add --grub-setup=/bin/true to grub-install:

# modprobe dm-mod
# grub-install --target=i386-pc --grub-setup=/bin/true --recheck --debug /dev/sda
# mkdir -p /boot/grub/locale
# cp /usr/share/locale/en@quot/LC_MESSAGES/grub.mo /boot/grub/locale/en.mo

>>You can then chainload GRUB2's core.img from GRUB Legacy or syslinux as a Linux kernel or a multiboot kernel<<.

----

If it's possible to make the new Linux instance bootable through chainloading WITHOUT having to rely on blocklists, wouldn't it solve the problem? 

Is this enough to let the mbr-installed boot loader start booting the new Linux instance?

Is the problem with chainloading only related to the use of blocklists in the core.img file, and thus circumvented by using the simple core.img described above?

There don't appear to be any problems with chainloading other OS's AFAICT.  As I understand it, the only problem is trying to chainload other instances of GRUB2.

On my laptop I had GRUB2 installed from Arch Linux and was booting Arch, F17, Mageia 2, and Win7 all from Arch's GRUB2.  When I installed F18, F18 replaced Arch's GRUB2 without warning me (Tsch, Tsch).  I did not want to use Fedora's GRUB2, so I reinstalled Arch's GRUB2 from within Arch.

So now I have Arch's GRUB2 installed to the MBR.  I boot the other OS's from Arch's GRUB2.  Mageia 2 was installed with Legacy GRUB to the root partition of Mageia.  F18 no longer has it's own GRUB, as it was replaced by Arch's GRUB.  Windows is chainloaded, as is typical.  I can boot F18 fine just by copying the relevant lines from Fedora's grub.cfg to /etc/grub.d/40_custom.  This is also what I do with Mageia.  Every time Fedora's linux kernel is updated I have to update /etc/grub.d/40_custom by copy/paste, then rebuild grub.cfg from within Arch.

Bottom line: It seems only one instance of GRUB needs to be installed regardless of the number of instances of Linux installed.  Each instance of Linux that does not have it's own GRUB installed, just needs rebuild it's own instance of grub.cfg for each kernel update so that that grub.cfg can be used as a template for editing /etc/grub.d/40_custom of the active instance of GRUB.

https://wiki.archlinux.org/index.php/GRUB2#Dual-booting

(In reply to comment #81)
> Bottom line: It seems only one instance of GRUB needs to be installed
> regardless of the number of instances of Linux installed.  Each instance of
> Linux that does not have it's own GRUB installed, just needs rebuild it's
> own instance of grub.cfg for each kernel update so that that grub.cfg can be
> used as a template for editing /etc/grub.d/40_custom of the active instance
> of GRUB.

This is only true, as long as your GRUB is able to boot your linux instance. E.g. when Fedora introduces a new filesystem (like ext4 a few years ago), then typically your old GRUB is not able to boot files from this (unknown to him) filesystem. The same could be true for btrfs and all coming filesystems.

This is why I prefer chainloading multiple GRUBs. The MBR Grub only chainloads the GRUB of the linux system installed on the partition. This GRUB is from the linux system to be booted and is therefore always able to handle it. Also its configuration systems fits to the linux system installed. I typically install the current Fedora version but keep the previous one in a seperate partition.

And this is why I would love to get GRUB chainloading enabled, because it seems to be the easiest solution for my use case.

(In reply to comment #81)
> Every time Fedora's linux kernel is
> updated I have to update /etc/grub.d/40_custom by copy/paste, then rebuild
> grub.cfg from within Arch.

Ick. Messy, and unnecessary. Insert into Arch GRUB's grub.cfg, an entry for each OS, using configfile (or legacyconfigfile) pointed to the relevant distribution's grub.cfg. Now you can update any distro's kernel, which will update its own grub.cfg and you do not have to use your Rube Goldberg method. The use of configfile has already been mentioned in this bug more than once.

(In reply to comment #82)
> This is only true, as long as your GRUB is able to boot your linux instance.
> E.g. when Fedora introduces a new filesystem

You want to use a new file system, put /boot on it, and use an ancient bootloader that can't use it. That's the weirdness required to arrive at the problem you're hypothesizing.

>The same could be true for btrfs and all coming filesystems.

If you'd bothered to read the entire bug report first, you'd see that btrfs supports embedding of GRUB in a 64KB pad before the file system starts on its partition. It's designed for this. GRUB supports it without --force.

> And this is why I would love to get GRUB chainloading enabled, because it
> seems to be the easiest solution for my use case.

It seems to be the only solution you're familiar with. So instead of learning about other options that might be better, you're asking other people to develop and support what they've already looked at and decided they don't want to support.

(In reply to comment #77)
> If one forces core.img to be written to
> a blocklist (rather than the MBR), then the OS filesystem under normal
> operation, in certain circumstances, may fragment core.img.

Sure. And my question is: *exactly what "certain circumstances" are that*? IMO it can't be easily done without modifying core.img directly (which could be avoided with the immutable flag altogether). 

Still waiting for evidence of the contrary.

(In reply to comment #79)
> Ask on grub-devel.

OK, I will. I think I shall also ask on ext4-devel.

> When the
> developers themselves don't want to support it, I don't see the point in
> arguing, but the argument is with them, not red hat, not Fedora Project. 

This bug is against Fedora: anaconda not being able to install a boot loader anywhere else but in the MBR.

This is as matter of how an OS fits in an existing environment. Being able to be booted by chain-loading makes an OS a good, friendly citizen in a multi-boot environment. Linux distributions (as opposed to other OS) used to be multi-boot-friendly over decades. Fedora broke with this tradition, and users who are dissatisfied with that are speaking up here.

The suggested tricks involving rescue CD, chroot, and manual grub2 installation don't qualify as serious solutions that would make up for the missing functionality in Fedora.

Proper multi-boot functionality is an important feature for a Linux Distribution. It is up to the Fedora Project to figure out how this feature can be procured.

(In reply to comment #86)
> OK, I will. I think I shall also ask on ext4-devel.

I already asked on ext4-devel (http://comments.gmane.org/gmane.comp.file-systems.ext4/36637). The ext4 teams has ideas on how to savely store core.img in the ext4 filesystem. They already reserved an inode for this purpose.

However, there is some missing code. I am willing to write a first implementation to close that gap. If I (or others) succeed, then ext4 will be able to be used by grub-install without using --force. My hope is, that Fedora will then also support this configuration as it is then supported upstreams.

(In reply to comment #83)
> (In reply to comment #81)
> > Every time Fedora's linux kernel is
> > updated I have to update /etc/grub.d/40_custom by copy/paste, then rebuild
> > grub.cfg from within Arch.
> 
> Ick. Messy, and unnecessary. Insert into Arch GRUB's grub.cfg, an entry for
> each OS, using configfile (or legacyconfigfile) pointed to the relevant
> distribution's grub.cfg. Now you can update any distro's kernel, which will
> update its own grub.cfg and you do not have to use your Rube Goldberg
> method. The use of configfile has already been mentioned in this bug more
> than once.

Indeed.  Just tried the configfile method.  Works pretty good.  Sure cleaned up my /etc/grub.d/40_custom file.  I am now using "configfile /boot/grub2/grub.cfg" in /etc/grub.d/40_custom to boot F18, as well as "chainloader =1" to boot Mageia 2 (installed with legacy grub).

I disabled os-prober in F18's /etc/default/grub file and rebuilt F18's grub menu to clean it up.

Note that the legacy_configfile option brought up Mageia's GRUB menu, but Mageia wouldn't boot.  Instead of legacy_configfile, I tried chainloader +1, and Mageia booted fine with that.  I used the hiddenmenu option in menu.lst and deleted all other OS references in menu.lst except Mageia.

Still, I wonder about comment #25

Created attachment 694385 [details]
my new /etc/grub.d/40_custom file

(In reply to comment #87)
...
> I already asked on ext4-devel
> (http://comments.gmane.org/gmane.comp.file-systems.ext4/36637). The ext4
> teams has ideas on how to savely store core.img in the ext4 filesystem. They
> already reserved an inode for this purpose.
...

Thanks, Till. That sounds good.

IIUC, that link could be broken with something like this:
# cp -p core.img core.img.BAK1
# mv core.img.BAK1 core.img

(In reply to comment #90)
> IIUC, that link could be broken with something like this:
> # cp -p core.img core.img.BAK1
> # mv core.img.BAK1 core.img

No. The idea is, that core.img is a file with an inode but NOT with a directory entry. Therefore you are not able to use any userland tool on core.img because it is simply not there.

To create or access it, you need a special ext4-ioctl which has to be implemented. That is the todo. :-)

(In reply to comment #86)

If the file system, and GRUB, support a safe, reliable embedding, I see little reason why anaconda wouldn't support it.

I disagree that chainloading is the only way, or best way, to support multiboot. Context is relevant. These traditional ways of multiboot I think are more fragile and complex, than understanding GRUB2 alone and its prescribed multiboot features. UEFI, Btrfs, systemd, all break with tradition, so I find the tradition argument totally uncompelling.

Calling Fedora effectively "unfriendly" and lacking "proper" function, amounts to slander. You merely want things to work in a specific way, even when other methods still support the end goal of multiboot.

More people are better served by getting GRUB to be dynamically aware of the current state of bootable systems on a computer, rather than depending on a prebaked configuration script that may be days or months old.

(In reply to comment #91)
Is it more or less complicated to get a dedicated inode on ext4, or simply increase the boot sector pad? On ext4 now it's 1K. Btrfs is 64K. Embedding on btrfs is simple as a result, for the fs devs, for users, for GRUB devs.

(In reply to comment #92)
What breaks if the ext4 boot sector pad is increased?
What tools would need to account for the current size and a proposed increased size?
Could an existing ext4 file system be shifted to have an increased size?

I think I didn't get my question across like I meant it. Since this bug-report is about getting back the option of allowing Fedora to be booted from an already installed boot-loader, preferably without either boot-loader knowing any details of each other's operation, I would like to find out if there are any possibilities that would be acceptable from a technical viewpoint, upstream or elsewhere.

If the old use of block lists isn't going to be accepted, considering the fourth option in the list below:
  1) would it be OK to implement?
  2) would this solve the problem?
  3) would this be as simple to use on the side of the mbr-installed boot-loader as the old way?


(From the same Arch wiki-page as before)
Install grub-bios boot files

There are 3 ways to install GRUB(2) boot files in BIOS booting:

    #Install_to_440-byte_MBR_boot_code_region (recommended) ,
    #Install_to_GPT_BIOS_Boot_Partition (recommended with GUID_Partition_Table (GPT)) ,
    #Install_to_Partition_or_Partitionless_Disk (not recommended),
    #Generate_core.img_alone (safest method, but requires another BIOS boot-loader like grub-legacy or syslinux to be installed to chainload /boot/grub/i386-pc/core.img). 

from:
https://wiki.archlinux.org/index.php/GRUB2#Install_to_Partition_or_Partitionless_Disk

If this would be possible to implement, would we need another bug-report?

(In reply to comment #94)
> getting back the option of allowing Fedora to be booted
> from an already installed boot-loader, preferably without either boot-loader
> knowing any details of each other's operation

This refers to two boot loaders, so it's chain loading. The 1st must necessarily know details of the 2nd in order to find it. It's unreasonable for Fedora to become responsible for making the 1st aware of the 2nd.

It's legitimate to want Fedora's anaconda to create all files needed for another bootloader to be capable of booting Fedora. That is, create core.img and grub.cfg, even if core.img won't be installed to the MBR gap or BIOS Boot. I raised this in bug 885240, which led to bug 886502 asking for this and how anaconda should do it. Then it's possible for for another boot manager to:

1. Ideally, use configfile to read the Fedora grub.cfg. Any Fedora kernel updates cause this grub.cfg to be updated. Any boot manager that loads this grub.cfg thus gives the user immediate access to the updated kernel, yet it does not need to maintain the grub.cfg.

2. Less ideal, likely a confusing workflow, but still possible, would be if the 1st boot loader doesn't understand grub.cfg, but can read ext4 and locate the Fedora core.img.

3. Very strange is a boot manager or loader the user wants as primary, but doesn't understand grub.cfg, nor understands ext4, and thus can only chain load to a specific boot sector and read block lists in order to find and load core.img.

The issue in contention here is #3, is that somehow people have boot managers/loaders that can't do the most basic things, but still want them as primary for unknown reasons. That's the only use case for blocklisted core.img.

Both 2 and 3, in my opinion, are in the realm of: Fedora should encourage users to upgrade their crusty boot manager/loader to something that actually does what's needed: can read current and legacy grub configs, can boot Windows, can boot BSD, can boot OS X, does understand pretty much any file system; GRUB 2.00 can directly read boot files from ext[234], XFS, btrfs including multiple device linear, raid and compression, mdraid 0,1,5,6,10, LVM, ZFS, and others.

Now, I'm happy to argue in favor of a different strategy for VMs, as well as UEFI. But for BIOS baremetal, I don't understand what inept boot managers/loaders people are protecting that they want to blocklist chain load GRUB2.

 
> If the old use of block lists isn't going to be accepted, considering the
> fourth option in the list below:
>   1) would it be OK to implement?
>   2) would this solve the problem?
>   3) would this be as simple to use on the side of the mbr-installed
> boot-loader as the old way?

I think by 4th option you mean chain load to core.img (my option #2 above). Yes I think it's fine. It's odd to me, but I see no injury to Fedora anaconda to use grub2-install --grub-setup=/bin/true, when the user asks for no boot loader to be installed, instead of not calling grub2-install at all (present behavior).

> If this would be possible to implement, would we need another bug-report?

Correct me if I'm wrong, but I think that's bug 886502.

Here are several good questions from Martin[1] and replies:

Subject: GRUB and the risk of block list corruption in extX
http://thread.gmane.org/gmane.comp.file-systems.ext4/36911

[1] per Comment 86

(In reply to comment #96)
Note in particular Ted Ts'o's statement:

"I think the grub2 developers are being far too paranoid.  In practice,
ext4 doesn't move blocks around."

http://article.gmane.org/gmane.comp.file-systems.ext4/36924

(In reply to comment #92)

> If the file system, and GRUB, support a safe, reliable embedding, I see
> little reason why anaconda wouldn't support it.

Recent discussions indicate that block lists in extX are more reliable than people often say. If that turns out to be true, this dispute could be solved quite easily.

> I disagree that chainloading is the only way, or best way, to support
> multiboot. 

We have different opinions, then. The huge advantage of chainloading (traditional chainloading, not "kernel .../core.img") is separation. The primary boot loader needs no knowledge whatsoever about the OS it is booting into. Neither needs the secondary loader know anything about the primary environment. That leads to a clean setup where the different OS are self-contained and can't interfere with each other.

> UEFI, Btrfs, systemd, all break with
> tradition, so I find the tradition argument totally uncompelling.

It's about dropping a useful feature, not "tradition" by itself.

> Calling Fedora effectively "unfriendly" and lacking "proper" function,
> amounts to slander.

I tried to express my opinion politely. I apologize if I failed to do so.

> More people are better served by getting GRUB to be dynamically aware of the
> current state of bootable systems on a computer, rather than depending on a
> prebaked configuration script that may be days or months old.

In my favorite setup, this script is as simple as "root (hdX,Y); chainloader +1". Even if this is years old, it still works exactly the way I want. The secondary bootloader started in this way may the unfold his shiny dynamic menu for me, giving me the best of both worlds.

(In reply to comment #36)
> If you don't want your primary boot manager replaced, in anaconda you need
> to deselect boot loader installation from the Installation Destination >
> Click on Full disk summary and options to reveal the Selected Disks dialog.
> Select disks and click "Do not install bootloader". Your system will not be
> bootable without additional post-install configuration. It's suggested you
> do this after installation has successfully finished, but before you reboot.
> 
> 2. Create GRUB2 core.img, suppress embedding in the MBR, produce grub.cfg.
> -Confirm the whole /dev/sdX device Fedora 18 is installed on.
> mount | grep sysimage
> chroot /mnt/sysimage
> -Install GRUB, using whole /dev/sdX device from previous step, not including
> partition number.
> grub2-install --grub-setup=/bin/true /dev/sdX
> grub2-mkconfig -o /boot/grub2/grub.cfg
> 
> 3. If you already have a GRUB2 instance, you can now add a menu entry to
> that distribution's grub.cfg, using 'configfile' to load the Fedora 18
> grub.cfg created in step 2 above.

I had occasion to reinstall Fedora 18, so I gave this method a shot.  Rebooted the Fedora DVD and chose Rescue, after getting to terminal, followed the sequence above.  Basically it worked with a caveat.

A problem still remains.  No /etc/default/grub file is generated for passing parameters to grub.cfg.  This problem is mentioned as well in the following bug report: https://bugzilla.redhat.com/show_bug.cgi?id=886502

I ended up copying a /etc/default/grub file from my Arch linux partition and editing it a bit for Fedora.  Not ideal by any means.

(In reply to comment #99)
> I had occasion to reinstall Fedora 18, so I gave this method a shot. 
> Rebooted the Fedora DVD and chose Rescue

It's sufficient to switch to the text console and type the grub2 commands before the first reboot - no need to boot the rescue system.

Yup - the time to do that would be after the official install process is complete, but before rebooting. ctrl-alt-f2 gives you a console in anaconda.

(In reply to comment #86)
> (In reply to comment #79)
> > Ask on grub-devel.
> 
> OK, I will. I think I shall also ask on ext4-devel.

Here is an answer from Vladimir Serbinenko:

  http://article.gmane.org/gmane.comp.boot-loaders.grub.devel/19725
  http://article.gmane.org/gmane.comp.boot-loaders.grub.devel/19730

The scenario is as follows: 

 1 A user deletes and recreates core.img by mistake, invalidating the block list
 2 Later writes on the file system reuse the blocks still referenced by GRUB's block list.

(2) is a security threat because an attacker with just the ability to write files to the file system could craft a malicious sector and write it to the FS until the FS is full - he would have a good chance to write to the first block in the block list and have his malicious code executed at the next reboot.

(1) could come to pass in several ways. Realistic error scenarios that come to mind are
 a) User runs grub2-mkimage but not grub2-setup
 b) User restores core.img from a backup and forgets to run grub2-setup


I can understand that with this in mind, bock list installation shouldn't be a first class option in the Fedora installer. But this risk doesn't preclude offering it as an "expert" option with an appropriate warning, either. 

Personally, I could live with (ctrl-alt-F2, chroot /mnt/sysimage, grub2-install --force /dev/$ROOTPART) when bug #886502 is fixed. I just think that Fedora could improve its attractiveness by offering said "expert" option.

(In reply to Martin Wilck from comment #98)
> (In reply to comment #92)
> 
> > I disagree that chainloading is the only way, or best way, to support
> > multiboot. 
> 
> We have different opinions, then. The huge advantage of chainloading
> (traditional chainloading, not "kernel .../core.img") is separation. The
> primary boot loader needs no knowledge whatsoever about the OS it is booting
> into. Neither needs the secondary loader know anything about the primary
> environment. That leads to a clean setup where the different OS are
> self-contained and can't interfere with each other.

I agree with Martin.  In particular Linux should never touch a Windows (NTFS) partition, or any previously installed partitions, unless explicitly marked for install.

> > UEFI, Btrfs, systemd, all break with
> > tradition, so I find the tradition argument totally uncompelling.

In my experience they all break Linux.

> It's about dropping a useful feature, not "tradition" by itself.

And if the alternatives were seamless and worked, there would not be so much pushback.  Mainly people just want FC19 to work as well for them as previous versions.  And if the new feature is truly better than the old, people will be more than happy to use it.

> > Calling Fedora effectively "unfriendly" and lacking "proper" function,
> > amounts to slander.
> 
> I tried to express my opinion politely. I apologize if I failed to do so.

It is not slander to point out regressions and breakages.

> > More people are better served by getting GRUB to be dynamically aware of the
> > current state of bootable systems on a computer, rather than depending on a
> > prebaked configuration script that may be days or months old.
> 
> In my favorite setup, this script is as simple as "root (hdX,Y); chainloader
> +1". Even if this is years old, it still works exactly the way I want. The
> secondary bootloader started in this way may the unfold his shiny dynamic
> menu for me, giving me the best of both worlds.

Me too.  I've used the old grub enough to understand its limitations, but I've also used the new grub2 enough to know its limitations.  grub2 still isn't as good as legacy grub.  That's not slander, it is a technical evaluation.

Russ: are you volunteering to maintain grub-legacy for the next ten years? Because that's what's required for us to use it, and that's why we went to grub2. Not because we think it's better, necessarily, but because neither upstream nor anyone else wants to maintain grub-legacy any more.

(In reply to Russ Anderson from comment #103)
It continues to baffle me how people who have enough technical expertise to consider "root (hdX,Y); chainloader +1" simple, yet consider unchecking the install bootloader option in anaconda and installing their preferred bootloader too difficult.

>In particular Linux should never touch a Windows (NTFS) partition<
I dont understand this. Not Linux, GRUB2, nor anaconda, ever touch (as in write to) the NTFS volume in any of the various ways of configuring multiboot.

>And if the alternatives were seamless and worked, there would not be so much
pushback.<

Except there's been almost no pushback. It's a handful of people who simply don't like that a previously available method, that's explicitly not sanctioned by the upstream project, is no longer available in the installer.

>grub2 still isn't as good as legacy grub.  That's not slander, it is a technical evaluation.<
Nothing prevents you from using unmaintained GRUB 0.97 if you prefer it. And as far as I know, grubby still correctly adds kernels to the old grub legacy grub.conf. So I really don't understand what the complaint actually is, or what solution you're proposing.

(In reply to Adam Williamson from comment #104)
> Russ: are you volunteering to maintain grub-legacy for the next ten years?

There is a concept of legacy mode, which basically means not updating grub, but not breaking it either.  

> Because that's what's required for us to use it, and that's why we went to
> grub2. Not because we think it's better, necessarily, but because neither
> upstream nor anyone else wants to maintain grub-legacy any more.

That's a reasonable answer, but means Fedora should make clear to existing grub users (which is most of them) that they should not use FC19 (unless they have very new hardware, and sometimes not even then).  Call FC19 a technology preview or proof of concept, to set expectations properly.

FWIW, I would prefer to do pretty much anything other than complain about (and open BZs) on Anaconda, grub2, and UEFI.  All I want is to install and boot the machine.  Once that starts working I'll move on to other things.

Russ: we switched to grub2 somewhere back around f16 or f17. not f19.

Switch to GRUB2 for BIOS was F16 and for UEFI was F18. F18 was the first to drop the use of the --force flag to compel grub2-install to install boot.img to the /boot partition VBR instead of the disk MBR.

I've tested installing F12 through F19 on an old 32-bit Dell Latitude circa 2006 with and without Windows Vista already on it, and the final releases have all installed fine, and Windows is bootable. So again I don't understand the complaint, let alone how it relates to this bug.

We do have known issues with dual-boot installs on UEFI in some cases, but that's never worked _better_ in the past.

(In reply to Chris Murphy from comment #105)
> (In reply to Russ Anderson from comment #103)
> It continues to baffle me how people who have enough technical expertise to
> consider "root (hdX,Y); chainloader +1" simple, yet consider unchecking the
> install bootloader option in anaconda and installing their preferred
> bootloader too difficult.

It continues to baffle me how anyone that used the old Anaconda would not be horrified by the new Anaconda.  I just spent much of the last two days collecting debug info after the new Anaconda install failed to boot (BZ 975970) and later failed to install (BZ 978065) on a new laptop.  By contrast SuSE installed without issue, and even set up the Windows chainloader correctly.  The SuSE installer (yast2) did not require any extra bootloader steps.  If I was a customer, and not a glutton for punishment, I would have given up on FC19 and lived happily ever after with SuSE.

> >In particular Linux should never touch a Windows (NTFS) partition<
> I dont understand this. Not Linux, GRUB2, nor anaconda, ever touch (as in
> write to) the NTFS volume in any of the various ways of configuring
> multiboot.
> 
> >And if the alternatives were seamless and worked, there would not be so much
> pushback.<
> 
> Except there's been almost no pushback. It's a handful of people who simply
> don't like that a previously available method, that's explicitly not
> sanctioned by the upstream project, is no longer available in the installer.

The "handful of people" are just the tip of the iceberg and dismissing them is simply denial of real problems.  Don't shoot the messengers.

> >grub2 still isn't as good as legacy grub.  That's not slander, it is a technical evaluation.<
> Nothing prevents you from using unmaintained GRUB 0.97 if you prefer it. And
> as far as I know, grubby still correctly adds kernels to the old grub legacy
> grub.conf. So I really don't understand what the complaint actually is, or
> what solution you're proposing.

The way you dismiss people who report problems, I'm sure you don't understand what the complaint actually is.  Have you looked at how long the grub2 BZ list is?
https://bugzilla.redhat.com/buglist.cgi?bug_status=__open__&content=grub2&list_id=1479587&order=relevance%20desc&product=Fedora&query_format=specific
https://bugzilla.redhat.com/buglist.cgi?bug_status=__open__&content=grub2&list_id=1479590&order=relevance%20desc&product=Red%20Hat%20Enterprise%20Linux%207&query_format=specific

Yes. I was responding to this assertion: "they should not use FC19 (unless they have very new hardware"

(In reply to Adam Williamson from comment #109)
> We do have known issues with dual-boot installs on UEFI in some cases, but
> that's never worked _better_ in the past.

Yes, UEFI.  UEFI & grub2 have major problems.  UEFI and grub have had occasional issues.  UEFI & grub is much better.  And no, none of this involves secure boot.

FWIW, I stopped at FC14 on my desktop, to avoid the gnome3 "unholy mess" and get real work done.  FC19 only goes on test machines.

"UEFI & grub is much better"

No. No, it really isn't. Believe me, I've installed Fedora at least 1000 times as often as you have, and dealt with a hell of a lot more bootloader bug reports.

You're starting to sound like one of those people who think every possible change is for the worse, given you've so far bashed grub2, newUI, *and* gnome 3. Would you like to take a swing at systemd to complete the set?

(In reply to Russ Anderson from comment #110)
> It continues to baffle me how anyone that used the old Anaconda would not be
> horrified by the new Anaconda.

Well that's just plain unskilled trolling to bring that up in an old F18 bug report.

>By
> contrast SuSE installed without issue, and even set up the Windows
> chainloader correctly.

Well your bug reports clearly show an existing MBR which means you booted and installed Windows in CSM mode and then you booted Fedora in UEFI mode according to the syslog. So it seems you're pretty confused - which is entirely understandable because it's fairly mind numbingly hostile what hardware vendors have decided to subject us to. But that's the hand we've been dealt. You either want to fix bugs and improve Fedora or you want to complain and so far I get the impression you mostly want to complain and I won't assist you with that.

Windows almost invariably should be UEFI installed. With Linux you pretty much have to test UEFI and BIOS modes to see which mode will support your hardware better, mostly it's about getting the best video support but disk and battery performance might matter also. If the best mode is UEFI, then you need Windows and Fedora installed in UEFI mode on a GPT partitioned disk. If that mode is CSM (BIOS) then you need both Windows and Fedora installed in CSM mode on an MBR partitioned disk.

There may be a lot of hardware out there that'll work in UEFI mode with MBR partition scheme, and BIOS mode with GPT, but there are enough exceptions that it's safer to recommend UEFI->GPT and CSM/BIOS->MBR. The only way you can find out otherwise is to test it.


> The "handful of people" are just the tip of the iceberg and dismissing them
> is simply denial of real problems.  Don't shoot the messengers.

That's not what's happening. You need to stick to the facts. I understand it's easy to get P.O'd with what should be very basic (booting), and something that mortal people shouldn't have to interact with, at all.


> 
> The way you dismiss people who report problems, I'm sure you don't
> understand what the complaint actually is.

I do pretty flippantly dismiss improperly reported problems that are overly beaten dead horses. That's bug 969709. The complaint doesn't belong there. It's not a Fedora problem, or an anaconda problem to not support --force. It's a design decision. The fact installing to a partition isn't supported anymore is a direct consequence of grub maintainers not wanting to support it. So the work to convince them otherwise belongs in their forums and bug reports, not Fedora or anaconda.

Besides which nothing prevents the user from installing grub themselves with --force.

But yet again you throw spaghetti on a wall by bringing up some other complaint, this time one that's not even yours, while simultaneously doing very little to clarify what your complaint is. Did you just want to bring attention to bug 975970 and bug 978065? Or what?

>  Have you looked at how long the
> grub2 BZ list is?

Yeah I've filed a number of those myself. What's your point?

(In reply to Chris Murphy from comment #114)

> It's not a Fedora problem, or an anaconda problem to not support --force.
> It's a design decision. The fact installing to a partition isn't supported
> anymore is a direct consequence of grub maintainers not wanting to support
> it. So the work to convince them otherwise belongs in their forums and bug
> reports, not Fedora or anaconda.

As you know, Chris, I attempted this upstream discussion in February.

Using block lists to install grub (--force) isn't anything that would need dedicated "support" by upstream. It introduces the risk that the boot process breaks if the disk blocks that map "core.img" change. GRUB2 supports many different OSes and file systems. Even if block lists were safe in some environments, warning users of possible corruption makes sense from the upstream GRUB2 perspective.

In the context of a single OS (here: F18, F19), the situation is easier: the kernel is known, the set of supported file systems is limited, and there are other means of control. It would be possible for anaconda to allow --force only on ext4, for example. For ext4, the result of the upstream discussion was pretty clear - corruption can only occur if "core.img" itself is tampered with by the user. So far I have heard about only one realistic scenario for this to happen: "core.img" being restored from a backup, without re-running "grub2-install". Admins can reduce the risk of unintentional breakage e.g. by setting the immutable attribute on "core.img", or by an  SElinux rule allowing only "grub2-mkimage" to write "core.img".

Thus, pointing at upstream is just an excuse. Fedora could support --force if they wanted. But they decided not to allocate Dev and QA resources for it (http://permalink.gmane.org/gmane.comp.boot-loaders.grub.devel/19735). That's indeed a design decision. Fedora is free to make this decision, and people are free to use other distros if they don't approve.

Out of curiosity, I'd be interested to know how many bug reports Fedora / Red Hat got about boot problems that turned out to have been caused by a block list corruption of "core.img" or "stage1".

For reference, here are a few links to statements from upstream developers from the discussion in February:

Jan Kara: http://permalink.gmane.org/gmane.comp.file-systems.ext4/36912
Ted Ts'o: http://permalink.gmane.org/gmane.comp.file-systems.ext4/36924
Vladimir Serbinenko: http://permalink.gmane.org/gmane.comp.boot-loaders.grub.devel/19725

Finally, work was going on in February to use EXT2_BOOT_LOADER_INO for safe embedding of a bootloader in ext4. I don't know what the status is, though.

(In reply to Martin Wilck from comment #115)
> Using block lists to install grub (--force) isn't anything that would need
> dedicated "support" by upstream.

The very fact embedding in ext is sufficient rationale for the anaconda team to just not go down this road.
 
> In the context of a single OS (here: F18, F19), the situation is easier: the
> kernel is known, the set of supported file systems is limited, and there are
> other means of control. 

The majority of fs's either explicitly cannot have grub embedded, or it being embedded isn't recommended and requires --force to do so. And the anaconda team isn't responsible for, and likely doesn't have time to be keeping track of what the kernel team is doing, so I think it's a totally inappropriate speculation that the anaconda team knows about kernel behaviors.

The only fs that can officially support grub embedding without --force is btrfs. And even that isn't necessarily ready for the anaconda team to just go whole hog and support.


> It would be possible for anaconda to allow --force
> only on ext4, for example. 

This is frustratingly imprecise language. Anaconda is not preventing the user from using --force themselves, therefore it is already allowed. What you've consistently asked for is for it to be available (supported) in the GUI, which requires a non-trivial amount of code to a.) show the embed to partition UI to the user, b.) cause the --force flag to be used c.) cause a particular slice to become the grub target, and d.) myriad additional error handling as a result of this new feature, and e.) maintain all of this in subsequent versions of anaconda.

Now, of course all of that is possible to do. But is it recommended? No. Is it best practices? No. Is there a better way to do this? Yes. You just don't happen to like the alternatives, you simply want to do things the way you've been doing them. It's entirely reasonable to want to keep doing things the way you've been doing them, even if it's weird and inefficient, because it's familiar. But your preference in absolutely no way obligates the anaconda team to build what you want.


> Thus, pointing at upstream is just an excuse.

It is a fully qualified, legitimate excuse. The anaconda team is behaving entirely within the norms of professional courtesy to defer to grub upstream on what is recommended practice for the installation of and on going usage of the boot loader, and what is not recommended. You simply don't like the upstream grub response, and you don't like the anaconda team's deference to that response. But you not liking this outcome is just not with merit.

> Fedora could support --force
> if they wanted. But they decided not to allocate Dev and QA resources for it
> (http://permalink.gmane.org/gmane.comp.boot-loaders.grub.devel/19735).
> That's indeed a design decision. Fedora is free to make this decision, and
> people are free to use other distros if they don't approve.

Yes. Exactly.

If you want it in Fedora, you need to re-evaluate your argumentation because calling things excuses, saying that what you want could be done while not one single person has stepped forward to build what you want, is no where near enough of a compelling argument for the anaconda team to do what you keep saying should be done.


> 
> Out of curiosity, I'd be interested to know how many bug reports Fedora /
> Red Hat got about boot problems that turned out to have been caused by a
> block list corruption of "core.img" or "stage1".

Difficult to say because such corruption will manifest in a fairly generic failure that could have many causes.



> 
> For reference, here are a few links to statements from upstream developers
> from the discussion in February:
> 
> Jan Kara: http://permalink.gmane.org/gmane.comp.file-systems.ext4/36912
> Ted Ts'o: http://permalink.gmane.org/gmane.comp.file-systems.ext4/36924
> Vladimir Serbinenko:
> http://permalink.gmane.org/gmane.comp.boot-loaders.grub.devel/19725
> 
> Finally, work was going on in February to use EXT2_BOOT_LOADER_INO for safe
> embedding of a bootloader in ext4. I don't know what the status is, though.

Well I think there's much cart before the horse here. You have established no scope for this work, no one stepping forward to write the necessary code for anaconda, no parameters for what they need from upstream grub nor a tentative agreement with the anaconda team to accept the code should it be written, or the UI/UX lead, on what this would look like and how will maintain it going forward. Something tentative might be a good idea to have first, and a bug report isn't the right place to have this conversation. And then you need to find out from the grub team what they are willing to support or not. And then go to ext devs and get that thing built.

So yes I've heard of the inode idea, I don't know that this meets the grub dev requirements. It seems to me an offset would be a lot simpler, and already has precedent being supported by grub for btrfs which has a 64KB boot loader pad offset from the start of the file system.

But even before all of this, every time this idea has been posted somewhere where someone knows something about how grub works, they all think it's a universally bad idea to create a system that supports grub legacy chain loading grub2, which is the basic thing you want to do. The primary bootloader should be grub2, and use its configfile and legacy_configfile to point to distribution specific configuration files that are still independently maintained (updated) by those distributions.

(in reply to to Chris Murphy in comment #116)

The main point I wanted to make in this discussion was to clarify what the actual risk of block list installation is, and whether this risk justifies to call it a "universally bad idea", "fundamentally broken", etc. I tried to lay out the facts again in comment #115, to the best of my understanding. May the reader decide.

> You just don't happen to like the alternatives, you simply want to do things 
> the way you've been doing them.

Both sides have valid arguments. If they don't suffice to reach agreement, we can't help but say what we "like" and what not.

> You simply don't like the upstream grub response, 

That's not what I meant. I understand their position.

> What you've consistently asked for is for it to be available (supported) in 
> the GUI ...

My - perhaps naive - line of thought was that, since it was possible to support this in previous anaconda versions and in installers of other distributions, it should be relatively easy to do in current anaconda, too. Obviously I have been mistaken. I acknowledge the statement that the anaconda team prefers to allocate resources for other tasks.

> You have established no scope for this work, no one stepping forward to write > the necessary code for anaconda, ... 

True, I am not a Fedora or anaconda developer. It should still be legitimate, even welcome, if users bring forward arguments about design decisions they don't approve of.

> But even before all of this, every time this idea has been posted somewhere
> where someone knows something about how grub works, they all think it's a
> universally bad idea to create a system that supports grub legacy chain 
> loading grub2, ...

Strange, I didn't draw this conclusion from the discussions that I participated in, and that I read.

Just a few facts. As written above, linux 3.10 includes EXT2_BOOT_LOADER_INO. This code was written by me and it allows to safely embed a boot loader code into ext3/4.

My next step will be to improve GRUB2 to make use of that ioctl if available. I already looked into the code and it is not too much work to be done. The result will be, that you no longer have to use "--force" for ext3/4 and that there will be no warning about unsafe block list if installing to a partition. My plan is to finish this in the next weeks. If work is finished and accepted by GRUB I will inform the anaconda team about the change.
 
My hope is, that the anaconda team will then allow the installation of GRUB into a ext3/4 partition (as it should already allow so for btrfs which offers safe embedding from the beginning).

Hope this plan helps to cool down discussion, as there is at least a road to go. :-)

Well, this discussion is missing an important element.

The decision to leave the ability out was not based only on the 'upstream doesn't support it' argument, but also a UX argument. The option to install the bootloader to a partition is, for many users, essentially a 'shoot myself in the foot' button: if we include it it has to be included in such a way that only those who really want it and know the consequences of selecting it will use it.

The consequences of the current 'don't install a bootloader' option are fairly clear, even to a fairly inexperienced user, it should be clear that a bootloader is probably something you want to have. The consequences of installing a bootloader to a partition header rather than the MBR are rather less obvious if you simply present the two options and let the user freely pick, as old UI did. We certainly had bug reports with old UI which boiled down to 'I didn't realize I really shouldn't have done that'.

To put it in narrative form what more or less happened is this:

1) install-bootloader-to-partition was not included in the newUI mockups
2) so it wasn't included in the newUI work
3) at some point, someone noticed this, and reported it to anaconda
4) we had a big old knock-down-drag-out in #anaconda about whether and how this could be implemented sanely in the UI
5) someone pointed out that embedding wasn't even really supported and everybody jumped on that as a justification for just leaving it out entirely, which neatly solved the UI arguments
6) the 'no bootloader' option was added as a compromise for the userbase segment we jokingly refer to as OS Pokemon Trainers (because you guys have just Gotta Catch 'Em All...)

I don't recall it ever coming up whether the right question was asked of users in the process of installing to MBR systems. Instead of asking where to install the bootloader, Anaconda should be asking what the bootloader's job will be:

  Will Fedora's bootloader be expected to offer any other operating system(s) to start besides Fedora?

    ( ) Yes
    ( ) No

A yes answer means bootloader probably should goto MBR. It would not need to goto MBR if at least one primary partition slot is available for Fedora's unconditional use. A no answer means not MBR, which means both os-prober need not be enabled, and a selection of location needs to be offered. An appropriate follow-up question needs to be exposed only after a selection is made, and it needn't be asked during the same installation stage.

The foundational question could be posed early, then utilized during package selection and partitioning stages, and loader location selection made during partitioning phase, or post-package selection or installation.

That fits the general 'functional' approach, but I don't think it's a very good question, and I think it's a mistake to ask most users such a question at all.

Whether to ask such a question could depend on a partition table scan. The answer is probably obvious and the question not strictly necessary for systems with 1-3 non-native partitions and no more. It should be similarly obvious if a type 0x0A partition is present, active, and accompanied by generic-equivalent MBR code. On a system with a double digit partition count, particularly if sprawled across more than one physical storage device, no Linux installer should be presuming it knows a correct or best answer.

It is our general experience with the installer that things get messy very fast when you start trying to use heuristics. There's *always* an exception, a corner case, a condition you didn't think of...

I'm not saying we shouldn't do it, but be aware that doing it is _always_ an exercise in iterative frustration.

As an example of the above, we've been tweaking the goddamn 'Installation Options' dialog virtually non-stop since the first cut of newUI and it's still the weakest part of the newUI experience.

(In reply to Adam Williamson from comment #122)

> That fits the general 'functional' approach, but I don't think it's a very
> good question, and I think it's a mistake to ask most users such a question
> at all.

What about the following: 

1. "Will other operating systems (e.g. Microsoft Windows) be installed besides Fedora on this Computer?"
  "No" -> install to MBR.
  "Yes" -> 2.

Help text for the question: 'Click "yes" if you are going to install, or have already installed, other operating systems on this computer. [warn that this is an advanced user task]'

2. "Will Fedora be the primary OS running no this system?"
  "Yes" -> install to MBR. Help text should explain that F19 is well capable of detecting and booting other OSes.
  "No" -> offer alternatives, including chainloading. In this case the user ought to have some idea about boot loaders, so little harm can be done.

Martin: no, that still doesn't really work. We handle dual-boot with Windows (and most other Linux distros) perfectly well by taking over the MBR and providing a Windows boot option. That's what most people tend to expect of a Linux distro. They don't expect to have to configure chained multiboot themselves.

And saying 'Will' means we're talking about the future...so a) you'd probably answer "no" if you *already* had other OSes, and b) if you were a 'normal' person who was planning to try Ubuntu after Fedora or something, answering 'yes' would result in us giving you what was to all appearances a non-functional system. It's the 'shoot yourself in the foot' button, only worse.

See? UX design really isn't easy =)

(In reply to Adam Williamson from comment #127)
> Martin: no, that still doesn't really work. We handle dual-boot with Windows
> (and most other Linux distros) perfectly well by taking over the MBR and
> providing a Windows boot option.

I agree with you in the Win+Fedora case. In other, non-trivial cases, taking over the MBR isn't necessarily the preferred option. 

> That's what most people tend to expect of a
> Linux distro. They don't expect to have to configure chained multiboot
> themselves.

I may not be a representative user, but what I expect from a Linux distro (based on experience built up over the last years) is a default installation in the MBR, plus an "advanced bootloader options" menu that allows me to tweak it to my needs.

> See? UX design really isn't easy =)
It sure isn't, and I am bad at it as I just demonstrated. But I am sure the Fedora UI team has people that could come up with a reasonable solution for an "advanced boot loader options" dialog. I understand that this comes at a cost, and that you need to evaluate the cost/benefit relationship.

Personally, I can live with a manual "grub-install --force" from the shell. I wonder if that could be done in kickstart installations, too.

"But I am sure the Fedora UI team has people that could come up with a reasonable solution for an "advanced boot loader options" dialog."

Your confidence is gratifying but possibly misplaced =) Like I said, we spent like a week trying to do exactly that and never came up with anything that made everyone happy.

"Personally, I can live with a manual "grub-install --force" from the shell. I wonder if that could be done in kickstart installations, too."

I think it should be possible. There is a generic %post section in kickstarts where you can insert arbitrary commands to be run following the installation process.

So I've got this far, read all the comments and the installation guide for Fedora 19, and used everyones' favourite search engine, but I still can't answer the question: how do I dual boot Fedora 19 and a TPM-enabled, Bitlockered Windows installation?

Currently (Fedora 16) I use the Windows bootloader to optionally chainload grub legacy. If booting Windows, it boots via the TPM-validated Windows boot sequence and I don't have to enter the Bitlocker recovery key.

If I understand the comments above, I can:
a) Create a BTRFS partition for /boot (e.g. /dev/sda5)
b) Install Fedora 19 via Anaconda, but explicitly "not install a bootloader"
c) Before rebooting run: "chroot /mnt/sysimage; grub2-install /dev/sda5". This shouldn't complain because BTRFS has support for immovable boot image.

Unfortunately, I can't test TPM in a virtual machine...

Any help appreciated,
Simon

*** Bug 876434 has been marked as a duplicate of this bug. ***

Simon: that sounds about correct. You may also need to do 'grub2-mkconfig' manually at the same time.

(In reply to Simon from comment #130)
Or you can use ext4 and use grub2-install --force. Or you can use a netinst image with kernel command line extlinux, which will use extlinux instead of grub. Exlinux installs to a partition/filesystem by design.

'extlinux' will only work on a network install, note.

(In reply to Chris Murphy from comment #133)
> (In reply to Simon from comment #130)
> Or you can use ext4 and use grub2-install --force.
I was trying to follow your advice from comment 19 and comment 46 and avoid such "fragile" workarounds. Once you have your eyes opened as to how dangerous something is, it's a bit hard to shut them tight and pray!

> Or you can use a netinst
> image with kernel command line extlinux, which will use extlinux instead of
> grub. Exlinux installs to a partition/filesystem by design.
I have actually tried this, with no success. I probably need to file another bug report, but I could neither get the "bootloader --extlinux" kickstart option nor the Anaconda "extlinux" command line to work; I think it had something to do with the fact that in both cases, I had to select the "Installation Destination" spoke in Anaconda rather than a default "blank disk" configuration. This seems to install grub to the MBR regardless and then fail to load grub stage2 files...

IMHO, this is a significant problem for Fedora. I would not expect any Linux distro to force a choice between (a) overwriting the MBR or (b) using a unstable, non-production filesytem (BTRFS), command line access to the installer text console AND error-prone typed-in grub commands (which incidentally don't correctly create GRUB_CMDLINE_LINUX or /etc/default/grub - see bug 886502)

As for:
> Considering how maybe a dozen people in prerelease testing wanted to install
> GRUB into a partition ran into this problem
is it not likely that these days most testing is done via a virtual machine? And who dual boots a virtual machine?

Rightly or wrongly, I have been accustomed to installing my distros' boot loaders to their /boot partition (via a nice GUI) and then just chainloading them from whatever previous MBR loader existed: Windows (via EasyBCD), legacy grub from other Linux distro, etc..

Is this just a "Grub2" problem? How do grub-legacy and Extlinux avoid ext[2-4] trampling on their "block lists"?

(In reply to Simon from comment #135)
> Is this just a "Grub2" problem? How do grub-legacy and Extlinux avoid
> ext[2-4] trampling on their "block lists"?

It's a generic problem, but grub2 is more exposed because its code is bigger, and "core.img" is dynamically generated.

(In reply to Martin Wilck from comment #136) 
> It's a generic problem, but grub2 is more exposed because its code is
> bigger, and "core.img" is dynamically generated.

So is there a generic solution for BIOS-based booting? Could I not just create small, unformatted (extended) partitions for each boot loader and have each loader write its stage 2 image at "block 0" of that unformatted partition?

(In reply to Simon from comment #137)
> So is there a generic solution for BIOS-based booting? Could I not just
> create small, unformatted (extended) partitions for each boot loader and
> have each loader write its stage 2 image at "block 0" of that unformatted
> partition?

This would be possible, yes. You can also use btrfs partitions. Or even extX, if you are ready to bear the risk described in comment #115. That's what I do.
Btw, stage 2 is not the problem - only "stage1" needs to be loaded via blocklist.

(In reply to Simon from comment #135)
...
> > Or you can use a netinst
> > image with kernel command line extlinux, which will use extlinux instead of
> > grub. Exlinux installs to a partition/filesystem by design.
> I have actually tried this, with no success. I probably need to file another
> bug report, but I could neither get the "bootloader --extlinux" kickstart
> option nor the Anaconda "extlinux" command line to work; I think it had
> something to do with the fact that in both cases, I had to select the
> "Installation Destination" spoke in Anaconda rather than a default "blank
> disk" configuration. This seems to install grub to the MBR regardless and
> then fail to load grub stage2 files...
...

I think I may have reproduced this in a VM by first doing a grub2-based minimal install and then doing an extlinux-based minimal install with /boot reformatted.

Booting fails with:
error: file '/grub2/i386-pc/normal.mod' not found.
Entering rescue mode...
grub rescue>

Could you open a new bug with your steps to reproduce and any error messages?

(In reply to Steve Tyler from comment #139)
> Booting fails with:
> error: file '/grub2/i386-pc/normal.mod' not found.
> Entering rescue mode...
> grub rescue>
> 
> Could you open a new bug with your steps to reproduce and any error messages?

Please cc me on the new bug, and please post program.log and storage.log.

The error sounds like grub code is still in the MBR, which loads the core.img still in the MBR gap syslinux mbr.bin file overwriting the first 440 bytes of LBA 0.

(In reply to Simon from comment #135)
> (In reply to Chris Murphy from comment #133)
> > (In reply to Simon from comment #130)
> I have actually tried this, with no success. I probably need to file another
> bug report, but I could neither get the "bootloader --extlinux" kickstart
> option nor the Anaconda "extlinux" command line to work;

File a bug, attach logs.


> IMHO, this is a significant problem for Fedora. I would not expect any Linux
> distro to force a choice between (a) overwriting the MBR or (b) using a
> unstable, non-production filesytem (BTRFS)

The only options are to overwrite the MBR code, or to not install a bootloader. Option B isn't an actual choice the installer supports, because there's no GUI to choose to install grub to a partition regardless of the file system. You can do this manually post install, or with kickstart, however, and if the fs is btrfs you don't need to use --force, whereas with ext3/4 you do.

Not in comment 133 I mention you need to use netinst for extlinux. It doesn't work with DVD or Live media.

Hidden extlinux install option works only with network install 
https://fedoraproject.org/wiki/Common_F19_bugs#Hidden_extlinux_install_option_works_only_with_network_install

"Could I not just create small, unformatted (extended) partitions for each boot loader and have each loader write its stage 2 image at "block 0" of that unformatted partition?"

Congratulations, you have just re-invented the BIOS boot partition!

https://en.wikipedia.org/wiki/BIOS_Boot_partition

:)

(In reply to Simon from comment #137) 
> So is there a generic solution for BIOS-based booting?

Yes. Allow current grub2 to take over the MBR and MBR gap, and have it point to a grub.cfg that uses configfile and legacy_configfile to point to the distribution specific grub.cfg and grub.conf, which in turn are kept up to date with kernel changes by the utilities used by those distributions.

> Could I not just
> create small, unformatted (extended) partitions for each boot loader and
> have each loader write its stage 2 image at "block 0" of that unformatted
> partition?

Grub doesn't install to unformatted partitions on MBR disks, presently. But even if it had something like the GPT BIOS Boot partition, there'd still only be one of these per disk. The MBR boot strap code in LBA 0 only points to one location if it's grub based. So I don't understand what this gains you over just settling on having the distro with the newest grub2 install grub2 normally to the MBR and MBR gap, pointing to a grub.cfg that contains configfile and legacy_configfile entries for your other distributions' grub.cfg or conf files. That way those distributions maintain their own correct grub.cfg/conf entries, no distro modifies any other distro's grub files. And you don't have to chainload from one grub to another either.

You can implement Chris' approach by adding entries to /etc/grub.d/40_custom. Getting the syntax and partition references right takes some experimenting, but an existing /boot/grub2/grub.cfg provides examples. After editing 40_custom, run:
grub2-mkconfig -o /boot/grub2/grub.cfg.
Reboot.

grub2 documentation:
http://www.gnu.org/software/grub/manual/

grub2 can search for file system labels, and that is what this example uses:

# cat /etc/grub.d/40_custom 
#!/bin/sh
exec tail -n +3 $0
# This file provides an easy way to add custom menu entries.  Simply type the
# menu entries you want to add after this comment.  Be careful not to change
# the 'exec tail' line above.
menuentry 'fir' {
        insmod part_gpt
        insmod ext2
        #set root='hd1,gpt2'
        search --no-floppy --label --set=root fir_boot
        configfile /grub2/grub.cfg
}

(In reply to Chris Murphy from comment #144)
> on having the distro with the newest grub2 install
> grub2 normally to the MBR and MBR gap, pointing to a grub.cfg that contains
> configfile and legacy_configfile entries for your other distributions'
> grub.cfg or conf files. That way those distributions maintain their own
> correct grub.cfg/conf entries, no distro modifies any other distro's grub
> files. And you don't have to chainload from one grub to another either.

I think I'm confused. Each newest distribution's Grub2 replaces the last newest's MB track? How do you propose they handle the next update round from the previous newest or the one before that or the one before that that overwrites the MB track because when installed it "owned" the MB track? Multiboot means more than one installed operating system, up to at least 62 per HD on MBR systems last I checked, not all of which are necessarily startable in absence of legacy-compatible MBR code.

(In reply to Felix Miata from comment #146)
>Each newest distribution's Grub2 replaces the last newest's MB track?

Nope. The way I worded it is confusing. For a given list of distributions, only one of them will have a GRUB closest to upstream, that's the GRUB to use. e.g. Fedora's is usually the closest, so what you do is install it last so that its GRUB is the one that's being loaded, and its grub.cfg has the 40_custom additions to point to other distributions.

Otherwise, if other distributions with older GRUB versions must be installed after Fedora than a.) choose not to install a bootloader for those distributions; or b.) probably safer is to let them install GRUB to a partition. The purpose of b. is that it'll at least still create the grub.cfg, whereas option a might not (on Fedora, if you don't install a bootloader, you also don't get a grub.cfg), while also installing GRUB boot.img and core.img in a benign way, they won't be used at all anyway if you're using configfile and legacy_configfile.

When any distribution does updates, they only update the grub package. As far as I know, no distribution then also calls that updated package's grub-install to reinstall GRUB to the MBR and MBR gap. The only thing they update related to GRUB is the grub.cfg if there's been a kernel update.

>Multiboot means more than one installed operating system, up to at least 62 per >HD on MBR systems last I checked, not all of which are necessarily startable in >absence of legacy-compatible MBR code.

You do not need GRUB legacy to boot a distribution that uses GRUB legacy. The latest version of GRUB2 will read GRUB legacy grub.conf files using the legacy_configfile command. So it uses the exact same grub.conf entries GRUB legacy would use. It just doesn't use GRUB2 to chainload GRUB legacy to read a legacy file to boot linux (which is rather Rube Goldbergish).

(In reply to Chris Murphy from comment #147)
> GRUB2 will read GRUB legacy grub.conf files using the
> legacy_configfile command. So it uses the exact same grub.conf entries GRUB
> legacy would use.

Only Fedora and its derivatives' Grub Legacy use a /boot/grub/grub.conf. The standard boot menu file for others' Grub Legacy uses menu.lst, which is MSDOS 8.3-only filesystem compatible and interchangeable with Grub for DOS.

I still don't think you fully comprehend what multiboot encompasses or can be or is used for. .e.g

example BIOS system 1:
single HD
IBM MBR code
boot track empty except for MBR and last sector used by IBM BM
sda1: IBM or MS-DOS 6.x installed on FAT16 (not VFAT; for DOS apps not compatible with any VM)
sda2: IBM Boot Manager on sda3 (set "active")
sda3: EXT2 hosting some variety of Gru*
sda5: FAT16 (not VFAT; for DOS apps not compatible with any VM)
sda6: type 0x82
sda7: EXTx hosting some variety of Gru*
sda8: HPFS eComStation 1.2 OS (not startable via Gru*; for apps unavailable on other operating systems)
sda9: HPFS apps
sda10: HPFS data
sda11: EXTx for /home
sda12: EXTx for /usr/local
sda13: EXTx for /srv
sda14: EXTx hosting some variety of Gru* and used for some distro's /
sda15: EXTx hosting some variety of Gru* and used for some distro's /
sda16: EXTx hosting some variety of Gru* and used for some distro's /
sda17: EXTx hosting some variety of Gru* and used for some distro's /
sda18: EXTx hosting some variety of Gru* and used for some distro's /
sda19: EXTx hosting some variety of Gru* target for F19 /
sda20: EXTx hosting some variety of Gru* and reserved for next new distro's /
sda21: EXTx hosting some variety of Gru* and reserved for next new distro's /
sda22: EXTx hosting some variety of Gru* and reserved for next new distro's /
sda23: EXTx hosting some variety of Gru* and reserved for next new distro's /
sda24: EXTx hosting some variety of Gru* and reserved for next new distro's /

Notes:
A: first 13 partitions were configured 5 or more years ago.
B: next 4 partitions were configured in ensuing years
C: it's time now to put F19 on sda19
D: next year another Linux will be put on sda20, 2nd next year another Linux will be put on sda21, etc.
E: Supposedly Grub can start IBM BM same as it chainloads NTLDR or other Grubs. This IBM BM, as updated and refreshed several times, as others, has demonstrated inability to function correctly unless set "active" and loaded directly by IBM legacy-compatible BIOS code.
F: Several OS/2 (eComStation) and DOS apps have demonstrated inability to function as required in any VM
G: Owner requires use of software that is not available or up to task running in DOS or OS/2, and other software that is no longer maintained, thus not available for newer distro verions, consequently requiring keeping old distros installed and working.
H: hardware is fully functional and adequate to required tasks
I: adding a computer, or replacing existing, is logistically impossible

What do you tell this owner to do?

My guess: sorry, Fedora cannot support your configuration via standard installation process, mainly due to Grub2 developers' decree, even though other Linux distros can, and Fedora used to be able to. Please find and use our special semi-secret installation process that substitutes another bootloader for Grub2.

example BIOS system 2: (only differences from above example listed)
system is 2 years old instead of >5
single HD
MBR code is AiR-Boot compatible
Boot track hosts AiR-Boot (master boot loader used for booting eCS 2.2, which is not bootable via Gru*, and loading PBRs of Linux native and FAT partitions)
sda1 hosts both DOS and functions as C: for NTLDR
sda2 no longer utilized for booting
sda8 has eComStation 2.2 instead of 1.2
sda14 NTFS hosts WinXP
sda15 NTFS for Windows data

What do you tell this owner to do?

My guess for this example is ditto the first.

This bug's handling is not behavior I consider worthy of an industry leader.

(In reply to Felix Miata from comment #148)
...
> I still don't think you fully comprehend what multiboot encompasses or can
> be or is used for. .e.g
...

Thanks, Felix. That's very interesting, but I don't understand how your client is using this, ummh, hodgepodge. Are all those partitions being used for legacy, production applications? What are you going to do when you have filled sda24? My initial thought is to refactor -- separate out the grub2 compatible stuff, the VM compatible stuff, and the IBM BM compatible stuff onto different disk drives or different computers ...

Disclaimer: IT consulting is not my specialty.

(In reply to Felix Miata from comment #148)
>The
> standard boot menu file for others' Grub Legacy uses menu.lst, which is
> MSDOS 8.3-only filesystem compatible and interchangeable with Grub for DOS.

legacy_configfile reads menu.lst.


> What do you tell this owner to do?

I've already recommended the anaconda team still create /etc/default/grub even if the install bootloader option isn't checked. That work hasn't been done. Other than that somewhat inconsequential file the recommendation is: a.) uncheck the option to install the bootloader in the installer, b.) use grub2-install --force /dev/sdXY to force installation to an ext formatted partition post install.

Anyone who can manage a rat's nest partitioned drive as the example can certainly accommodate running grub2-install --force themselves.


> My guess: sorry, Fedora cannot support your configuration via standard
> installation process, mainly due to Grub2 developers' decree, even though
> other Linux distros can, and Fedora used to be able to.

I don't speak for the project or the anaconda team. But to me, it makes negative sense for the overwhelmingly redhat anaconda team, to spend limited resources on producing what I think amounts to supporting the extremely unusual use cases of about a dozen people who are running weird ancient junk. And even if I'm wrong by an order of magnitude, it's more reasonable for 120 people to be relegated to using --force with manual installation of grub, than for 50 people on the redhat anaconda team and Fedora QA and docs team to create, support, and document something for 120 people.

There's no benefit at all for RHEL, or the overwhelming majority of Fedora users, and a high risk of a crummy experience for the majority in making the accommodation.


> Please find and use
> our special semi-secret installation process that substitutes another
> bootloader for Grub2.

It is not at all semi-secret. The grub2-install command itself will tell you the flag that needs to be used to forcibly install to an ext partition if you omit the flag when manually installing it to a partition. I find it inexplicable someone who manages a single drive with 23 f'n partitions can't cope with the manual installation of grub. Despite all of my whining about grub2 from 2 years ago I'm Joan of Arc in comparison.


> 
> example BIOS system 2: (only differences from above example listed)
> system is 2 years old instead of >5
> single HD
> MBR code is AiR-Boot compatible
> Boot track hosts AiR-Boot (master boot loader used for booting eCS 2.2,
> which is not bootable via Gru*, and loading PBRs of Linux native and FAT
> partitions)
> sda1 hosts both DOS and functions as C: for NTLDR
> sda2 no longer utilized for booting
> sda8 has eComStation 2.2 instead of 1.2
> sda14 NTFS hosts WinXP
> sda15 NTFS for Windows data
> 
> What do you tell this owner to do?

You appear to have mutually exclusive boot requirements for this system. Good luck with that. 

If eCS 2.2 can boot linux, use that instead of grub. If eCS can't boot linux, are you bitching to them about their lack of linux support? If not, you're not being consistent with your criticisms.


> 
> This bug's handling is not behavior I consider worthy of an industry leader.

It's an asinine comment. What you want is for many someones, who each could give 2 sh|ts about the ridiculous, non-professional, act of curiosity and/or desperation use case examples you've presented, to write a lot of code and do testing so you can get what you want in a GUI. You're just being lazy. grub2-install --force post-install still works and does exactly what you need.

This bug could be a good example for a bugzilla feature to set bug status to "encased". As in, encased in cement, no further comments can be added.


(In reply to Steve Tyler from comment #149)
> My initial thought is to refactor -- separate out the grub2
> compatible stuff, the VM compatible stuff, and the IBM BM compatible stuff
> onto different disk drives or different computers ...
> 
> Disclaimer: IT consulting is not my specialty.

And nevertheless you're coming up with a rational and sensible approach to this, rather than more absurdity. 

Maybe what's needed are more bowling balls, and add a fire extinguisher. I also forgot to inquire if the mouse has recently been fed and watered (via parachute and FedEx respectively of course).

http://etidweb.tamu.edu/RubeGoldberg.html

(In reply to Chris Murphy from comment #150)
> Anyone who can manage a rat's nest partitioned drive as the example can

I have more HDs with more than 24 partitions than I can count on ten fingers, some with more than 40.

> certainly accommodate running grub2-install --force themselves.

Or a better alternative. The special semi-secret comment was a reference to extlinux and the need to netboot to access its installation specially. 
 
> And even if I'm wrong by an order of magnitude, it's more reasonable
> for 120 people to be relegated to using --force with manual installation of

What I find unreasonable is requiring anything like --force as a non-optional replacement for Grub Legacy, which is easily set up on any partition, without anything like forcing, via Grub's shell. 

  root (hd0,18)
  setup (hd0,18)

That's it. Grub Legacy's ready to be chainloaded to by any minimally competent master bootloader wherever located.

> I find it
> inexplicable someone who manages a single drive with 23 f'n partitions can't
> cope with the manual installation of grub.
 
Not cannot. Will not. I manage just fine by choosing the install no bootloader option. I cannot any more recommend such an option to others than I can Grub2. I find both unsatisfactory for most recommendation scenarios.

Grub2 is complex bloatware, better for some cases, counter-KISS for more common cases, no matter how simple upstream claims it is to use. Anything that cannot be used like what it is designed and intended to supplant, without dire warning attempting to install in same location for same purpose as predecessor, or outright rejection of the attempt, is seriously more complicated from the relevant macro perspective.

> If eCS 2.2 can boot linux, use that instead of grub. If eCS can't boot
> linux, are you bitching to them about their lack of linux support? If not,
> you're not being consistent with your criticisms.
 
eCS can boot Linux via chainload principal, as long as the Linux distro isn't demanding its personal bootloader, unlike others that do not do so, usurp disk space from without its operating requirement for / and whatever else may be intentionally shared.

> What you want is for many someones, who each could
> give 2 sh|ts about the ridiculous, non-professional, act of curiosity and/or
> desperation use case examples you've presented, to write a lot of code and
> do testing so you can get what you want in a GUI.

What I want from it is the ability to do what old UI was content to do before: not require herculean effort to leave MB track unmolested. That shouldn't demand any more QA now than it did before whether for 4 partition systems or 24 or 44.

> This bug could be a good example for a bugzilla feature to set bug status to
> "encased". As in, encased in cement, no further comments can be added.

Result: Newly aghast at untraditional inflexibility file new bugs.

(In reply to Steve Tyler from comment #149)
> I don't understand how your
> client is using this, ummh, hodgepodge. Are all those partitions being used
> for legacy, production applications? What are you going to do when you have
> filled sda24? 

Those illustrations are not about who needs what for what reason. Choices have been made, but not without cost. To a minor extent, it's about ecological cost of inducing replacement of fully functional hardware. Next it's about satisfying only what the majority needs, as if all the various minorities should somehow be able to join the majority and reduce developer and QA workload indicated to address minority needs. No gummint is making us build wheelchair ramps and accessibly wide doors, and M$ & Apple aren't doing it themselves, so let's not us do it. Far more it's about a broader cost of reducing traditional FOSS adaptability and flexibility for the apparent primary purpose of getting new releases through alpha and beta to GA more easily and quickly.

Whoa, this is getting ugly.

As someone who has used Linux for over 20 years, I can honestly say bootloader problems have been the single biggest obstacle to installing Linux on anything but dedicated hardware. I would imagine that helping users set up dual boot Windows and Linux should be a priority for companies such as Red Hat if they want to see wider adoption of their OS.

Obviously this is a technically challenging area; I been bitten by Fedora bugs such as bug 537155 in the past (leaving my Windows machine unbootable) and by Windows intransigence (overwrites MBR upon install, regardless of other OS). 

As it stands, however, there's absolutely no way I could recommend to a "normal" computer user that they should dual boot Linux. What if they have UEFI, not BIOS? What if they "Turned on Bitlocker" in Windows? What if they clicked their way through the Truecrypt GUI? What if they were adventurous and had already installed a Linux distro?

My point is that it makes a *great deal of sense* for the Anaconda team to spend what limited resource is available on ensuring that the dual or multiple booting is perceived as "easy" for the user. Yes, in an ideal world, Windows wouldn't be pre-installed and consume the whole drive. In reality, you do what every other business has to do when seeking adoption: make it easier for your client to transition.

At the very least, some clear, easy-to-find instructions would be great. See e.g. https://help.ubuntu.com/community/WindowsDualBoot#Master_Boot_Record_and_Boot_Manager

Simon: we do support dual booting. Indeed, it is explicitly in our release criteria. Dual booting with Windows works just fine with Fedora 19. With BIOS, and with UEFI.

(In reply to Felix Miata from comment #151)
> What I find unreasonable is requiring anything like --force as a
> non-optional replacement for Grub Legacy ...

It's one flag. You're making a mountain out of a mole hill, epitome of unreason.

> ... which is easily set up on any partition, without anything like forcing, via
> Grub's shell. 

Nothing stops you from using GRUB legacy, if that's what you prefer.

> What I want from it is the ability to do what old UI was content to do
> before: not require herculean effort to leave MB track unmolested.

This is just a broken record. You want Y. Maintainers don't want to redesign, rebuild, and test Y. I think the logic of continuing to repeat merely that which is wanted is pointless.

A whole new line of the conversation would be to propose a Fedora feature, outline all the work that needs to be done, and who will do it, what the liabilities are, etc. Then see if the anaconda team would go for it, and then get Fesco to sign off on it. But right now, I see one person who's willing to write some code for ext4 to support a bootloader specific inode. That's it. No one has stepped up to write grub or anaconda patches.


> That
> shouldn't demand any more QA now than it did before whether for 4 partition
> systems or 24 or 44.

Right. So in this hypothetical Fedora feature write up, you can point out that you'll QA it yourself, and as the code will only be triggered optionally with a kernel parameter, regressions aren't expected for the overwhelming majority.

I strongly suspect once you actually find out how much work is involved to do what you want, you'll be VERY content to just use --force. Or, perhaps, you'll just keep repeating that you want other people to do this work for you, while they have zero interest or stake in it.

(In reply to Simon from comment #153)
> As someone who has used Linux for over 20 years, I can honestly say
> bootloader problems have been the single biggest obstacle to installing
> Linux on anything but dedicated hardware.

I think that applies with all OS's, not just linux. Booting is non-trivial, as it turns out. And BIOS/MBR isn't particularly well designed (or consistently designed) for multibooting. So you're stuck having to load something much more capable than BIOS, to achieve multibooting.

> I would imagine that helping users
> set up dual boot Windows and Linux should be a priority for companies such
> as Red Hat if they want to see wider adoption of their OS.

That is already true for Fedora, has been for some time. I've tested this many times and filed bugs during alpha and beta testing to make sure it works, as have many other people in the community.


> As it stands, however, there's absolutely no way I could recommend to a
> "normal" computer user that they should dual boot Linux. What if they have
> UEFI, not BIOS? What if they "Turned on Bitlocker" in Windows? What if they
> clicked their way through the Truecrypt GUI? What if they were adventurous
> and had already installed a Linux distro?

Hence this proposal:
http://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/

The case for preexisting Windows or OS X that happen to be encrypted is likely a show stopper when it comes to resizing. How to get GRUB to point to the right location to boot those systems, though (chainloading or multiboot) I think would be useful.

(In reply to Chris Murphy from comment #150)
> I've already recommended the anaconda team still create /etc/default/grub
> even if the install bootloader option isn't checked.

In my opinion this would be a good first step. It would help me personally very much.

> It is not at all semi-secret. The grub2-install command itself will tell you
> the flag that needs to be used to forcibly install to an ext partition if
> you omit the flag when manually installing it to a partition.

To make everyone as happy as possible, I suggest adding a note to the boot option in anaconda also. It could be something like 'If you do not wish to install GRUB2 automatically, you can run its setup manually using grub2-install after the installation has completed'.

(In reply to Daniel L. from comment #156)
I'd file an RFE against anaconda, version set to rawhide and make the proposal. Be clear where the message would appear, when, and how it would read.

I'd suggest that it appears in the existing warning that you're not installing a bootloader. This is a bit circuitous to get the message you want, but I think it's more likely to be accepted because it means essentially no UI changes.

To see what I mean, run the installer, go to the link for disk options, deselect the bootloader option for the disk, finish all of your other installation destination options and get back to the main hub. You'll find a warning for Installation Destination, and if you click on it to return to Installation Destination there will be a banner at the bottom of the screen indicating you'll get more information if you click on it. If you click on it you'll get a dialog that says something like, you're not installing a bootloader this computer may not be bootable.

So I'm suggesting adding what you want on the end of that warning. Not difficult to add, and not a bad idea.

(In reply to Daniel L. from comment #156)
And somewhere the RFE for the create grub files but do not install the bootloader was lost during F18 and F19, so it might be worthwhile to file a new one against rawhide that's really clear. The basic proposal is:

If bootloader option is unchecked, run:
grub2-install --grub-setup=/bin/true /dev/sdX

instead of not running grub2-install, or grub2-mkconfig, or creating /etc/default/grub..

The flag is telling grub-install to merely run grub-setup, so all the mods get created, core.img is created (and thus it can be chainloaded or multibooted if your initials are R.G.); but it doesn't write to either the MBR or the MBR gap. I sound like I know what I'm talking about but I'd still test it before making the RFE.

(In reply to Chris Murphy from comment #155)
> I strongly suspect once you actually find out how much work is involved to
> do what you want, you'll be VERY content to just use --force. Or, perhaps,
> you'll just keep repeating that you want other people to do this work for
> you, while they have zero interest or stake in it.

I'm not a programmer. Whatever work might be involved is mostly beyond my understanding. What I do think is the coders, drivers and formal testers forget that they don't do all the testing that needs doing. Making it harder for the informal testers to contribute means less testing gets done, and fewer problems outside formal testing specifications get discovered. This bug is one that does exactly that, making willing testers less willing to spend their time, able to spend less time, for no more reason than Anaconda devs don't want to be bothered to include a third bootloader option instead of just two, three choices being the least offered by other top distros, and IIRC, less than Fedoras previous to F18 offered.

This bug highlights Fedora position that the broader cost of reducing traditional FOSS adaptability and flexibility is willingly paid in order to serve the overriding goal of formal code, package and QA teams getting new releases through alpha and beta to GA as easily and quickly as possible.
 
> (In reply to Simon from comment #153)
> To make everyone as happy as possible, I suggest adding a note to the boot
> option in anaconda also. It could be something like 'If you do not wish to
> install GRUB2 automatically, you can run its setup manually using
> grub2-install after the installation has completed'.

To  make everyone as happy as practical, that wouldn't go far enough. No bootloader names need mention in primary UI, just maybe in help text, if at all. What Anaconda needs running on a multiboot BIOS system (and what this bug is about) is something equivalent to the following in its UI:

1[X]-Fedora will manage my system's startup, functioning as my primary or sole startup manager.
2[ ]-I like my existing startup arrangement, so Fedora should install no startup stuff outside the space specifically allocated to its normal operation.
3[ ]-I can handle startup without any help from the installer. Just install Fedora, and leave startup to me.

1 means put Grub2 on MBR.
2 means put Extlinux on /.
3 means put anything that needs to go on kernel cmdline somewhere user can find it. No form of Fedora-provided boot management is necessary.

"This bug is one that does exactly that, making willing testers less willing to spend their time, able to spend less time, for no more reason than Anaconda devs don't want to be bothered to include a third bootloader option instead of just two, three choices being the least offered by other top distros, and IIRC, less than Fedoras previous to F18 offered."

This is not at all true, and I cannot conclude any reason other than bad faith for your misrepresentation, given that all the other reasons are included in this comment thread.

"This bug highlights Fedora position that the broader cost of reducing traditional FOSS adaptability and flexibility is willingly paid in order to serve the overriding goal of formal code, package and QA teams getting new releases through alpha and beta to GA as easily and quickly as possible."

This is equally untrue, and an equally irresponsible misrepresentation. Please stop the soapboxing.

BTW, I don't think more than 15% of users (WAG, but somewhere in that range) would have a damn clue what any of the choices in your proposed UI mean.

(In reply to Adam Williamson from comment #161)
> BTW, I don't think more than 15% of users (WAG, but somewhere in that range)
> would have a damn clue what any of the choices in your proposed UI mean.

"Something equivalent to". Anyway, it shouldn't matter. #1 is preselected, could be presented in bolder, larger text, and selection of some other option can be accompanied by a warning akin to Grub2's sirens, flags and you'll be sorry for attempting to put it on a partition.

(In reply to Adam Williamson from comment #160)
> "This bug is one that does exactly that, making willing testers less willing
> to spend their time, able to spend less time, for no more reason than
> Anaconda devs don't want to be bothered to include a third bootloader option
> instead of just two, three choices being the least offered by other top
> distros, and IIRC, less than Fedoras previous to F18 offered."
> 
> This is not at all true, and I cannot conclude any reason other than bad
> faith for your misrepresentation, given that all the other reasons are
> included in this comment thread.

Seriously? The added complication not found in the competition means when the time is available to spend and I have a choice to spend it on Mageia or Fedora (or something else), knowing Fedora requires more post-installation cleanup or pre-installation prep because this is wontfix, you really think the impact is zero? There is much I'd rather test than OS installation, which I find to be a necessary evil, not a pleasure, and why I yum upgrade magnitudes more often than run Anaconda. In the past year, more than once, I've upgraded from as many as 4 versions back (IIRC) to get to latest or Rawhide on a system in order to avoid Anaconda newUI.

You really think there's no one who agrees with me? I'm confident there must be, and that no small % just don't do Fedora, or try briefly but then give up and spend their discretionary time contributing elsewhere.
 
> "This bug highlights Fedora position that the broader cost of reducing
> traditional FOSS adaptability and flexibility is willingly paid in order to
> serve the overriding goal of formal code, package and QA teams getting new
> releases through alpha and beta to GA as easily and quickly as possible."
 
> This is equally untrue, and an equally irresponsible misrepresentation.

IMO whether it is true or not doesn't matter as much as that the description seems fitting. As in other endeavors, being upstanding isn't enough. Appearing to be upstanding is equally important.

"you really think the impact is zero?"

No, what I am saying is untrue is:

"for no more reason than Anaconda devs don't want to be bothered to include a third bootloader option"

There are several 'more reasons'. You are just ignoring them.

(In reply to Adam Williamson from comment #164)
> There are several 'more reasons'. You are just ignoring them.

Maybe I inadvertently was in that comment, but clearly not in all my comments.

I have my suspicions that there's a powerful one that no one has mentioned either in this bug, or in related mailing list threads.

Why? Why is there always this bizarre impulse to conspiracy theorizing? No. There is no Secret Reason. The entire thing has been beaten to death in this thread.

(In reply to Felix Miata from comment #159)

> 2[ ]-I like my existing startup arrangement, so Fedora should install no
> startup stuff outside the space specifically allocated to its normal
> operation.

> 2 means put Extlinux on /.

Extlinux goes on /boot if it's a separate partition. This is possible with Fedora 19 netinst using the extlinux kernel parameter. It's not on the DVD or live media because there wasn't enough space for it, and once that was realized there wasn't enough time to figure out what should be dropped to make room. Keep in mind the extlinux option was for cloud/vm, not to solve the 'install to partition' request.

I don't know if specifying extlinux causes anaconda writes the syslinux mbr.bin to the MBR, and if so if there's a way to suppress it. I suspect it does because again the feature is for cloud/vm. So a.) UI code and translation would be needed to suppress this; or b.) backup your MBR and restore it post install. As precious as this MBR code appears to be, I'd guess you'd know how to do this considering how aggressive most OS's are about stomping on the MBR code.