This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours

Bug 885240

Summary: GRUB is installed despite Do not install bootloader being selected
Product: [Fedora] Fedora Reporter: Chris Murphy <bugzilla>
Component: anacondaAssignee: David Lehman <dlehman>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: 18CC: anaconda-maint-list, awilliam, clydekunkel7734, eblake, fropeter, g.kaviyarasu, ipilcher, jonathan, mads, pf.rhlists, pjones, robatino, rtguille, sbueno, stephent98, vanmeeuwen+fedora
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: AcceptedBlocker
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 886502 (view as bug list) Environment:
Last Closed: 2012-12-14 22:16:01 EST Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Bug Depends On:    
Bug Blocks: 752661, 886502    
Attachments:
Description Flags
anaconda.log
none
packaging.log
none
program.log
none
storage.log
none
hexdump.txt
none
anaconda.log 18.37
none
anaconda.program.log 18.37
none
anaconda.storage.log 18.37
none
parted mbr.s boot loader assembly code none

Description Chris Murphy 2012-12-07 16:34:30 EST
Description of problem:


Version-Release number of selected component (if applicable):
Fedora-18-Beta-x86_64-Live-Desktop.iso (actual release), yum updated
anaconda 18.36-1


How reproducible:
100%

Steps to Reproduce:

This is a single disk installation, started with a newly created virtual disk image, therefore it's assured to be zero'd.

1. Boot from beta live cd.
2. yum update anaconda
3. launch installer
4. In Installation Destination, choose "Full disk summary and options"
5. Select the disk, click on "Do not install bootloader"
6. Proceed with installation.
7. Reboot.

Actual results:
System reboots to a GRUB menu, just as if I hadn't deselected the disk for bootloader installation.

hexdump -C /dev/sda shows a GRUB bootloader in the MBR boot loader region, and in the MBR gap.

Expected results:
An unbootable system in this case; although specifically I expect no bootloader code in the MBR or MBR gap.


Additional info:
The program.log shows that grub2-install is still being called whether the "install bootloader" option it enabled or disabled for the selected disk. Seems that's the most likely cause of the bug.

