Description of problem: Sometimes (most of the time) I believe that os-prober and associated code should be abandon. There has got to be a better way to support customization and multi-boot. Peasonally, I use 40_custom with hand-crafted files to chainload configfiles. Anyway, the code currently in rawhide is broken. I have identified two problems: 1. Bother linux and initrd rather than linux16 and initrd16 are used. Instead of just forcing linux16/initrd16, 30_os-prober should look at the secondary system and use linux/initrd or linux16/initrd16 that the system uses. 2. The operands for linux are missing. The result is that sometimes you can boot and sometimes not. Version-Release number of selected component (if applicable): grub2-2.02-0.3, os-prober-1.58-7 How reproducible: everytime
A related but different problem is that os-prober's linux-boot-prober cannot handle linux16/initrd16 and produces no output for those menuentries. Sigh!
Created attachment 908187 [details] add support specifying linux and initrd type in 30_os-prober To function properly, this patch needs the patch sumitted for bug #1108344.
Test the updates. Updates grub2-2.02 and os-prober rpms are available here: http://czarc.org/fedora/repo/21/
I will fix os-prober soon. Will grub2 be fixed soon too?
Since 30_prober and os-prober flat do not work currently without the grub2 & os-prober patches, I consider that this problem is a Fedora 21 alpha blocker. This should be fixed sooner ratrher than later. But that is just my opinion ;)
Created attachment 909733 [details] v1.1: add support specifying linux and initrd in 30_os-prober Includes bugfix to limit kernel options to parameter 6 returned by linux-boot-prober.
The patch is still valid for grub2-2.02-0.8 and is a problem in Fedora 21. See the other half of the solution in bz#1108344 where there is a p[atch for os-prober. Either patch can be applied first as it takes both to implement the fix and currently, broken is broken. To see the problem: 1. install Fedora21 on a system (real of virtura). 2. Install a second installation of Fedora 21 in different partitions. 3. Upon bootup of installation 2 (last installed gets the mbr) and note that the grub2 menu does NOT have the other system entries.
Created attachment 951005 [details] patch to emit linux16 etc. Well, since Hedayat didn't accept the part of the os-prober patch that actually tells us what stanzas it found in the foreign config file, I had to implement this a different way. I think with this patch we should generally be right, but the case where the running OS is booted via EFI and the foreign OS is booted via the CSM will be wrong on x86 platforms.
Yes, Hedayat believes that os-prober should not be telling grub2 what to do and the grub2 developers will not take ownership of os-prober. To be honest, I believe that os-prober is a bad idea and chaining configfile is far better. I do not use os-prober any more.
grub2-2.02-0.10.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/grub2-2.02-0.10.fc21
Package grub2-2.02-0.10.fc21: * should fix your issue, * was pushed to the Fedora 21 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing grub2-2.02-0.10.fc21' as soon as you are able to, then reboot. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-13799/grub2-2.02-0.10.fc21 then log in and leave karma (feedback).
Actually, I wonder what is the correct entry for the case when one OS is installed in EFI mode and the other in BIOS mode. When the grub is loaded in former mode, should it try to load both kernels in EFI mode using linuxefi (was it?), or should it try to boot the BIOS mode kernel using linux/linux16? I guessed that the latter wouldn't work, and both of them should be loaded using linuxefi. If not, so it would be beneficial to provide such info by os-prober. However, the output format should be general enough (e.g. a boot mode field which contains something like this: EFI, BIOS_16, BIOS_32) so that it can be provided for other OSes too. So, if the info is really relevant, I'll add it in one way or the other.
grub2-2.02-0.10.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.
Note the fix for this had a small bug and doesn't work in -10. In grub2-2.02-0.11.fc21 (in Koji currently, should be in updates-testing soon) it should work correctly. See https://bugzilla.redhat.com/show_bug.cgi?id=964828#c23 .
Couple of notes here: 1) I'm curious as to what Gene meant by "2. The operands for linux are missing. The result is that sometimes you can boot and sometimes not.". It seems like he's suggesting that Fedora's grub2 (non-UEFI) can't/couldn't boot entries of the form 'linux (somekernel)' (as opposed to 'linux16 (somekernel)'), but from my look at the source that doesn't seem like it can be right. The introduction of 'linux16' happened years ago upstream (2009), the only thing we changed in Fedora/RHEL recently was to start using 'linux16' rather than 'linux' *by default*, but I don't see that Peter ever patched grub to not work with plain 'linux', which would be a pretty weird thing to do. There are implications both here and in https://bugzilla.redhat.com/show_bug.cgi?id=964828#c12 that somehow plain 'linux' didn't work, but I *think* they must be mistaken. Perhaps they got confused by UEFI reports (the 'linux' command really doesn't exist in our grub2-efi). 2) Peter - when you say "I think with this patch we should generally be right, but the case where the running OS is booted via EFI and the foreign OS is booted via the CSM will be wrong on x86 platforms." - is there actually anything *right* we can do there? I thought it's not possible to do a BIOS boot from a UEFI bootloader. Theoretically I suppose we could possibly do a UEFI native boot of an OS that was intended to be a BIOS native install - it seems like that might work to at least some extent - but it'd probably get very confused when it tried to update its kernel, and I'm not sure we actually want to do that. Is the right thing to do there just to try as hard as possible not to generate entries for the other type of install at all?
OK, what I meant is that /etc/grub.d/30_os-prober does not have sufficient information to determine if the other installation used linux/initrd (32 bit) or linux16/initrd16. It could be that it does not matter and linux16/initrd16 will work for any "recent" Fedora release. If that is the case, then just go with Peter's solution of forceing linux16/initrd16 because it will work. If there is some really weird corner case the a user can disable os-prober and create a simple /etc/grub.d/40_custom menuentry which chains grub2/grub.cfg files.
Gene: my reading is that 99% of the time a system that boots with 'linux' will boot with 'linux16', and vice versa. The things the 16-bit loader has that the 32-bit loader doesn't are at least (briefly) documented - support for some 'BIOS features' (APM and EDD are mentioned specifically), and for the vga= parameter (32-bit loader requires gfxmode= and can translate some common vga= parameters into gfxmode= ). It's systems that need the 'BIOS features' that need linux16 rather than linux, AIUI - the bug report that caused the switch in Fedora/RHEL was from a RHEL customer who had hardware whose storage did not work with the 32-bit loader because it needed EDD. I think it would be 'most correct' to preserve the original directive - as explained in https://bugzilla.redhat.com/show_bug.cgi?id=1108344#c15 - but 99% of the time it's not actually going to cause *problems* to 'translate' 'linux' into 'linux16' or vice versa.
I seem to have this problem on Fedora 20. I mistakenly wrote it up in https://bugzilla.redhat.com/show_bug.cgi?id=1108344 (see #17 through #21). Hedayat Vatankhah says that this bz is the correct one. Recap: On Fedora 20, on a UEFI system, grub2-mkconfig builds grub entries for CentOS 7 that use initrd and kernel commands where the initrdefi and kernelefi are required. Fedora 20 (with all current updates) uses os-prober-1.58-8, grub2-efi-2.00-27 grub2-tools-2.00-27 grubby-8.28-1 Could someone fix this? My guess: by back-porting grub2-2.02-0.10 or better and perhaps os-prober-1.58-11 or better to Fedora 20.