Bug 1161749

Created attachment 955102 [details]
return linux & initrd "type" info

This is my original patch fitted to os-prober-1.58-11 and precisly implements providing /etc/grub.d/30_os-prober information as to what "type" is used: linux | linux16 | linuxefi and initrd | initrd16 | initrdefi

CCing pjones for info (grub2 can consume this info if os-prober provides it).

First, as I said before, if this is going to happen, it should be more general than Gene's patch. Also, if I start applying this change (which will be incompatible with original os-prober output), I'll probably start the os-prober fork (which have been discussed with Gene before, but I got busy for a while :P). 

It seems that grub legacy has always used 16 bit protocol, which is equivalent to Grub2's linux16 (At least, it is mentioned here: http://comments.gmane.org/gmane.comp.boot-loaders.grub.devel/19775); but Grub2 has always used linux/initrd to boot Grub legacy entries (they actually can't do it in the current situation, because this info is not provided by os-prober; but I've seen no complains about it either). Well, to be more fair, as Grub2 can load grub legacy config files, we should see how they handle it there: do they use 16bit protocol to load entries from Grub legacy config file or 32bit one?

Anyway, rewriting original boot entries is what we have been doing always for grub legacy entries; so at least the bug is not urgent. I'd prefer some discussion before proceeding with any fix. 

For now, I'm interested to know how does Grub2 deal with grub legacy entries. 

Then, it would be also good to know if additional information is also needed for handling UEFI/CMT boots.

"Then, it would be also good to know if additional information is also needed for handling UEFI/CMT boots."

I don't know what CMT is. If you mean CSM, then no, I don't think so.

For UEFI, I think what the information would help us with is just deciding whether to try and handle the entry *at all*. AIUI, the boot mode is set before we hit grub - once we hit grub we are irrevocably 'in' UEFI-native mode or BIOS/CSM mode. You can't somehow do a UEFI-native boot from BIOS-mode grub, or vice versa. pjones can correct that if it's wrong or too simplified, but either way...

...I think what the information would help with is filtering - when we're writing a configuration for a UEFI-native install of Fedora we probably should not add entries for BIOS-native installs of other distributions, and vice versa. Currently os-prober does nothing to help us know if another installation is UEFI-native or BIOS-native; if it provided the information as to whether the entry is 'linuxefi' or not, we would have a good/perfect (I'm not sure which) indicator.

:D Yes, that's CSM.

I absolutely don't know about CSM/UEFI case, but my *feeling* is like yours: you can't boot Fedora using linux/initrd if grub is loaded in EFI mode, and vice versa. And even if it is possible, Fedora doesn't support it now since it requires both grub2 and grub2-efi packages to be present (so that all linux/linux16/linuxefi and initrd counterparts are available). 

But, I also *feel* that it might be possible to boot the other Fedora (which was installed in CSM/BIOS mode) in UEFI mode using linuxefi/initrdefi. 

This was also one of the reasons that I decided that grub2 itself should decide about the correct command to boot other GNU/Linux OSes rather than looking at os-prober output.

"But, I also *feel* that it might be possible to boot the other Fedora (which
was installed in CSM/BIOS mode) in UEFI mode using linuxefi/initrdefi."

I think it might be possible but I'm not sure it's *advisable*, because I suspect it would then mess things up when it tried to do a kernel update. pjones would know for sure. Still, even if we wanted to do it, it would probably help to *know* we were in that case, as opposed to just adding an entry for another UEFI native install.

This message is a reminder that Fedora 21 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 21. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '21'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 21 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

I can confirm my guess now: A EFI grub should load any kernel/initramfses using linuxefi/initrdefi commands, and a BIOS grub should use non-EFI commands. I also think that it won't affect kernel updates in any way.

Anyway, I agree that it is better for os-prober to provide as much info as possible; but I consider it a feature request rather than a bug fix which would be much better if applied upstream unless we get a real use for it in Fedora.

This bug appears to have been reported against 'rawhide' during the Fedora 24 development cycle.
Changing version to '24'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora24#Rawhide_Rebase

This message is a reminder that Fedora 24 is nearing its end of life.
Approximately 2 (two) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 24. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '24'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 24 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged  change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

Fedora 24 changed to end-of-life (EOL) status on 2017-08-08. Fedora 24 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.