Bug 1196065 - Grub2 is defaulting to 16 bit for 64 bit machines preventing Plymouth graphical mode [NEEDINFO]
Summary: Grub2 is defaulting to 16 bit for 64 bit machines preventing Plymouth graphic...
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: grub2
Version: 28
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Peter Jones
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 1551563
TreeView+ depends on / blocked
 
Reported: 2015-02-25 09:00 UTC by mikey
Modified: 2019-09-23 20:40 UTC (History)
25 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1551563 (view as bug list)
Environment:
Last Closed: 2019-05-28 23:48:35 UTC
Type: Bug
Shadowmaster.SM: needinfo? (extras-qa)


Attachments (Terms of Use)

Description mikey 2015-02-25 09:00:14 UTC
Description of problem:

Plymouth is not loading on 64 bit machines due to a line in /etc/grub.d/10_linux

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

The line is: sixteenbit="16"

Instead setting it to: sixteenbit=""

Will restore Plymouth. 


Version-Release number of selected component (if applicable):


How reproducible:

Run plymouth graphical boot on a 64 bit machine on Fedora 21 (possibly affects NVidia graphics drivers). 

Steps to Reproduce:
1. reboot at 64 bit machine iwth fedora 21 installed

Actual results:

Text mode boot.

Expected results:

Graphical Plymouth boot.

Additional info:

Discussion and solution links:

http://forums.fedoraforum.org/showthread.php?t=302370#5
http://forums.fedoraforum.org/showthread.php?t=301929#9

Comment 1 Laszlo Pal 2015-08-14 19:28:25 UTC
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

Comment 2 Fedora End Of Life 2015-11-04 10:01:35 UTC
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.

Comment 3 Eduardo 2015-11-04 14:32:06 UTC
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).

Comment 4 filipe.manco 2015-11-04 22:10:41 UTC
Hi

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

Comment 5 NSLW 2015-11-22 10:25:07 UTC
Still issue on Fedora 23.

Comment 6 Fedora End Of Life 2015-12-02 09:26:12 UTC
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.

Comment 7 Maksim Zubkov 2015-12-06 15:56:49 UTC
Still issue on Fedora 22 and 23 too.

Comment 8 Stanislav 2016-08-08 11:31:18 UTC
It's still actual on Fedora 24.

Comment 9 Levente Farkas 2016-12-02 06:34:01 UTC
It's still actual on Fedora 25

Comment 10 Andreas Schöneck 2017-07-24 06:40:10 UTC
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

...
---

Comment 11 "FeRD" (Frank Dana) 2017-09-08 12:40:07 UTC
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.

Comment 12 "FeRD" (Frank Dana) 2018-03-05 12:36:23 UTC
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

Comment 13 Georg Sauthoff 2018-03-10 15:23:00 UTC
(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

Comment 14 Jan Kurik 2018-05-31 09:08:53 UTC
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.

Comment 15 Eduardo 2018-05-31 16:28:45 UTC
Hi, can you update the version to 28? The issue is still present in the latest release.
Thank you.

Comment 16 John Kissane 2018-08-20 13:08:34 UTC
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.

Comment 17 "FeRD" (Frank Dana) 2018-08-22 03:36:00 UTC
(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.

Comment 18 Artem S. Tashkinov 2019-03-18 14:32:11 UTC
We're now weeks from Fedora 30 release and this bug is still not fixed.

Comment 19 Ben Cotton 2019-05-02 19:46:30 UTC
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.

Comment 20 Ben Cotton 2019-05-28 23:48:35 UTC
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.

Comment 21 Martin Dengler 2019-08-30 10:25:31 UTC
Can we update to Fedora 30 and reopen, please?  I believe the bug / behavior is still there.  Does upstream know about the issue?

Comment 22 "FeRD" (Frank Dana) 2019-08-30 15:05:12 UTC
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.)

Comment 23 German 2019-09-21 00:46:42 UTC
I can't belive... 4 years and it's still not fixed.
Really can we reopen it again for Fedora 30?

Comment 24 Samuel Sieb 2019-09-21 17:49:29 UTC
If you think you still have this problem, open a new bug report.

Comment 25 Patrick Mansfield 2019-09-23 20:17:54 UTC
(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".

Comment 26 Samuel Sieb 2019-09-23 20:40:00 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.