I'm only talking about the generic Linux virtual console, not terminal emulators such as GNOME Terminal or remote login interfaces like PuTTY.

It seems that some methods have been deprecated in newer Linux versions such as 5.19.
I tried ShiftPgUp, but it didn't work in Linux 5.19.2.
I prefer the virtual console because it needs fewer resources.

  • AFAIK in recent kernel releases Linux console became disaccelerated, so while "it needs fewer resources" it might be a whole lot slower than any graphical terminal emulator. And using screen/tmux to scroll back is a major PITA. Aug 24, 2022 at 11:41
  • That question should not IMHO be closed duplicate since OP is asking for how when the answer on the other question just tells why and OP appears to already have the knowledge of the deprecation.
    – MC68020
    Aug 24, 2022 at 11:45
  • @MC68020 the answers to the linked questions also explain how. “This question already has answers here”, not “This question is the same as”. Aug 24, 2022 at 11:46

2 Answers 2


Scroll back was removed in version 5.9 of the kernel.

You can use a tool such as screen or tmux which provide their own scroll back buffer. For example in screen, press the screen hotkey (CtrlA by default), then Esc; you can then scroll around the history using PgUp, PgDn etc. Esc will leave this mode. The default scrollback is 100 lines, you can change this by setting defscrollback in ~/.screenrc or specifying a scoll back size using the -h command-line option.

  • Why did they remove it? Sep 5 at 23:25
  • @gomennathan the explanation is given in the commit messages — follow the two links in the answer. Sep 6 at 4:33

Still running 5.4, I won't be able to test but because I do share your preference for tty (for system administration) AND since only one file (drivers/video/fbdev/core/fbcon.c) seems concerned by the patch then :

I would rush trying to revert it :

  1. Of course start backing up your kernel source tree,

  2. Take a copy of the patch from the link given here-above:

    curl -L https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/patch/\?id\=50145474f6ef4a9c19205b173da6264a644c7489 > scrollback-fbcon.patch
  3. Then actually reverse the patch; first do a dry run:

    patch -p1 -R --dry-run < scrollback-fbcon.patch

    and if everything looks OK (man patch if explanations needed for the report of the dry run), apply the patch:

    patch -p1 -R < scrollback-fbcon.patch
  4. If everything looks OK then do proceed, rebuild your kernel and please do report here the result of your experience.

  • Why not use git revert? Aug 24, 2022 at 11:48
  • @StephenKitt : because I should have assumed that OP's get the knowledge of git and also because, at the end of the day, it is not significantly easier ;-P
    – MC68020
    Aug 24, 2022 at 11:58
  • Having tried both, it seems to me that git revert 50145474f6ef4a9c19205b173da6264a644c7489 and dealing with the fallout is easier than dealing with the .rej file, but that’s subjective of course. You’re still assuming enough knowledge on the reader’s part, with patch rather than with git (the reader needs to know to add -p1, and how to understand .rej files and fix the result). Aug 24, 2022 at 12:15
  • 1
    @StephenKitt : I won't argue with you here&now on that IMHO peripheral question. My point going no further than : DO REVERT THAT PATCH ! because in my experience of linux kernels up to 5.4, (not to say running a 5.4.195 with a dozen+ patches reverted) the probability of getting whatever hard-to-deal-with rejection when the patch concerns a unique file is minimum.
    – MC68020
    Aug 24, 2022 at 12:37

Not the answer you're looking for? Browse other questions tagged .