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

Bug 804835

Summary: Failed to install GRUB2 into boot partition
Product: [Fedora] Fedora Reporter: Dr. Tilmann Bubeck <tilmann>
Component: grub2Assignee: Peter Jones <pjones>
Status: CLOSED NEXTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 17CC: awilliam, bcl, bellevuemer, chepioq, dennis, eblake, gerfert, g.kaviyarasu, horsley1953, jonathan, korsnick, kparal, mads, mihai, mrmazda, n-a-zhubr, nitind, pjones, pschindl, robatino, satellitgo, sebastian.heyn, t.artem, tflink, vanmeeuwen+fedora
Target Milestone: ---Keywords: CommonBugs
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
See Also: https://bugzilla.redhat.com/show_bug.cgi?id=861192
Whiteboard: https://fedoraproject.org/wiki/Common_F17_bugs#chainloading-fail RejectedBlocker
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-04-30 19:06:06 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:

Description Dr. Tilmann Bubeck 2012-03-19 17:38:46 EDT
Description of problem:
When choosing to install GRUB2 into boot partition (in contrast to MBR, which is normally used), then no error message appeare, but the system is unable to boot. After BIOS-Power-On it shows only "GRUB" and does not continue.

Explanation: I use a seperate partition (sda1) which only has a GRUB-1.99 to device which partition to chainload. I installed F17 onto sda7 and choose sda7 in the master grub. Instead of getting the second GRUB of F17 I only get "GRUB". This concept normally works for anything including F16.

Version-Release number of selected component (if applicable):
Fedora-17-Beta-TC2-x86_64-DVD.iso

How reproducible:
always

Steps to Reproduce:
1. Install F17
2. Choose "Install GRUB onto Boot Partition"
3. reboot
  
Actual results:
GRUB after BIOS Power On.

Expected results:
Grub working

Additional info:
Comment 1 Petr Schindler 2012-03-28 07:39:13 EDT
I have the same problem. I have two systems and I want one grub for each of them. The second system has it's own grub on /boot partition. When I install grub to MBR it works, but when I want to install grub to another partition, it doesn't work.

