Text consoles not working in recent Rocky-8 kernels

Rocky Linux Help & Support
1

I just discovered that switching to a text console does not work in kernels newer than 4.18.0-553.97.1.el8_10.x86_64. From a graphical console, pressing Ctrl+Alt+F3 thru F6 results in an entire screen filled with little white squares, and no actual characters can be displayed. The same thing happens momentarily during shutdown when the system switches back to text mode. There is no problem during the boot sequence prior to starting the kernel. For now, I have uninstalled and excluded kernel*-4.18.0-553.100.1.el8_10.x86_64 and kernel*-4.18.0-553.104.1.el8_10.x86_64. The 4.18.0-553.97.1 kernel works fine.

I am using Intel integrated graphics (no graphics card) on my Intel i5-1260K system.

2

I noticed the same thing on my little old netbook last night. I got the text screen full of squares while it went through the shutdown.

My netbook is old and it does “stuff” slowly. (I really just use it for reading ebooks now.) It appears that the text is being printed behind the squares because I could see the progression of the shutdown as the leftmost squares turned green moving down the screen.

Yes, Rocky 8 really does on an Acer netbook.

3

So, it’s not just me. I tried upgrading my very out-of-date Rocky-8 installation on my old Lenovo laptop. (A mere 840 packages needed updating. :face_with_crossed_out_eyes: I run Fedora on that, because Rocky-8 has problems staying paired with my Bluetooth mouse. I had never deleted the old Rocky-8 installation.

Sure enough, prior to the update the text consoles were working fine. After the update, just a screenful of squares. (Carriage return displays as blank.) I tried with several graphics server and desktop options – no difference. I’m surprised I’m not seeing complaints about this elsewhere.

4

I see it also on shutdown. Intel HD Graphics 4600.

5

What is your output from the following command example:

~# locale
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=

and:

~# cat /etc/vconsole.conf 
KEYMAP="us"
FONT="eurlatgr"

and:

~# localectl status
System Locale: LANG=en_US.UTF-8
    VC Keymap: us
   X11 Layout: us
6

locale
LANG=en_GB.UTF-8
LC_CTYPE=“en_GB.UTF-8”
LC_NUMERIC=“en_GB.UTF-8”
LC_TIME=“en_GB.UTF-8”
LC_COLLATE=“en_GB.UTF-8”
LC_MONETARY=“en_GB.UTF-8”
LC_MESSAGES=“en_GB.UTF-8”
LC_PAPER=“en_GB.UTF-8”
LC_NAME=“en_GB.UTF-8”
LC_ADDRESS=“en_GB.UTF-8”
LC_TELEPHONE=“en_GB.UTF-8”
LC_MEASUREMENT=“en_GB.UTF-8”
LC_IDENTIFICATION=“en_GB.UTF-8”
LC_ALL=

cat /etc/vconsole.conf
KEYMAP=“gb”
FONT=“eurlatgr”

localectl status
System Locale: LANG=en_GB.UTF-8
VC Keymap: gb
X11 Layout: gb

7

Looks OK, I’ll create a VM now to see if I can replicate.

8

Hmm, I’ve not been able to replicate the issue in a VM running on KVM. I’m booted into kernel:

[root@rocky8 ~]# uname -r
4.18.0-553.104.1.el8_10.x86_64

and my console looks like:

Screenshot from 2026-02-17 11-03-30
Screenshot from 2026-02-17 11-03-301280Ă—875 23 KB

even on booting/rebooting/shutdown I can see everything. At first I thought it was maybe due to locale configuration or missing fonts. But since I have no font or ttf package installed on a minimal installation it’s probably nothing to do with either of those options.

Might be worthwhile opening a bug report - more info here: Reporting Bugs and RFE's - Rocky Linux Wiki

9

@ iwalker My output from “locale”, “cat /etc/vconsole.conf”, and “localectl status” is just like yours.

I do see the problem in a Rocky-8 VM just updated to kernel 4.18.0-553.104.1.el8_10.x86_64 running on the same host where I discovered the problem.

On all my systems (host, VM, laptop) I can boot directly to multi-user mode (and without the “rhgb” boot option) and still see the problem on all text consoles except the first, which works correctly. If I boot my laptop to Fedora-42, there is no problem with the text consoles, but that is running a much newer kernel (6.18.9-100.fc42.x86_64).

10

Ah good catch, yeah I just fired up my VM and checked those consoles and saw the same. Urgh. I’ll see if I can figure out why the difference.

11

Same happening on rhel8 also, so it’s not unique to Rocky.

12

If you report it as a problem in RHEL8, that will probably get more attention than me reporting a problem seen in Rocky-8.

13

Interesting, this thread on linuxquestions.org looks like the same problem (since corrected) on a Debian system.

14

Looks like they already know about it after fixing an fbdev issue: 2419902 – (CVE-2025-40322) CVE-2025-40322 kernel: Linux kernel: Information disclosure and denial of service via out-of-bounds read in font glyph handling

15

Incidently, also installing packages like terminal-fonts-console from EPEL and then specifying these in /etc/vconsole.conf doesn’t help either - and I’ve tried a lot of others as well. The white blocks do change to another character, but that’s about it. So it will require the fix to be made within the kernel which is most likely what happened with the Debian system.

So for now, all we can do is wait until upstream fix it. Or alternatively, use kernel-lt or kernel-ml from elrepo.

EDIT:

Yes, kernel-lt from elrepo does work fine for all tty1-6 consoles.

1 Like
16

Still not fixed in kernel-4.18.0-553.105.1.el8_10.x86_64 .

17

Nope, and not fixed in 4.18.0-553.107.1.el8_10.x86_64 either. From the link I posted earlier, people are asking about it, so have to wait until they post about it as fixed in that link.

As mentioned earlier, you can use elrepo and install kernel-lt or kernel-ml which works and would at least allow you to use your system correctly until RH fix it.

Just posting, still not fixed doesn’t really help anyone since we know that anyway and we can see that in the RHEL link I posted.

18

If you want to get it fixed quicker, report the bug here: My View - Rocky Linux BugTracker - the previous link I posted was the WIKI which explains more on what detail is required.

The Rocky team would then look at it, obviously find what we already have in this forum thread that it’s a bug upstream and they would then most likely report it upstream. That’s about the only way it’s going to get fixed quicker when things are reported in the appropriate place.