Bug 886502 - create grub.cfg and /etc/default/grub even when not installing bootloader (BIOS installs)
create grub.cfg and /etc/default/grub even when not installing bootloader (BI...
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity high
: ---
: ---
Assigned To: Anaconda Maintenance Team
Fedora Extras Quality Assurance
:
: 893106 901373 1033550 (view as bug list)
Depends On: 885240
Blocks:
  Show dependency treegraph
 
Reported: 2012-12-12 07:56 EST by Eric Blake
Modified: 2015-02-03 21:33 EST (History)
28 users (show)

See Also:
Fixed In Version: anaconda-22.9-1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 885240
Environment:
Last Closed: 2014-12-09 12:04:47 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Eric Blake 2012-12-12 07:56:32 EST
When the user selects to not install grub into the MBR, anaconda should still use:

grub2-install --grub-setup=/bin/true

and grub2-mkconfig so that there is at least a grub.cfg file created that can then be loaded by a pre-existing grub2 in the MBR using 'configfile' command.

+++ This bug was initially created as a clone of Bug #885240 +++

> > <snip>
> > 
> > 2. No grub.cfg is being created now, and it would be nice if it still would
> > for those users who will point another grub to the Fedora grub.cfg. Makes it
> > that much easier for them to get a booting Fedora.
> 
> 
> Yes! Please!  Without it you can work around it, but it is a real PITA.

Indeed, the request to create a grub.cfg so that some other grub can point to it is also made in bug 872826.  Honoring the option to avoid installing the bootloader onto MBR or the file system gap is a good thing, but crippling the user by not even creating grub.conf is unfriendly.

--- Additional comment from David Lehman on 2012-12-10 08:53:01 MST ---

(In reply to comment #19)
> the bootloader onto MBR or the file system gap is a good thing, but
> crippling the user by not even creating grub.conf is unfriendly.

grub2-mkconfig often _fails_ to run if you haven't first run grub2-install, which we of course cannot do in your case.

--- Additional comment from Chris Murphy on 2012-12-10 12:00:19 MST ---

(In reply to comment #26)
> grub2-mkconfig often _fails_ to run if you haven't first run grub2-install,
> which we of course cannot do in your case.

Are you sure the dependency is on grub2-install, and not grub2-mkimage? Grub2-mkimage installs the modules to /boot/grub2 and produce the custom core.img, but without touching the MBR or MBR gap. I think all grub2-mkconfig may want is core.img.

--- Additional comment from David Lehman on 2012-12-10 12:29:25 MST ---

(In reply to comment #27)
> (In reply to comment #26)
> > grub2-mkconfig often _fails_ to run if you haven't first run grub2-install,
> > which we of course cannot do in your case.
> 
> Are you sure the dependency is on grub2-install, and not grub2-mkimage?
> Grub2-mkimage installs the modules to /boot/grub2 and produce the custom
> core.img, but without touching the MBR or MBR gap. I think all
> grub2-mkconfig may want is core.img.

I'm not sure at all, but what you're talking about is definitely a new feature rather than "don't cripple ...". It would require new code, testing, &c just for this specific case, which I frankly don't consider anywhere near important enough given my current workload.

You folks are welcome to write and test patches, then then send via git-send-email to anaconda-patches@lists.fedorahosted.org for review/inclusion.

--- Additional comment from Steve Tyler on 2012-12-10 12:43:27 MST ---

This bug is about grub being installed when it should not be. It would be better to open a new bug requesting a new feature.

WRT this bug: The hexdump in Attachment 659695 [details] does not show any evidence of grub being installed:
1. The string "GRUB" does not appear in the first sector.
2. The first sector does not begin with "eb 63 90".

--- Additional comment from Chris Murphy on 2012-12-10 12:59:05 MST ---

(In reply to comment #29)
anaconda 18.37-1 appears to fix this bug, although parted applies some sort of goober in the first 80 bytes of LBA 0 which may be a separate bug. These 80 bytes cause the system to hang, rather than skip over the disk if the boot loader region had contains zeros as it did before installation.

This could make some systems unbootable, the opposite intention of the anaconda feature to not install a boot loader.

--- Additional comment from Adam Williamson on 2012-12-10 13:29:56 MST ---

Discussed at 2012-12-10 blocker review meeting: http://meetbot.fedoraproject.org/fedora-bugzappers/2012-12-10/f18final-blocker-review-3.2012-12-10-17.13.log.txt . Accepted as a blocker per criterion "The installer must be able to install into free space alongside an existing clean single-partition Windows installation and either install a bootloader which can boot into the Windows installation, or leave the Windows bootloader untouched and working" (second case).

Please, can you folks split the 'create a grub.cfg' and 'don't do mklabel' issues into separate reports? They are not what this bug is for, and things are getting confusing. This bug will be closed when an update that is confirmed not to install grub to the MBR is pushed. Thanks.

--- Additional comment from Steve Tyler on 2012-12-10 13:38:32 MST ---

Created attachment 661116 [details]
parted mbr.s boot loader assembly code

The "goober" is the parted boot loader: Comment 24.

--- Additional comment from Chris Murphy on 2012-12-11 19:29:33 MST ---

(In reply to comment #28)
> I'm not sure at all, but what you're talking about is definitely a new
> feature rather than "don't cripple ...".

On help-grub@ Mads Killerich concurs re: dependencies. To suppress just the embedding in the MBR and MBR gap he suggest this:

grub2-install --grub-setup=/bin/true

> It would require new code, testing,
> &c just for this specific case, which I frankly don't consider anywhere near
> important enough given my current workload.

I just tested it, and all mods and core.img are created, but does not write to the MBR or MBR gap. Using this suppression option would allow the call to grub2-mkconfig to remain intact. And also it seems less of a change needing much testing.

I'm thinking of this as a work around for those, myself not included, who are used to a long standing ability to embed GRUB in the Fedora boot partition, which is not going to happen in F18 (due to the use of block lists to make it work).

 
> You folks are welcome to write and test patches, then then send via
> git-send-email to anaconda-patches@lists.fedorahosted.org for
> review/inclusion.

If it can't happen for F18, fine, it's not a hill I'm going to die on, and I guess we'll see exactly how many people expect/want more assistance in making Fedora bootable when they also don't want to step on a current boot loader in the MBR.

--- Additional comment from Adam Williamson on 2012-12-11 22:54:43 MST ---

It certainly could happen for F18 if someone writes and submits a patch reasonably soon. But again, can we please have this in a separate report? Then we could propose that report as NTH.
Comment 1 Eric Blake 2012-12-12 08:00:40 EST
-1 blocker +1 NTH - I can't justify multi-boot OS using grub's 'configfile grub.cfg' or 'kernel core.img' to "chain-load" a grub image via any of the blocker criteria, but it sure seems like a simple request to make life easier for those that do want to chain-load in a manner that obeys upstream grub recommendations.
Comment 2 Chris Lumens 2012-12-12 11:45:49 EST
Does this one only have the AcceptedBlocker whiteboard because it was cloned from an existing AcceptedBlocker?  If, that should get blanked out until they've had time to do the meeting.
Comment 3 Eric Blake 2012-12-12 11:55:56 EST
(In reply to comment #2)
> Does this one only have the AcceptedBlocker whiteboard because it was cloned
> from an existing AcceptedBlocker?  If, that should get blanked out until
> they've had time to do the meeting.

Yes, looks like a cloning artifact.  I blanked the whiteboard so the meeting can discuss it properly.
Comment 4 Adam Williamson 2012-12-12 17:26:08 EST
-1 blocker, it clearly isn't. +1 NTH, this would be a useful thing to add, so long as we don't do it crazy late - AFAICS it can only break the 'not installing a bootloader at all' path, the code shouldn't be touched outside of that path.
Comment 5 Adam Williamson 2012-12-12 17:30:07 EST
Eric, if you want to write a patch for this, it shouldn't be too terribly hard. The code you need to look at is in pyanaconda/bootloader.py . Note there are 'classes' within this code for different bootloaders, make sure you poke the right one. You'd want to write the patch against origin/f18-branch branch - *not* master.

Chris, the 'discussed at 20XX-XX-XX blocker review meeting...' comments act as a 'check' on the blocker status - if a bug has AcceptedBlocker in whiteboard but no explicit comment explaining when it was discussed and that status was granted, you can assume the status is bogus.
Comment 6 Paul Franklin (RHlists) 2012-12-14 09:27:51 EST
+1 NTH

A useful addition for sophisticated users, especially
since I'll no longer be able to put the bootloader in
sector zero of the Fedora partition, as I have done for years.
Comment 7 Chris Murphy 2012-12-14 11:49:10 EST
(In reply to comment #6)
You can put a boot loader in sector 0 and 1 of an ext[234] partition, but GRUB can't fit in only 1024 bytes. Historically GRUB was forced into free space in the file system without its awareness, using block lists, and therefore GRUB could be clobbered at any time. You can still install it this way yourself, e.g. grub2-install --force /dev/sda1 for ext file systems. Force is proscribed for XFS and btrfs. Forcing is also unnecessary for btrfs since it has a sufficiently large (64KB) boot code region.
Comment 8 Eric Blake 2012-12-14 11:58:51 EST
(In reply to comment #7)
> (In reply to comment #6)
> You can put a boot loader in sector 0 and 1 of an ext[234] partition, but
> GRUB can't fit in only 1024 bytes. Historically GRUB was forced into free
> space in the file system without its awareness, using block lists, and
> therefore GRUB could be clobbered at any time. You can still install it this
> way yourself, e.g. grub2-install --force /dev/sda1 for ext file systems.
> Force is proscribed for XFS and btrfs. Forcing is also unnecessary for btrfs
> since it has a sufficiently large (64KB) boot code region.

But that information is unrelated to the point of this bug, which is about creating grub.cfg even when NOT installing grub into MBR or file system gaps.  That is, this bug exists so that we DON'T need to use grub2-install --force.
Comment 9 Mads Kiilerich 2012-12-16 19:20:04 EST
A couple of points that might or might not be tracked elsewhere:

It seems like everything discussed here is for BIOS. That should perhaps be written in big letters in the subject.

grub2 for BIOS on Fedora uses /boot/grub2/grub.cfg, but the standard fedora EFI grub uses /boot/efi/EFI/fedora/grub.cfg. It could thus be argued that both should be created if possible. There is no reason it shouldn't be easy to change between booting a Fedora installation both as BIOS and as EFI.

But also: Fedora will unfortunately install the "efi bootloader" directly in /boot/efi/EFI/fedora when the grub2-efi package is installed. There is thus no way to avoid installating a bootloader on EFI. Anaconda on EFI should thus perhaps not ask the question, and it could just as well always create this strange /boot/efi/EFI/fedora/grub.cfg. (And before that it should run a dummy grub2-install to populate /boot/grub2 correctly.)

And keep in mind that running grub2-install on an EFI system probably will do something completely different from what it does on a BIOS system.

I'm sorry that this didn't make it simpler, but I think it raised some valid points.
Comment 10 Adam Williamson 2012-12-17 12:04:39 EST
Discussed at 2012-12-17 blocker review meeting: http://meetbot.fedoraproject.org/fedora-bugzappers/2012-12-17/f18final-blocker-review-5.2012-12-17-16.40.log.txt . Rejected as a blocker, it clearly doesn't violate the release criteria, but accepted as NTH as this would be useful for multi-booters and cannot be fixed post-release.
Comment 11 Chris Murphy 2012-12-17 20:47:36 EST
(In reply to comment #9)
> grub2 for BIOS on Fedora uses /boot/grub2/grub.cfg, but the standard fedora
> EFI grub uses /boot/efi/EFI/fedora/grub.cfg. It could thus be argued that
> both should be created if possible. There is no reason it shouldn't be easy
> to change between booting a Fedora installation both as BIOS and as EFI.

Well except I think grub2-install fails if efibootmgr fails, which it does if the computer is BIOS mode boot. And grub2-mkconfig produces a rather different grub.cfg depending on whether the boot mode is BIOS vs UEFI.


> But also: Fedora will unfortunately install the "efi bootloader" directly in
> /boot/efi/EFI/fedora when the grub2-efi package is installed. There is thus
> no way to avoid installating a bootloader on EFI. Anaconda on EFI should
> thus perhaps not ask the question,

Agreed. Filed this as Bug 888106.
Comment 12 Chris Lumens 2013-01-18 10:27:06 EST
*** Bug 901373 has been marked as a duplicate of this bug. ***
Comment 13 Michel Alexandre Salim 2013-01-18 22:20:43 EST
Note that in addition to creating grub.cfg, /etc/default/grub also needs to be written -- the latter by Anaconda since grub doesn't create it and it contains Fedora-specific defaults.
Comment 14 Steve Tyler 2013-01-19 02:48:04 EST
FWIW, the anaconda code to write /etc/default/grub is here:
http://git.fedorahosted.org/cgit/anaconda.git/tree/pyanaconda/bootloader.py?id=anaconda-18.37.11-1#n1429
Comment 15 Adam Williamson 2013-01-24 19:03:09 EST
Bumping out to Rawhide, cleaning the blocker bureaucracy.
Comment 16 Daniel Laczi 2013-02-05 17:13:36 EST
It would be very helpful if anaconda created /etc/default/grub as there is no other possibility to generate that file automatically (as far as I know).

I've just installed Fedora 18 without installing GRUB2 and ran grub2-install and grub2mk-config manually on a live cd (via chroot). Creating /etc/default/grub by hand though was unfriendly.
Comment 17 Per Sjoholm 2013-02-05 17:30:45 EST
There is more to it, not just the files.

I installed grub afterwards and the machine didn't run firstboot.
It's doesn't start in graphical mode and graphical(gdm) starts ok manually.

I installed an other machine and got the same behavior. Re-installed with grub installed i (MBR) and then no problem.
Comment 18 Daniel Laczi 2013-02-05 17:58:07 EST
I've installed two system without installing GRUB. On the very first boot SELinux relabeled the filesystem on both systems. Afterwards both rebooted and ran into firstboot.
Comment 19 David Batson 2013-02-08 14:54:47 EST
(In reply to comment #16)
> It would be very helpful if anaconda created /etc/default/grub as there is
> no other possibility to generate that file automatically (as far as I know).
> 
> I've just installed Fedora 18 without installing GRUB2 and ran grub2-install
> and grub2mk-config manually on a live cd (via chroot). Creating
> /etc/default/grub by hand though was unfriendly.

Yes indeed!  I copied an existing /etc/default/grub from Arch installed on another partition, and edited that file accordingly.  Even so, I am not sure it is exactly as it should be.
Comment 20 Steve Tyler 2013-02-08 22:50:06 EST
For the record, /etc/default/grub is not necessarily required. A test in a VM shows that a default, Gnome desktop install boots fine without it.

Test procedure (using the F18 DVD):
Complete a default, Gnome desktop install (with bootloader install enabled).
Before rebooting, switch to the installer shell (ctrl-alt-f2).
# chroot /mnt/sysimage
# mv /etc/default/grub /etc/default/grub.BAK1
# grub2-mkconfig -o /boot/grub2/grub.cfg
# exit
# reboot

Tested with:
$ qemu-kvm -m 2048 -hda f18-test-3.img -cdrom ~/xfr/fedora/F18/Fedora-18-x86_64-DVD.iso -vga qxl -boot menu=on -usbdevice mouse
Comment 21 David Batson 2013-02-08 23:57:23 EST
(In reply to comment #20)
> For the record, /etc/default/grub is not necessarily required. A test in a
> VM shows that a default, Gnome desktop install boots fine without it.
> 
> Test procedure (using the F18 DVD):
> Complete a default, Gnome desktop install (with bootloader install enabled).
> Before rebooting, switch to the installer shell (ctrl-alt-f2).
> # chroot /mnt/sysimage
> # mv /etc/default/grub /etc/default/grub.BAK1
> # grub2-mkconfig -o /boot/grub2/grub.cfg
> # exit
> # reboot
> 
> Tested with:
> $ qemu-kvm -m 2048 -hda f18-test-3.img -cdrom
> ~/xfr/fedora/F18/Fedora-18-x86_64-DVD.iso -vga qxl -boot menu=on -usbdevice
> mouse

True, you can boot without /etc/default/grub but you lose a number of grub options such as disabling os-prober, grub hiddenmenu, default os boot, grub themes, etc.
Comment 22 Steve Tyler 2013-02-09 00:10:24 EST
For reference, here is /etc/default/grub after a default F18 install[1]:

GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT=saved
GRUB_CMDLINE_LINUX="rd.lvm.lv=fedora/swap rd.md=0 rd.dm=0 $([ -x /usr/sbin/rhcrashkernel-param ] && /usr/sbin/rhcrashkernel-param || :) rd.luks=0 vconsole.keymap=us rd.lvm.lv=fedora/root rhgb quiet"
GRUB_DISABLE_RECOVERY="true"
GRUB_THEME="/boot/grub2/themes/system/theme.txt"

The F18 anaconda code to write /etc/default/grub is here:
http://git.fedorahosted.org/cgit/anaconda.git/tree/pyanaconda/bootloader.py?id=anaconda-18.37.11-1#n1429

[1] Tested with:
$ qemu-kvm -m 2048 -hda f18-test-3.img -cdrom ~/xfr/fedora/F18/Fedora-18-x86_64-DVD.iso -vga qxl -boot menu=on -usbdevice mouse
Comment 23 Chris Murphy 2013-02-09 00:40:28 EST
I'm uncertain the theme.txt exists without grub2-install being run first. GRUB devs have said there are some dependencies on grub2-install being run before grub2-mkconfig.

Hence to fulfill the RFE for this bug, anaconda should do the same things it does when the (default) option to install boot loader is selected, except to add the flag --grub-setup=/bin/true when calling grub2-install. The only thing that does is suppress stomping on the MBR and MBR gap (or BIOS Boot). This way /etc/default/grub, core.img, all modules, themes, support files, and grub.cfg are still created and available.
Comment 24 Steve Tyler 2013-02-09 01:35:07 EST
(In reply to comment #23)
> I'm uncertain the theme.txt exists without grub2-install being run first.
> GRUB devs have said there are some dependencies on grub2-install being run
> before grub2-mkconfig.
...

Thanks for raising that issue.

1. The file "/boot/grub2/themes/system/theme.txt" exists after an F18 minimal install with bootloader installation disabled.[1]
2. The directory "/boot/grub2/themes/system/" contains 31 files, most of which are png and pf2 files.
3. No other directories under "/boot/grub2/" are populated.
4. grub2-mkconfig runs without error and writes "/boot/grub2/grub.cfg".[2]
5. Booting with "configfile /boot/grub2/grub.cfg" succeeds.

[1] Tested with:
$ qemu-kvm -m 2048 -hda f18-test-3.img -cdrom ~/xfr/fedora/F18/Fedora-18-x86_64-DVD.iso -vga qxl -boot menu=on -usbdevice mouse

[2] The grub2-mkconfig command was run after chrooting to "/mnt/sysimage" before rebooting from the installer.
Comment 25 Steve Tyler 2013-02-09 02:19:39 EST
(In reply to comment #24)
...
> 3. No other directories under "/boot/grub2/" are populated.
> 4. grub2-mkconfig runs without error and writes "/boot/grub2/grub.cfg".[2]
> 5. Booting with "configfile /boot/grub2/grub.cfg" succeeds.
...

Here is my test configuration:
sda1 /boot (Installation 1)
sda2 /     (Installation 1)
sda3 /     (Installation 2, which does not use a separate boot partition.)
sda4 swap

Installation 2 does not have any grub2 modules installed, yet it can be booted from sda1 using the grub2 "configfile" command, so the grub2 modules must be coming from the grub2 installation on sda1.

Tip: Set different time zones for the two installations, so they can be distinguished by running the date command after logging in.
Comment 26 David Batson 2013-02-09 07:47:05 EST
(In reply to comment #24)
> 1. The file "/boot/grub2/themes/system/theme.txt" exists after an F18
> minimal install with bootloader installation disabled.[1]
> 2. The directory "/boot/grub2/themes/system/" contains 31 files, most of
> which are png and pf2 files.
> 3. No other directories under "/boot/grub2/" are populated.
> 4. grub2-mkconfig runs without error and writes "/boot/grub2/grub.cfg".[2]
> 5. Booting with "configfile /boot/grub2/grub.cfg" succeeds.
> 
> [1] Tested with:
> $ qemu-kvm -m 2048 -hda f18-test-3.img -cdrom
> ~/xfr/fedora/F18/Fedora-18-x86_64-DVD.iso -vga qxl -boot menu=on -usbdevice
> mouse
> 
> [2] The grub2-mkconfig command was run after chrooting to "/mnt/sysimage"
> before rebooting from the installer.

Same here *except* #3. All my directories under /boot/grub2/ are populated.  Used the Fedora-18-x86_64-DVD.iso to install Fedora.

One difference, I booted the DVD again in rescue mode to run grub2-mkconfig.
Comment 27 Steve Tyler 2013-02-09 09:24:43 EST
(In reply to comment #26)
...
> > 3. No other directories under "/boot/grub2/" are populated.
...
> Same here *except* #3. All my directories under /boot/grub2/ are populated. 
> Used the Fedora-18-x86_64-DVD.iso to install Fedora.
> 
> One difference, I booted the DVD again in rescue mode to run grub2-mkconfig.

Thanks for your comments.

Item 3 in Comment 24 is referring to the configuration of Installation 2, which does not have a bootloader installed. That was not clear in Comment 24; sorry about that.

Confirming that running grub2-mkconfig from the DVD in rescue mode works.

After completing Installation 2 and rebooting from the DVD into rescue mode, there are two installations listed for mounting. They have identical names, so you have to guess which one is Installation 2.

One minor problem is that, before rebooting into Installation 2, selinux relabeling is done ...
Comment 28 David Batson 2013-02-09 13:50:55 EST
(In reply to comment #27)
> (In reply to comment #26)
> Item 3 in Comment 24 is referring to the configuration of Installation 2,
> which does not have a bootloader installed. That was not clear in Comment
> 24; sorry about that.
> 
> Confirming that running grub2-mkconfig from the DVD in rescue mode works.

In my case, I have 4 OS's installed.  I have been using Arch Linux GRUB2 for some months now, installed to the MBR.  When I first installed Fedora 18, it replaced Arch's GRUB2 bootloader before I knew it.  I was booting Fedora's GRUB2.  I booted back into Arch Linux and reinstalled the Arch Linux GRUB2 bootloader.

Later I decided to reinstall Fedora to change from E16 to Gnome, and during installation I formatted the Fedora partition.  This time I did not install Fedora 18's GRUB2 bootloader, but created /boot/grub2/grub.cfg from the DVD rescue mode.

I wouldn't think that pieces of the original Fedora GRUB2 bootloader would be left in the MBR...  FWIW, the path to Fedora's themes is different than Arch.  Arch is /boot/grub/... while Fedora is /boot/grub2/....
Comment 29 Steve Tyler 2013-02-09 15:46:44 EST
(In reply to comment #28)
> (In reply to comment #27)
> > (In reply to comment #26)
> > Item 3 in Comment 24 is referring to the configuration of Installation 2,
> > which does not have a bootloader installed. That was not clear in Comment
> > 24; sorry about that.
> > 
> > Confirming that running grub2-mkconfig from the DVD in rescue mode works.
> 
> In my case, I have 4 OS's installed.  I have been using Arch Linux GRUB2 for
> some months now, installed to the MBR.  When I first installed Fedora 18, it
> replaced Arch's GRUB2 bootloader before I knew it.  I was booting Fedora's
> GRUB2.  I booted back into Arch Linux and reinstalled the Arch Linux GRUB2
> bootloader.
> 
> Later I decided to reinstall Fedora to change from E16 to Gnome, and during
> installation I formatted the Fedora partition.  This time I did not install
> Fedora 18's GRUB2 bootloader, but created /boot/grub2/grub.cfg from the DVD
> rescue mode.
> 
> I wouldn't think that pieces of the original Fedora GRUB2 bootloader would
> be left in the MBR...  FWIW, the path to Fedora's themes is different than
> Arch.  Arch is /boot/grub/... while Fedora is /boot/grub2/....

Thanks for the additional details. Did you run grub2-install on your Fedora partition? That could explain why you are seeing grub2 files in /boot/grub2/ ...
Comment 30 Steve Tyler 2013-02-09 17:14:07 EST
(In reply to comment #25)
...
> Installation 2 does not have any grub2 modules installed, yet it can be
> booted from sda1 using the grub2 "configfile" command, so the grub2 modules
> must be coming from the grub2 installation on sda1.
...

For testing, I am using this menu entry in /boot/grub2/grub.cfg on Installation 1:

menuentry 'Boot Fedora Installation 2 with configfile' {
        set root='hd0,msdos3'
        configfile /boot/grub2/grub.cfg
}
Comment 31 David Batson 2013-02-09 21:12:28 EST
No, I did not run grub2-install on my Fedora partition.
Comment 32 David Batson 2013-02-09 21:16:44 EST
(In reply to comment #31)
> No, I did not run grub2-install on my Fedora partition.

Oops, I was wrong.  Here is what I did.

https://bugzilla.redhat.com/show_bug.cgi?id=872826#c99
Comment 33 Fedora End Of Life 2013-04-03 09:40:20 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.

(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
Comment 34 Massimiliano 2013-05-05 08:22:13 EDT
This is strange in my F18 (I have not installed grub2 MBR through anaconda):

# file /etc/default/grub
/etc/default/grub: ERROR: cannot open `/etc/default/grub' (No such file or directory)

# rpm -q --whatprovides /etc/default/grub 
grub2-tools-2.00-15.fc18.x86_64

# rpm -q --list grub2-tools | grep default
/etc/default/grub
/usr/sbin/grub2-set-default

But if I get the package...

# yumdownloader grub2-tools

... I can't find any /etc/default/grub inside it.
Comment 35 Per Sjoholm 2013-05-05 14:52:59 EDT
This is how I fixed this mess. 

MBR overwritten by grub2, use syslinux rpm and dd.
From syslinux http://www.syslinux.org/wiki/index.php/Mbr
 dd bs=440 count=1 conv=notrunc if=mbr/mbr.bin of=/dev/sda

Install fedora with no grub2
Before rebooting. open a shell terminal

chroot /mnt/sysimage
grub2-install --grub-setup=/bin/true /dev/sda
grub2-mkconfig -o /boot/grub2/grub.cfg

reboot and boot http://www.sysresccd.org/
Set boot flag for the partition you want to boot.

install grub1 on the partition boot, use the version in sysrecoverycd and let that boot grub2 core.img

Copy /boot/grub/ files and run to install to partition assume sda2 (hd0,1)

grub
  root (hd0,1)
  setup (hd0,1)
quit


Create menu.lst or grub.conf
cat >>/boot/grub/menu.lst <<EOF
title Fedora
	root (hd0,1)
	kernel /boot/grub2/i386-pc/core.img
EOF

In Fedora
Write /etc/default/grub 
grub2-mkconfig -o /boot/grub2/grub.cfg

by moving bootflag you can now chose which partition to boot as before.
Comment 36 David Shea 2014-03-13 15:09:53 EDT
*** Bug 893106 has been marked as a duplicate of this bug. ***
Comment 37 Per Sjoholm 2014-04-05 14:30:39 EDT
(In reply to Per Sjoholm from comment #35)
> This is how I fixed this mess. 

Grub setup valid for Fedora 20, follow comment  #35

/etc/default/grub is still missing
What should it be ?
Comment 38 David Batson 2014-04-06 01:45:32 EDT
Here is mine from a normal install of Fedora 20, installing GRUB2 to the MBR.

/etc/default/grub

GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT=saved
GRUB_DISABLE_SUBMENU=true
GRUB_TERMINAL_OUTPUT="console"
GRUB_CMDLINE_LINUX="vconsole.font=latarcyrheb-sun16 $([ -x /usr/sbin/rhcrashkernel-param ] && /usr/sbin/rhcrashkernel-param || :) rhgb quiet"
GRUB_DISABLE_RECOVERY="true"
Comment 39 Gene Czarcinski 2014-04-06 15:52:25 EDT
1. Changed release as this should be open until fixed.

2.  If syslinux/extlinux is being used instead of grub2, then the comparable syslinux/extlinux configuration files should be created but nothing isntalled into the MBR.
Comment 40 Vilius Šumskas 2014-11-05 18:28:13 EST
What about RHEL systems? Just upgraded RHEL6 system to RHEL7 using official RedHat upgrade tool (which I believe doesn't install grub2 into MBR) and now my system doesn't have /etc/default/grub file + /boot/grub2 is almost empty with the exception of themes folder. grub2 still boots from old /boot/grub/grub.conf file.
Comment 41 Adam Williamson 2014-11-05 20:56:47 EST
if the 'official upgrade tool' for RHEL 7 is based on fedup (IIRC it is), it does not involve anaconda at all.
Comment 42 David Shea 2014-12-09 16:59:40 EST
*** Bug 1033550 has been marked as a duplicate of this bug. ***
Comment 43 Chris Murphy 2015-02-03 21:24:26 EST
This change in Rawhide is backwards compatible according to this patch:
http://git.savannah.gnu.org/cgit/grub.git/commit/?id=55e2c84fe32f49242b54fc90e0b6a5ade1dc1ab0

But the new/preferred and more discoverable option is to use --no-bootsector instead.
Comment 44 Chris Murphy 2015-02-03 21:33:48 EST
Also this:
http://lists.gnu.org/archive/html/grub-devel/2015-02/msg00032.html

Note You need to log in before you can comment on or make changes to this bug.