Bug 804835
Summary: | Failed to install GRUB2 into boot partition | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Dr. Tilmann Bubeck <tilmann> |
Component: | grub2 | Assignee: | Peter Jones <pjones> |
Status: | CLOSED NEXTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 17 | CC: | aros, 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, tflink, vanmeeuwen+fedora |
Target Milestone: | --- | Keywords: | CommonBugs |
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
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 23:06:06 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Dr. Tilmann Bubeck
2012-03-19 21:38:46 UTC
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. 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. 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. 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). 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 (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. 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'. (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. (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. (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. (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. 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. (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". (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). 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 (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. 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. 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). Can you please find a reference to the upstream bug? Maybe we could then re-evaluate blocker-ness of this issue. 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 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. (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. 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). (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/ . *** Bug 808948 has been marked as a duplicate of this bug. *** 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. 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 :-). Changed component to grub2 and made it f17blocker. 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. clearing 'rejectedblocker' to make sure the nomination is active. 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 ... 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. (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. I tested your build from Comment #32 and chainloading works like a charm! Thanks! 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. 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. (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. 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). 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). 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... *** Bug 815301 has been marked as a duplicate of this bug. *** @Adam - how to install this? 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. (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 (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 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. (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. 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 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. 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. 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. (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! |