Description of problem: When /etc/grub.d/30_os-prober is scanning for systems, it finds them but then cannot find the /boot because it is not handling linux16/initrd16. Manually edit a systems grub.cfg to change some linux16/initrd16 to linux/initrd and then another systems running 30_os-prober will find that system. Sigh, here we go around again. I will try to get the time to look into this. Version-Release number of selected component (if applicable): os-prober-1.58-7, grub2-2.02-0.3 How reproducible: everytime
Hi Gene! :) This bug is related to bug #1051632 and the fix should work for both cases. It needs a fix in both os-prober and grub2 package since grub2 uses linux/initrd for loading kernel/initramfs always. The fix should: 1. os-prober should detect menu entries which uses any of linux/linux16/linuxefi and initrd/initrd16/initrdefi (probably any linux*/initrd*). 2. os-prober(actually linux-boot-prober) should also output the info about proper loading of kernel/initrd. 3. grub2 should parse the new output and use the proper command to load kernel/initrd.
I have been busy testing my btrfs update for grubby and am doing lots of installs and kernel updates. If you have patches for os-prober and grub2, I will be happy to test them. See https://bugzilla.redhat.com/show_bug.cgi?id=1108296 It is possible that fixing this problem I found where to operands for the kernel are not being updated.
I was looking over to 30_os-prober code and the "easiest" solution may be for linux-boot-prober to return more information. So instead of just the operand for the kernel and the initramfs file, it could be something like "linux16=<>" For example, linux16=/root2/boot/vmlinuz-3.11.10-300.fc20.x86_64 for the case of rootfs on a btrfs subvol with /boot a directory. An updated version of os-prober and grub2 are going to need to be in sync or really strange things are going to happen.
Created attachment 908186 [details] add support to return kernel and initrd type This patch adds support to linux-boot-prober (40grub2) to return the kernel type (linux/linux16/linuxefi) and initrd type (initrd/initrd16/initrdefi). This update is used by the patch submitted with bug #1108296
Test the updates. Updates grub2-2.02 and os-prober rpms are available here: http://czarc.org/fedora/repo/21/
Thanks Gene. I'll try to test them ASAP.
Gene, I got doubts if this is a correct approach. Should os-prober tell grub2 how it should load kernel/initrd, or should grub2 itself decide about it? Isn't it possible that the probed grub.cfg is created for a BIOS boot setup and the grub for which we are creating a configuration file uses efi mode (or vice versa)? For EFI that would be easy. The same way that 10_linux decides to use linuxefi/initrdefi instead of linux/initrd, it can decide in 30_os-prober too. (I have not seen grub scripts to generate linux16/initrd16 at all! Are they ever automatically generated?). What do you think? We might need to get in touch with grub people about it to see which solution is more appropriate.
I believe that the patch for os-prober is correct ... it is just passing along what is used on the specific system. Whether you can have a multi-boot bios and efi systems is problematic in my opinion. But, os-prober is only acting as an information provider. As far as grub2 and 30_os-prober is concerned, it was my decision to use what is on the specific system and that may not be the correct approach. I will take a look at 10_linux. BTW, I find it interesting that 30_os-prober generates all those submenus when GRUB_DISABLE_SUBMENU=true is specified in /etc/defaults/grub. Is this a bug or a feature?
Patch is valid for os-prober-1.58-10 and is a problem in Fedora 21. See the other half of the problem in BZ#1108296 where there is a patch for grub2-2.02 Either patch can be applied "first" as broken is still broken ... the fix takes both patches. The patch simply provides some addition information so the /etc/grub.d/30_os_prober can do the right thing.
I've applied part of the fix (parsing grub2 entries), but the output format is not changed. I think it's up to grub to decide what kind of entries it should generate.
os-prober-1.58-11.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/os-prober-1.58-11.fc21
Package os-prober-1.58-11.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 os-prober-1.58-11.fc21' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-13617/os-prober-1.58-11.fc21 then log in and leave karma (feedback).
(In reply to Gene Czarcinski from comment #8) > BTW, I find it interesting that 30_os-prober generates all those submenus > when GRUB_DISABLE_SUBMENU=true is specified in /etc/defaults/grub. Is this > a bug or a feature? That's a grub bug.
os-prober-1.58-11.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.
So I did some looking into this. The case of non-EFI vs. EFI seems a bit icky and weird and I don't really want to give an opinion on it yet (though it seems unlikely to me that we'd ever want to 'translate' an EFI boot entry into a non-EFI one, or vice versa - I just can't see where that'd ever be a thing that would work out well. OS installs aren't generally agnostic as to whether they're booted UEFI-native or BIOS-native.) However, I think Chris is right about the linux / linux16 case, Hedayat. This is effectively a configuration choice. It is not something a configuration generator can figure out from first principles. What 'linux16' vs. 'linux' actually *does* is use grub's 'legacy' 16-bit Linux loader rather than its newer 32-bit Linux loader. See: http://git.savannah.gnu.org/cgit/grub.git/commit/?id=a9368fd30c6d6020e367cabf338d9222374116ff https://lists.gnu.org/archive/html/grub-devel/2009-03/msg00289.html https://www.gnu.org/software/grub/manual/html_node/GNU_002fLinux.html https://www.gnu.org/software/grub/manual/html_node/linux16.html This is effectively an issue of site or distribution configuration/policy. Fedora (well, really, RHEL) has a policy of preferring the 16-bit loader, due to http://bugzilla.redhat.com/show_bug.cgi?id=880840 (for the benefit of non-RH folks, that bug is basically a case where an RH customer encountered one of the corner cases where they have a problem when booting with the 32-bit loader because some of their hardware relies on a BIOS feature - EDD in that case - that the 32-bit loader does not support, as the grub manual links above briefly mention). It is reasonable to treat the use of 'linux16' as a configuration choice that has been made either by a distribution or by a site admin. Particularly in the latter case, os-prober should clearly make available the information that this configuration choice has been made, because that is information an os-prober consumer may need/require. The choice of 16-bit or 32-bit loader for a given entry isn't one that is *entirely* dependent on, say, the version of grub the configuration is being generated for, or whatever. In the specific case of grub2-mkconfig, it makes sense to me that grub2-mkconfig should not impose the distribution's policy about 16-bit vs. 32-bit loader when writing an entry to boot an existing OS based on its own configuration, because it's reasonable to assume the entry written in that OS's own configuration actually *works*. The upstream change from 16-bit by default to 32-bit by default happened sufficiently long ago that I think we can reasonably assume any existing grub2 configuration which specifies 'linux' expects that to mean 'the 32-bit loader', not 'the 16-bit loader'. Therefore we should not re-write such entries to be 'linux16' entries, but should write them to use 'linux'. Similarly, if an existing entry specifies 'linux16', we should respect that and write our entry based on it to use 'linux16' also.
I've filed https://bugzilla.redhat.com/show_bug.cgi?id=1161749 as a new bug requesting os-prober provide the information as to which loader invocation was used, with reference to #c15 here for justification.
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. Please release the updated os-prober for Fedora 20 too.
If it uses linux/initrd rather than linuxefi/initrdefi, then it is fixed in grub2 rather than os-prober. But, is your CentOS using initrdefi/linuxefi entries (Is it installed in EFI mode)? Currently, we do not support booting a BIOS OS from EFI grub or vise versa (and I don't know if it works).
Hedayat Vatankhah #18: The CentOS 7 installation is up-to-date as of yesterday. It is a UEFI installation. Its /boot/efi/EFI/centos/grub.cfg uses initrdefi and and linuxefi. I boot CentOS 7 by interrupting Fedora's grub2 to get to the menu, selecting the CentOS entry, editing it to use initrdefi and linuxefi, and running the revised entry. /boot/efi/EFI/centos/grub.cfg (created by CentOS but not currently used) does not contain entries for Fedora 20. I'm not sure why, but that surely isn't a Fedora bug. As to whether the Fedora 20 bug I'm experiencing is in os-prober or grub2, I have no idea. I guess I said "os-prober" because that seemed to be what was proposed in this bz but I admit to not understanding the whole thing. Is there some experiment you'd like me to try?
Funny thing. I manually ran grub2-mkconfig under CentOS 7 and did get entries for Fedora 20, but they used the linux/initrd commands, not linuxefi/initrdefi. So it looks as if whatever the bug is, it is in CentOS 7 and Fedora 20. (Remember that the automatically created and maintained /boot/efi/EFI/centos/grub.cfg has no entries for Fedora 20. I assume that that is something to do with grubby. The CentOS installation came first, before the Fedora 20 installation.)
Interesting! Actually, I was expecting F20 os-prober to not found your CentOS installation at all!!, and this is what this bug is about. :P (F21 one should be able to do so). However, currently os-prober finds an OS but it is grub2-mkconfig which decides about using initrd or initrdefi for booting the OS; so, if you have an entry for CentOS but it should use linuxefi/initrdefi rather than linux/initrd then grub2 fix (bug #1108296) should be back-ported to F20.