Question on whether grub2-install should be supressed, or replaced with grub2-mkimage so that a core.img is still produced, and can be loaded by another boot manager (e.g. one that can't read a grub.cfg).

It's highly recommended that the grub2-mkconfig command be retained (as it is now), even with the boot loader installation option deselected. This allows an existing GRUB to use configfile to point to the Fedora grub.cfg.
Comment 1 Chris Murphy 2012-12-07 16:35:05 EST
Created attachment 659598 [details]
anaconda.log
Comment 2 Chris Murphy 2012-12-07 16:35:36 EST
Created attachment 659599 [details]
packaging.log
Comment 3 Chris Murphy 2012-12-07 16:36:05 EST
Created attachment 659600 [details]
program.log
Comment 4 Chris Murphy 2012-12-07 16:36:32 EST
Created attachment 659602 [details]
storage.log
Comment 5 Chris Murphy 2012-12-07 16:37:15 EST
Proposing as release blocking, Final Release Criterion #9 "The installer must be able to install into free space alongside an existing clean single-partition Windows installation and either install a bootloader which can boot into the Windows installation, or leave the Windows bootloader untouched and working."

I have not tested this along side a Windows install, but at the moment there's good reason to believe grub would still be installed, and step on the Windows MBR bootloader.
Comment 6 Chris Murphy 2012-12-07 17:06:10 EST
Adding pjones, re: whether grub2-install should be removed without replacement, or replaced with grub2-mkimage to create core.img so that e.g. an existing GRUB Legacy can use an entry such as:

Title "GRUB 2 - Fedora 18"
root (hdx,y)
kernel /grub2/core.img
Comment 7 Ian Pilcher 2012-12-07 17:11:10 EST
I'm seeing an interesting behavior in a test VM with two disks, which may shed some light on the behavior that you're seeing.

If one of the two disks is set as the boot device, clicking on the "Do not install bootloader" button causes the *other* disk to become selected as the boot device.

In other words, I don't think that the "Do not install bootloader" button is actually intended to enable you to install no bootloader at all; I think it really means do not install the bootloader *here*.

What's needed for your (and my) use case is a truly global do not install a bootloader setting, rather than something per-device.
Comment 8 Chris Murphy 2012-12-07 17:16:13 EST
(In reply to comment #7)
No, I have a single disk, with a single green check under boot for that disk, and I'm allowed to deselect it. And it's clearly intended to allow no boot loader at all because it's a release requirement for installing along side Windows, see above.
Comment 9 Ian Pilcher 2012-12-07 17:25:51 EST
(In reply to comment #8)
> No, I have a single disk, with a single green check under boot for that
> disk, and I'm allowed to deselect it. And it's clearly intended to allow no
> boot loader at all because it's a release requirement for installing along
> side Windows, see above.

I don't see how it can be "clearly intended to allow no boot loader at all" when it doesn't even allow me to select that type of configuration (i.e. it insists on always having at least one disk selected at a boot disk).  As it stands, even once the setting is honored, it will still be forcing me to trash the bootloader on one of my two mirrored disks.
Comment 10 David Lehman 2012-12-07 17:35:06 EST
(In reply to comment #7)
> If one of the two disks is set as the boot device, clicking on the "Do not
> install bootloader" button causes the *other* disk to become selected as the
> boot device.

I just tried in a vm with three disks and was unable to reproduce the behavior you describe above.

> In other words, I don't think that the "Do not install bootloader" button is
> actually intended to enable you to install no bootloader at all; I think it
> really means do not install the bootloader *here*.
> 
> What's needed for your (and my) use case is a truly global do not install a
> bootloader setting, rather than something per-device.

If the user chooses to have no boot disk, that indicates to us that we should not install a bootloader.
Comment 11 Ian Pilcher 2012-12-07 18:25:20 EST
(In reply to comment #10)
> I just tried in a vm with three disks and was unable to reproduce the
> behavior you describe above.

I can't reproduce it here either.  Weird.

> If the user chooses to have no boot disk, that indicates to us that we
> should not install a bootloader.

OK cool.

I'll test the update that honors the setting as soon as it's available.
Comment 12 Fedora Update System 2012-12-07 20:45:21 EST
anaconda-18.37-1.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/anaconda-18.37-1.fc18
Comment 13 Chris Murphy 2012-12-07 23:18:42 EST
anaconda-18.37-1 observations:
1. I'm getting some sort of garbage in the first ~80 bytes of LBA 0. I am starting with clean virtual disk images. However if I drop the syslinux/mbr.bin into the first 440 bytes before starting installation, at the end of installation, it's untouched. So I don't know what this garbage is, it does cause the VM to try to boot from the virtual disk which then fails, instead of trying to boot from an alternate disk, although that's just because of the boot order.

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.
Comment 14 Chris Murphy 2012-12-07 23:20:11 EST
Created attachment 659695 [details]
hexdump.txt

hexdump of the first dozen or so sectors of the install disk, showing the garbage in the first four lines. These lines are zero before install, and non-zero after install, so I'm not sure what's writing this information there, but it's unexpected.
Comment 15 Chris Murphy 2012-12-07 23:24:08 EST
Created attachment 659696 [details]
anaconda.log 18.37

This log contains: 23:02:06,487 INFO anaconda: Installing bootloader
Comment 16 Chris Murphy 2012-12-07 23:26:49 EST
Created attachment 659697 [details]
anaconda.program.log 18.37

Not seeing anything re: garbage output to LBA 0.
Comment 17 Chris Murphy 2012-12-07 23:28:45 EST
Created attachment 659698 [details]
anaconda.storage.log 18.37

Here we go, what's this?

23:02:06,489 DEBUG storage: new default image: <pyanaconda.bootloader.LinuxBootLoaderImage object at 0x7f7ab4067c50>
Comment 18 Clyde E. Kunkel 2012-12-08 00:41:54 EST
(In reply to comment #13)
> <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.
Comment 19 Eric Blake 2012-12-08 09:27:38 EST
(In reply to comment #18)
> (In reply to comment #13)
> > <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.
Comment 20 Ian Pilcher 2012-12-08 14:10:52 EST
Seems to work with "smoke 5" (anaconda 18.37).
Comment 21 Fedora Update System 2012-12-08 17:12:51 EST
Package anaconda-18.37-1.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing anaconda-18.37-1.fc18'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-19991/anaconda-18.37-1.fc18
then log in and leave karma (feedback).
Comment 22 Clyde E. Kunkel 2012-12-08 19:11:56 EST
(In reply to comment #20)
> Seems to work with "smoke 5" (anaconda 18.37).

Yep.  Just no grub.cfg or modules, etc.
Comment 23 Steve Tyler 2012-12-09 00:38:26 EST
(In reply to comment #14)
> Created attachment 659695 [details]
> hexdump.txt
> 
> hexdump of the first dozen or so sectors of the install disk, showing the
> garbage in the first four lines. These lines are zero before install, and
> non-zero after install, so I'm not sure what's writing this information
> there, but it's unexpected.

This parted command writes the same first 80 bytes to a zero-filled disk image:
# parted /dev/sda mklabel msdos

Test procedure:

Create a zero-filled disk image:
$ qemu-img create f18-test-2.img 12G

Start the Live CD:
$ qemu-kvm -m 2048 -hda f18-test-2.img -cdrom ~/xfr/fedora/F18/F18-Final/TC1/Fedora-18-TC1-x86_64-Live-Desktop.iso -usb -vga qxl -boot menu=on -usbdevice mouse

From a terminal running on the Live CD:

[root@localhost liveuser]# dd if=/dev/sda count=1 2>/dev/null | hexdump -C
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000200
[root@localhost liveuser]# parted /dev/sda mklabel msdos
Information: You may need to update /etc/fstab.

[root@localhost liveuser]# dd if=/dev/sda count=1 2>/dev/null | hexdump -C
00000000  fa b8 00 10 8e d0 bc 00  b0 b8 00 00 8e d8 8e c0  |................|
00000010  fb be 00 7c bf 00 06 b9  00 02 f3 a4 ea 21 06 00  |...|.........!..|
00000020  00 be be 07 38 04 75 0b  83 c6 10 81 fe fe 07 75  |....8.u........u|
00000030  f3 eb 16 b4 02 b0 01 bb  00 7c b2 80 8a 74 01 8b  |.........|...t..|
00000040  4c 02 cd 13 ea 00 7c 00  00 eb fe 00 00 00 00 00  |L.....|.........|
00000050  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000001b0  00 00 00 00 00 00 00 00  64 0b 00 00 00 00 00 00  |........d.......|
000001c0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000001f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 55 aa  |..............U.|
00000200
[root@localhost liveuser]#
Comment 24 Steve Tyler 2012-12-09 02:21:06 EST
(In reply to comment #23)
...
> This parted command writes the same first 80 bytes to a zero-filled disk
> image:
> # parted /dev/sda mklabel msdos
...

See these files:
parted-3.1/libparted/labels/dos.c
parted-3.1/libparted/mbr.s

In the parted source:
http://ftp.gnu.org/gnu/parted/
Comment 25 Steve Tyler 2012-12-09 03:14:25 EST
If I'm reading this code right, parted writes the mbr only if the first byte on the disk is zero. However, in a test[1], parted always writes the mbr. This could be a parted bug. Even so, shouldn't writing the mbr be optional?

$ less -N parted-3.1/libparted/labels/dos.c
...
   1263         if (!table->boot_code[0]) {
   1264                 memset (table->boot_code, 0, 512);
   1265                 memcpy (table->boot_code, MBR_BOOT_CODE, sizeof (MBR_BOOT_CODE));
   1266         }
...

For the record, the version of parted on Fedora-18-TC1-x86_64-Live-Desktop.iso is:
parted-0:3.1-9.fc18.x86_64

[1] Using shed to change the first byte to these non-zero values: 0x01, 0xff.
Comment 26 David Lehman 2012-12-10 10:53:01 EST
(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.
Comment 27 Chris Murphy 2012-12-10 14:00:19 EST
(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.
Comment 28 David Lehman 2012-12-10 14:29:25 EST
(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.
Comment 29 Steve Tyler 2012-12-10 14:43:27 EST
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".
Comment 30 Chris Murphy 2012-12-10 14:59:05 EST
(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.
Comment 31 Adam Williamson 2012-12-10 15:29:56 EST
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.
Comment 32 Steve Tyler 2012-12-10 15:38:32 EST
Created attachment 661116 [details]
parted mbr.s boot loader assembly code

The "goober" is the parted boot loader: Comment 24.
Comment 33 Chris Murphy 2012-12-11 21:29:33 EST
(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.
Comment 34 Adam Williamson 2012-12-12 00:54:43 EST
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 35 Eric Blake 2012-12-12 07:57:38 EST
(In reply to comment #34)
> 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.

Done: bug 886502
Comment 36 Fedora Update System 2012-12-12 15:40:12 EST
Package anaconda-18.37.2-1.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing anaconda-18.37.2-1.fc18'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-19991/anaconda-18.37.1-1.fc18
then log in and leave karma (feedback).
Comment 37 Chris Murphy 2012-12-12 17:17:33 EST
anaconda-18.37.2-1 fix this bug for me. Grub is not installed to MBR or MBR gap.
Comment 38 Fedora Update System 2012-12-14 22:16:08 EST
anaconda-18.37.2-1.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.