My layout:
vda
 - vda1 - BIOS BOOT partition
 - vda2 - /boot partition of first system (this one has grub in mbr)
 - vda3 - LV group (with swap a and root of the first system
 - vda4 - /boot partition of second system - this is where I've installed grub for second system
 - vda5 - root of the second system

in grub.cfg I have this entry:
menuentry "second" {
    set root=(hd0,4)
    chainloader +1
}

Symptoms are same as Till's

This worked for me in Fedora 16, now, with new grub it doesn't work. I'm not sure, if this is problem of anaconda (I haven't found anything in logs about grub). I think it is a problem of new 2.00 beta2 grub more probably.
Comment 2 Dr. Tilmann Bubeck 2012-03-28 08:09:19 EDT
There is a workaround.

You (and also I) have used chainloading to load the second GRUB:

menuentry "second" {
    set root=(hd0,4)
    chainloader +1
}

This should work with any boot loader installed. But I does not work.

If you use the following construct (which is only possible if the second GRUB gets started by a first GRUB (and not e.g. from a MSDOS MBR), then it works:

menuentry "second" {
    set root=(hd0,4)
    insmod ext2
    kernel /boot/grub2/core.img
}

You have to change the kernel command line to fit your path. You have to use core.img as a kernel.
Comment 3 Artem S. Tashkinov 2012-04-06 06:39:22 EDT
Confirming.

I was trying to install GRUB2 boot loader into sda6 (logical partition) and chainloading doesn't work, the system hangs after showing "GRUB". I have tried to reinstall grub2 by invoking "grub2-install /dev/sda6 --force" but it didn't help.

To me it's a definite release blocker - a lot of people install multiple Linux distros alongside and wiping MBR only for Fedora's sake doesn't seem rational or reasonable.
Comment 4 Kamil Páral 2012-04-06 06:42:05 EDT
Proposing as Beta blocker. We don't have specific criteria for bootloaders, but it fails all other criteria that assume Fedora must be able to boot. But when bootloader is not put into MBR, Fedora fails to boot (or it is extremely complicated to work around that).
Comment 5 Adam Williamson 2012-04-06 13:34:30 EDT
So, my reading is this isn't actually a bug, just kind of a limitation of grub's design.

I don't think grub2 is really set up to be chainloaded. I think it only works between two identical or very similar grub2 versions. i.e., I don't think you can chainload 2.00~beta2 from 1.99.

http://ubuntuforums.org/showthread.php?t=1307385 is interesting here: it's about a similar 'bug' for chainloading grub2 from grub-legacy. You can't do it: you have to do the same core.img thing. And if you look at https://wiki.ubuntu.com/Grub2 , you can see there was even an Ubuntu installer option in the past which set up a 'chainload' from grub-legacy to grub2 using the 'kernel core.img' syntax, not 'chainloader'.

I think grub2's design doesn't really expect you to chainload grubs, basically. It only expects you to use chainloader to boot stuff like Windows. It's expecting you to use a single grub2 in the MBR to keep track of and boot multiple Linux installs; this is the point of the os-detect script and the new 'nested' boot menus in 2.00~beta2, which list out each detected Linux install separately.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 6 Artem S. Tashkinov 2012-04-06 13:49:29 EDT
(In reply to comment #5)

1) The option of installing GRUB2 on any partition boot sector, other than MBR exists and is still officially supported.

2) Earlier GRUB2 releases (e.g. 1.99-beta2 which is included in Fedora 16) support chainloading and work correctly when not being installed in the MBR.

If chainloading is not supposed to work with GRUB2, you can simply remove this option from the installer to avoid confusion and further duplicate bug reports (leaving us with just two options: install in MBR, don't install at all) - however I suspect the non-MBR option for GRUB2 will appear as a feature request here.
Comment 7 Mads Kiilerich 2012-04-06 14:10:54 EDT
I think a part of the explanation is that grub2-install without force will install core.img starting in the second sector so it can be picked up with 'chainloader +1'.

grub2-install --force (which normally has to be used for partitions instead of whole devices) will just record the sector numbers of core.img, so the corresponding chainloader entry would be something like 'chainloader /grub2/core.img'.
Comment 8 Artem S. Tashkinov 2012-04-06 14:22:48 EDT
(In reply to comment #7)

> I think a part of the explanation is that grub2-install without force will
install core.img starting in the second sector so it can be picked up with
'chainloader +1'.

Without --force GRUB2 will outright refuse to be installed anywhere other than in the MBR.
Comment 9 Mads Kiilerich 2012-04-06 15:09:38 EDT
(In reply to comment #8)
> Without --force GRUB2 will outright refuse to be installed anywhere other than
> in the MBR.

Correct. Partitioned devices will usually have 31k free where core.img can be stored without force. Partitions do not have that space and the boot loader can thus only be installed with the unreliable blocklist method that requires force.

An external chain loader that points to core.img will however not use the blocklist and will thus be reliable.
Comment 10 Artem S. Tashkinov 2012-04-06 15:33:55 EDT
(In reply to comment #9)

> An external chain loader that points to core.img will however not use the
> blocklist and will thus be reliable.

An external chain loader which can read the filesystem GRUB2 is installed on, because core.img weighs more than 4K thus you just cannot jump onto it from another bootloader.

Which means there are just two bootloaders in the world which can properly chainload GRUB2: a patched version of GRUB1 (a non-patched version doesn't support ext4) and GRUB2.
Comment 11 Artem S. Tashkinov 2012-04-06 15:46:08 EDT
(In reply to comment #10)

I was wrong, you can simply copy core.img from /boot to a filesystem where another bootloader resides and "run" this file - in theory it should work.

OK, then probably the best avenue in "resolving" this bug report will be anaconda showing a message to the user which (in case of not installing in an MBR) says:

"GRUB2 chainloading by referencing the first partition sector no longer works. In order to boot GRUB2 you should load a grub2 core by running /boot/grub2/core.img as a new kernel, e.g.

root (hd0,X)
kernel /boot/grub2/core.img

in case of GRUB1

and

set root=(hd0,X)
insmod ext2
kernel /boot/grub2/core.img

in case of GRUB2.
Comment 12 Tim Flink 2012-04-09 11:53:34 EDT
Discussed at the 2012-04-06 Fedora 17 beta blocker review meeting:

Rejected as a blocker bug for Fedora 17 beta because is not clearly a bug and no matter what, the desired outcome requires manual tinkering.

However, there seems to be a need for documentation on exactly how to accomplish this and it might be wise to add this bug to commonbugs.
Comment 13 Artem S. Tashkinov 2012-04-09 12:35:25 EDT
(In reply to comment #12)

> Rejected as a blocker bug for Fedora 17 beta because is *not clearly a bug*

Not meaning to intervene with Fedora development team decisions, but I am still interested as to what criteria must a bug comply with in order to be treated as "clearly a bug".
Comment 14 Tim Flink 2012-04-09 12:54:44 EDT
(In reply to comment #13)
> (In reply to comment #12)
> 
> > Rejected as a blocker bug for Fedora 17 beta because is *not clearly a bug*
> 
> Not meaning to intervene with Fedora development team decisions, but I am still
> interested as to what criteria must a bug comply with in order to be treated as
> "clearly a bug".

I don't think that there are any explicit criteria for something to be a bug or not.

In this case, it seems like the issue described is due to either a limitation in grub2's design or incomplete documentation (chainloader vs. core.img).
Comment 15 Adam Williamson 2012-04-09 23:09:59 EDT
artem: you can read the whole discussion if you want to see the full context of the decision - http://meetbot.fedoraproject.org/fedora-bugzappers/2012-04-06/f17-beta-blocker-review-5.2012-04-06-17.01.log.html . I always mean to actually link to the blocker meeting minutes when posting 'blocker status update' comments, but don't always remember...



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 16 Mads Kiilerich 2012-04-17 20:40:35 EDT
(In reply to comment #7)
I was wrong. Chainloader to partitions with blocklist should work.

I have however heard upstream rumours of a grub bug in this area - that might be what shows up here.
Comment 17 Tom Horsley 2012-04-17 21:24:59 EDT
I was able to install Fedora 17 Alpha telling it to install grub2 in the partition and it worked fine. I also have Fedora 16 installed the same way, and it also works fine. Fedora 17 Beta, however, does not work at all with grub2 installed to the partition. This sure seems like a bug to me, and one I can't work around as described above because the stand alone grub1 partition I used to chainload everything can't read ext4.
Comment 18 Tom Horsley 2012-04-17 21:37:03 EDT
And just to reinforce the bugness: If I chroot into the fedora 17 partition, yum erase grub2 then install the fedora 16 version of grub2 from the rpm I used yumdownloader to fetch under f16, I can now actually chainload and boot fedora 17 (with a few file not found errors no doubt due to the grub2.cfg file not being precisely compatible with fedora 16 grub2).
Comment 19 Kamil Páral 2012-04-18 04:58:07 EDT
Can you please find a reference to the upstream bug? Maybe we could then re-evaluate blocker-ness of this issue.
Comment 20 Adam Williamson 2012-04-18 12:10:39 EDT
Tom: still I think notabug.

I think chainloading works if you happen to be using precisely the same version of grub2 in both places (the initial bootloader and the one you want to chainload).

Alpha used grub2 1.99, same as F16. Beta uses grub 2.00~beta2. 'chainloader' will work with F16 and F17 Alpha, or F16 and F17 with F16's grub2 installed, but not with F16 and F17 Beta, because F17 Beta uses a different version of grub2 from F16. I still think, though, this is how things are 'meant' to work with grub2.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 21 Tom Horsley 2012-04-18 13:29:03 EDT
I can't possibly disagree more. Virtually everything can be cahinloaded. Heck, even Windows 7 can be chainloaded. Also, I'm already using a completely different version of grub in my stand alone boot partition (in fact, it is grub1, not grub2), and it has always worked. It is only f17 that has broken things in a fashion that no boot loader has ever broken them before.
Comment 22 Artem S. Tashkinov 2012-04-18 13:42:24 EDT
(In reply to comment #19)

It seems like GRUB2 developers are unaware of this bug, because I couldn't find anything relevant in their bugzilla (within both open and closed bug reports): http://savannah.gnu.org/bugs/?group=grub

My google-foo is also not top-notch since when I try to find similar bug reports this one almost always pops on the first position.

It makes sense to build GRUB2 from sources (preferably from trunk http://www.gnu.org/software/grub/grub-download.html)  without any extra patches/additions and try to chainload it.
Comment 23 Tom Horsley 2012-04-18 14:42:23 EDT
This seems a bit old, but maybe the bug came back?

http://savannah.gnu.org/bugs/?32391

It certainly seems to indicate the grub developers believe it ought to be possible to chainload into grub2 (in this bug, from the windows boot loader).
Comment 24 Mads Kiilerich 2012-04-18 16:53:31 EDT
(In reply to comment #19)
> Can you please find a reference to the upstream bug? Maybe we could then
> re-evaluate blocker-ness of this issue.

http://bzr.savannah.gnu.org/lh/grub/trunk/grub/revision/4217

I have reproduced the problem with 2.0~beta3. Backporting 4217 fixed the problem.

I don't know if it only influences chainloading or if it influences all installations to partitions or when it was introduced.

Tested using packages build from https://bitbucket.org/kiilerix/grub2/ .
Comment 25 Mads Kiilerich 2012-04-18 19:33:48 EDT
*** Bug 808948 has been marked as a duplicate of this bug. ***
Comment 26 Mads Kiilerich 2012-04-18 19:38:33 EDT
There is a scratch build of a grub2 similar to the one that worked for me on http://koji.fedoraproject.org/koji/taskinfo?taskID=4003982 . It contains a number of major changes compared to what currently can be found in f17, so be careful if you try it and be sure to run both grub2-install and grub2-mkconfig.
Comment 27 Tom Horsley 2012-04-18 20:13:49 EDT
I just gave the build from comment 26 a try, and it chainloads just fine from my grub1 partition. More evidence that it really is a bug :-).

Not sure what is up with the rpm though, if I tried a "yum install" on it, it kept telling me "nothing to do", but the lower level rpm -i worked fine.

Someone with proper permissions should really change the component of this bug to grub2 and make it a release blocker.

(And I see we now have grub getting into the video mode setting act, which also means the grub menus are now way too tiny to read on a large HDTV monitor :-).
Comment 28 Mads Kiilerich 2012-04-18 20:23:35 EDT
Changed component to grub2 and made it f17blocker.
Comment 29 Adam Williamson 2012-04-18 21:17:01 EDT
I still don't make this bug a release blocker, to be honest. Chainloading has always been 'you're on your own' territory. grub2 is dead against it and we have to pass it a --force option to even make it install to a partition at all...

but certainly if there's a fix for this we should pull it. I'll do that soon if pjones is busy.
Comment 30 Adam Williamson 2012-04-18 21:32:25 EDT
clearing 'rejectedblocker' to make sure the nomination is active.
Comment 31 Mario Heininger 2012-04-19 02:01:47 EDT
Well, i have the same problem on the F17 BETA. My normal Setup on the Workstations is an 3party Bootmanager in the MBR (because the Bootmanager have some funny options, online configure, partition hiding ...).

The same Issue where when we start with F15
grub2-install /dev/sda3
/sbin/grub2-bios-setup: warning: File system `ext2' doesn't support embedding.
/sbin/grub2-bios-setup: warning: Embedding is not possible.  GRUB can only be
installed in this setup by using blocklists.  However, blocklists are
UNRELIABLE and their use is discouraged..
Installation finished. No error reported.

okay
grub2-install -f /dev/sda3
/sbin/grub2-bios-setup: warning: File system `ext2' doesn't support embedding.
/sbin/grub2-bios-setup: warning: Embedding is not possible.  GRUB can only be
installed in this setup by using blocklists.  However, blocklists are
UNRELIABLE and their use is discouraged..
Installation finished. No error reported.

I have installed the grub2 RPM Package from F16 in the F17 Beta, so it works ...
Comment 32 Adam Williamson 2012-04-19 03:14:04 EDT
I've done a build of grub2 which bumps to beta3 and backports the fix for this (thanks, Mads). I'm away from home and have no F17 machine to smoke test this on, so can someone please do it for me? Here's the scratch build:

http://koji.fedoraproject.org/koji/taskinfo?taskID=4004533

please just install it and do a grub2-install, reboot, see if it explodes (and for bonus points, if it actually fixes the bug).

If you all let me know it's okay, I'll send it through to Rawhide and F17.
Comment 33 Mads Kiilerich 2012-04-19 05:35:19 EDT
(In reply to comment #31)
> Well, i have the same problem on the F17 BETA.

FWIW: This do not show any evidence of being the same problem. You have to use -f to install to a partition - and you do get a helpful warning. That is intended behaviour. The problem discussed here is that the bootloader doesn't work anyway.
Comment 34 Dr. Tilmann Bubeck 2012-04-19 06:27:03 EDT
I tested your build from Comment #32 and chainloading works like a charm!

Thanks!
Comment 35 Tom Horsley 2012-04-19 06:37:28 EDT
I just got an even weirder than normal message from the grub2 in comment #33:

[root@zooty grub2]# grub2-install --force '(hd0,msdos3)'
/usr/sbin/grub2-bios-setup: warning: File system `ext2' doesn't support embedding.
/usr/sbin/grub2-bios-setup: warning: Embedding is not possible.  GRUB can only be installed in this setup by using blocklists.  However, blocklists are UNRELIABLE and their use is discouraged..
Installation finished. No error reported.

Why is it mentioning ext2? I do have an ext2 partition on this drive, but sda3
(a.k.a hd0,msdos3) is NOT ext2.

I guess I'll find out if it works when I reboot, but thought I should record this while I remembered.
Comment 36 Tom Horsley 2012-04-19 06:44:52 EDT
Looks like it worked though. I guess the ext2 message is just irrelevant babbling. I can chainload just fine with this version of grub2, but once again trying to install it with "yum install" tells me "nothing to do" (that's after I did a yum erase of the previous one), but rpm -i did install it OK.
Comment 37 Mads Kiilerich 2012-04-19 06:51:09 EDT
(In reply to comment #35)
> I just got an even weirder than normal message from the grub2 in comment #33:

If it really is a bug then it is a different bug - please file a new issue. You could consider using /dev/sdX instead of the internal (hdX,X) notation. You could also try to run bash -x /sbin/grub2-install and see if that shows an explanation.
Comment 38 Tom Horsley 2012-04-19 07:56:20 EDT
I don't think it is a bug (at least it seemed to work fine). It is probably just going through all the partitions for no particular reason and complains about the ext2 one. Seems harmless, it was just weird.

It does do the same thing with '(hd0,msdos3)' and /dev/sda3 as the arg to grub2-install (and the install works fine either way).
Comment 39 Adam Williamson 2012-04-20 16:19:59 EDT
Discussed at 2012-04-20 blocker review meeting: http://meetbot.fedoraproject.org/fedora-bugzappers/2012-04-20/fedora-bugzappers.2012-04-20-17.01.log.txt . We agreed that, although this is a valid bug in grub and not just a 'doctor, it hurts', most of the rationale cited during Beta still applies: you always have to do manual configuration to make chainloading work, and the fact that it works if you configure it one way but not if you configure it the other isn't really enough to block release, especially since chainloading is a non-standard setup in the first place. The workaround is available, and works. So this is rejected as a Final blocker.

(We'll get the fix in soon anyway though, most likely).
Comment 40 Tom Horsley 2012-04-20 16:57:56 EDT
But don't forget an awful lot of the folks testing alpha and beta do so by multi-booting with chainloading, they might give up if they can't keep doing that :-).

I guess I should give up and figure out how to make my stand alone boot partition be grub2 and replace chainloading with booting core.img...
Comment 41 Mads Kiilerich 2012-04-23 06:51:32 EDT
*** Bug 815301 has been marked as a duplicate of this bug. ***
Comment 42 Sebastian Heyn 2012-04-27 13:31:25 EDT
@Adam - how to install this?
Comment 43 Mads Kiilerich 2012-04-30 19:06:06 EDT
grub2-2.0-0.24.beta4.fc17 has been pushed to f17 stable - closing.

It is recommended to run both grub2-install and grub2-mkconfig to get a new boot loader and matching configuration.
Comment 44 dominique 2012-05-01 03:37:31 EDT
(In reply to comment #43)
> grub2-2.0-0.24.beta4.fc17 has been pushed to f17 stable - closing.
> 
> It is recommended to run both grub2-install and grub2-mkconfig to get a new
> boot loader and matching configuration.

grub2-install don't work for me, i Have this error message :

[root@dominique ~]# grub2-install /dev/sda2
/usr/sbin/grub2-bios-setup: warning: File system `ext2' doesn't support embedding.
/usr/sbin/grub2-bios-setup: warning: Embedding is not possible.  GRUB can only be installed in this setup by using blocklists.  However, blocklists are UNRELIABLE and their use is discouraged..
/usr/sbin/grub2-bios-setup: error: will not proceed with blocklists.
[root@dominique ~]#

I want install grub on sda2 because on sda1 there is grub for my Fedora 16, and I want chainloader grub-Fedora17 in grub-Fedora16
Comment 45 Artem S. Tashkinov 2012-05-01 04:54:08 EDT
(In reply to comment #44)

It has been mentioned numerous times, and it's even written in GRUB's man'ual as well, but you need a special treatment )) so, when installing GRUB2 in any partition other than the MBR you must use

--force

Best of luck
Comment 46 Tom Horsley 2012-05-01 05:20:19 EDT
Mentioned many time maybe, but not mentioned in the one place it would do the
most good: In the error message printed by grub2-install.
Comment 47 Artem S. Tashkinov 2012-05-01 05:45:30 EDT
(In reply to comment #46)

I vividly remember that older GRUB2 releases printed a message about the necessity of using --force. Maybe it's an instance of false memory )) or maybe this message was subsequently concealed to avoid GRUB2 misuse.
Comment 48 dominique 2012-05-01 08:22:37 EDT
Ok, I use the --force option and that work. And after the mkconfig.

And now, I can boot on the grub of my F17, which is on sda(0,2) by grub on my F16, on sda(0.1).

I just had this line in the /etc/grub.d/40_custom of my F16

menuentry "Fedora17" {
set root=(hd0,2)
chainloader +1
}
 and do a mkconfig
Comment 49 pcotaku 2012-05-03 23:18:14 EDT
I reached somehow to make my machine work with F17 beta in my /dev/sdc2.

I hope this method can be a little help for others in trouble with chainload.

This is what I have done.

1 : Install F17 to a partition, install grub2 to the partition.

2 : After installation is done, but before reboot, mount the partition of F17.
    Look for a file grub.cfg.new. It must resides in /boot/grub2. Copy or rename that file to /boot/grub2/grub.cfg 

3 : Then reboot

4 : In the original bootloader's menu.lst (I still use grub not grub2), you change the line "chainloader +1" to "kernel /boot/grub2/i386-pc/core.img".

5 : Boot

That's the solution I found.

Now my machine boots F17 beta without trouble.
Comment 50 Nikolai Zhubr 2012-05-24 14:44:38 EDT
I'm not quite sure if it is supposed to be fixed in current 17-beta iso image already, but in case it is - I have to report that today's beta image still produced non-bootable partition for me (stuck with "GRUB " message as mentioned above upon reboot) Because my master bootloader is not GRUB and does not provide any ways for tricky workarounds, I see no evident way to reasonably easy fix this installation (Though my other partitions do remain bootable so I'm not in a trouble) Just hoping final release get this really fixed.
Comment 51 Adam Williamson 2012-05-24 14:58:53 EDT
What do you mean by 'current 17-beta' and 'today's beta'? We don't redo the Beta. The Beta is the Beta. It doesn't change. Anything labelled Beta is just...Beta. Later stuff is in nightlies or the Final TCs/RCs.
Comment 52 Nikolai Zhubr 2012-05-24 15:35:30 EDT
(In reply to comment #51)
> We don't redo the Beta. The Beta is the Beta. It doesn't change. 

Ah, my bad. Now I see timestamps. I probably should've tried 17.RC4 instead, as beta was out before the bug closed. Sorry for the noise!