Bug 1196065

Hi,

Please note this affects Fedora 22 too and it seems in only case when proprietary nvidia driver is installed. I've used nouveau driver for months and I never had such issue

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.

Hello,
I do not about others, but I have a Fedora 22 and Fedora 23 where this is still happening every time I rerun grub2-mkconfig manually.
Also this is happening on systems that do not have proprietary video drivers (one radeon, one i915).

Hi

It's also affecting me on Fedora 22, with an ATI graphics.

Still issue on Fedora 23.

Fedora 21 changed to end-of-life (EOL) status on 2015-12-01. Fedora 21 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.

Still issue on Fedora 22 and 23 too.

It's still actual on Fedora 24.

It's still actual on Fedora 25

Code in *Fedora 26* looks still like that:

---
linux_entry ()
{
  os="$1"
  version="$2"
  type="$3"
  isdebug="$4"
  args="$5"

  sixteenbit=""
  linuxefi="linux"
  initrdefi="initrd"
  case "$machine" in
    i?86|x86_64)
        sixteenbit="16"
        linuxefi="linuxefi"
        initrdefi="initrdefi"
        ;;
    aarch64)
        linuxefi="linux"
        initrdefi="initrd"
        ;;
  esac

...
---

Interestingly, I discovered that the use of linux16 is something INTENTIONAL that Fedora is patching into our grub builds, it's not actually part of the 10_linux script from upstream grub at all.

The patch to do this was checked in by pjones on 2013-10-28 and can be seen here (though a later patch further modifies the code to include the linuxefi lines):

http://pkgs.fedoraproject.org/cgit/rpms/grub2.git/tree/0099-Use-linux16-when-appropriate-880840.patch

The commit message reads:
"The kernel group really would prefer that we use the 16 bit entry point
on x86 bios machines. Resolves: rhbz#880840"

Most curious of all, attempting to view bug 880840 here in bugzilla produces a severe-looking message screen, admonishing
"You are not authorized to access bug #880840. Most likely the bug has been restricted for internal development processes and we cannot grant access." 

So, apparently the information about WHY the kernel group wants that sixteenbit switch in there is Highly Classified Information. Disappointing.

The updated URL to that linux16 patch in the Fedora grub2 tree is

https://src.fedoraproject.org/rpms/grub2/blob/master/f/0099-Use-linux16-when-appropriate-880840.patch

(In reply to "FeRD" (Frank Dana) from comment #11)
[..]
> Most curious of all, attempting to view bug 880840 here in bugzilla produces
> a severe-looking message screen, admonishing
> "You are not authorized to access bug #880840. Most likely the bug has been
> restricted for internal development processes and we cannot grant access." 
> 
> So, apparently the information about WHY the kernel group wants that
> sixteenbit switch in there is Highly Classified Information. Disappointing.

There are some open comments that summarize the above classified bug report and the rationale behind using the 16 bit entry, though:

https://bugzilla.redhat.com/show_bug.cgi?id=1108344#c15

> [..] 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

https://bugzilla.redhat.com/show_bug.cgi?id=1108296#c18

> 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

This bug is currently reported against a Fedora version which is already unsuported.
I am changing the version to '27', the latest supported release.

Please check whether this bug is still an issue on the '27' release.
If you find this bug not being applicable on this release, please close it.

Hi, can you update the version to 28? The issue is still present in the latest release.
Thank you.

Found this same issue when installing Fedora 28 via kickstart. To get the system to boot I had to manually change linux16 & initrd16 to linuxefi & initrdefi respectively via the grub boot menu editor. 

The file /boot/efi/EFI/fedora/grub.cfg is the one containing the incorrect entries. 

Once the system has booted, running the command:

grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg

rewrites the file correctly.

(In reply to John Kissane from comment #16)
> Found this same issue when installing Fedora 28 via kickstart. To get the
> system to boot I had to manually change linux16 & initrd16 to linuxefi &
> initrdefi respectively via the grub boot menu editor. 
> 
> The file /boot/efi/EFI/fedora/grub.cfg is the one containing the incorrect
> entries. 

If kickstart is writing `linux16` entries into /boot/efi/EFI/fedora/grub.cfg, then that's a different bug. This bug is only about the use of `linux16` vs. `linux` in grub boot entries. (IOW, with this bug addressed your /boot/efi/EFI/fedora/grub.cfg would've contained `linux` and `initrd` entries instead of `linux16` and `initrd16` entries, which still would be incorrect for EFI boot.)


You might be encountering an issue similar to bug 1538325.

We're now weeks from Fedora 30 release and this bug is still not fixed.

This message is a reminder that Fedora 28 is nearing its end of life.
On 2019-May-28 Fedora will stop maintaining and issuing updates for
Fedora 28. 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 '28'.

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 28 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 28 changed to end-of-life (EOL) status on 2019-05-28. Fedora 28 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.

Can we update to Fedora 30 and reopen, please?  I believe the bug / behavior is still there.  Does upstream know about the issue?

If this issue still exists in Fedora 30, it's definitely not the same issue, or even related to this old issue about how the kernel loader lines in the grub2.cfg file were being generated. 

The boot process has been completely restructured in the wake of BLS adoption, and current Grub doesn't even _have_ a linux16 module anymore:

$ sudo rpm -ql grub2-pc-modules|grep -i linux
/usr/lib/grub/i386-pc/linux.mod
/usr/lib/grub/i386-pc/syslinuxcfg.mod

It's possible, I suppose, that linux.mod is "really" linux16.mod, making it now the ONLY choice. (I honestly don't know — it's also possible that it's not, and linux16.mod is truly gone.) Regardless, even if it's the case that linux16 is now the only available kernel loader module, then simply editing grub2.cfg lines by hand (the old workaround for this issue) would no longer be effective in changing how the kernel is loaded.

All of which is to say, this report is no longer applicable to Fedora 30, and it would be best to create a new, unrelated issue for any issues with the Fedora 30 boot process. (And as far as upstream goes, the original report was never an upstream issue period. It was a downstream Fedora patch applied to the grub2 RPM builds, and only affected this distro.)

I can't belive... 4 years and it's still not fixed.
Really can we reopen it again for Fedora 30?

If you think you still have this problem, open a new bug report.

(In reply to Samuel Sieb from comment #24)
> If you think you still have this problem, open a new bug report.

If this is still a problem, why should should the bug be closed? :-(

But per comment 22, it sounds like the bug should be closed as fixed rather than leaving it in the crappy "CLOSED EOL".

Is it "fixed" if it went away because other things changed?  My point was more that since this bug is old and his problem is probably not this one that it would be better to just start a new one with new information and go from there.

The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days