Bug 885240

Created attachment 659598 [details]
anaconda.log

Created attachment 659599 [details]
packaging.log

Created attachment 659600 [details]
program.log

Created attachment 659602 [details]
storage.log

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.

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

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.

(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.

(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.

(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.

(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.

anaconda-18.37-1.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/anaconda-18.37-1.fc18

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.

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.

Created attachment 659696 [details]
anaconda.log 18.37

This log contains: 23:02:06,487 INFO anaconda: Installing bootloader

Created attachment 659697 [details]
anaconda.program.log 18.37

Not seeing anything re: garbage output to LBA 0.

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>

(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.

(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.

Seems to work with "smoke 5" (anaconda 18.37).

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).

(In reply to comment #20)
> Seems to work with "smoke 5" (anaconda 18.37).

Yep.  Just no grub.cfg or modules, etc.

(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]#

(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/

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.

(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.

(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.

(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.org for review/inclusion.

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".

(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.

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.

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

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

(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.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.

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.

(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

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).

anaconda-18.37.2-1 fix this bug for me. Grub is not installed to MBR or MBR gap.

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.