Well, it won't be because it's buggy. See above.

Well, I read that too

Anyway, without the glitch that would be nicer, indeed. Sorry I have no knowledge to help on this.

Tried but keystrokes in help for scrolling seemed to do nothing at all.

Ctrl-A then Esc and "Copy mode" should appear at the bottom of the screen and you can use the arrow keys or Page Up and Page Down to scroll around.

Press Esc again to exit "Copy mode"

1 members found this post helpful.

Not what I saw at bottom but seems to work few/several pages. Thanks!

Have spent the last week trying to get Slackware 15.0 and the 5.15.19 kernel up.
I have a patch made for the previous kernel, that would put the console scrollback in the console again.
But now the relevant console files are gone.

I have to use the consoles most of the time. They are more reliable than X11.
X11 is prone to failure, and the only way to get out of X11 lockup is to use the console and start killing processes.
I can get the X11 lockup several times in one day. It is part of X11 program development.
The docs for the widget tools are horrible, and all widget programming is really done by trial and error.

I develop free programs. Debugging some of them requires using the console constantly because the X11 is at the point
of failure. Anything that is required for the debugging has to be running in a console. Only the test program and gdb
are running under X11. Those can lockup at any time, making X11 unusable.

Any investigation as to why the X11 lockup occurred is done in that console, and almost anything is going to run over multiple pages.
Some of these processes just dump messages to the screen, you get no choice in the matter. You cannot after-the-fact try
to run that output through some pager.

This is not an invitation for others to second-guess my development system. Nor do I think anyone should second-guess anyone else's
use of the console. Doing this program development (for free) is difficult enough already. What is the point of trying to minimize
this problem by suggesting lame work-arounds. We have gotten to use this method, because the other ways we have tried did not work,
or had some conflict with the test program. I have one program where I have to run a second debugger in a second X11 session, just
because it does not work any other way. We already have multiple conflict issues to deal with, we need all the flexibility
in this that we can get.

Having the console scrollback was so useful, that I immediately noticed that it was not working, and
I had not gotten more than an hour into the installation process.

I have read the Torvalds post cited above. I just makes my blood boil as it is so full of nonsense.
The console did not need a maintainer, as it was not getting broken with every other release.
Maintainers are attracted by having something that needs constant fixing.
One bug showed up, and someone stepped forward with a patch.
Then on a "whim", its lets rip the whole thing out.
The idea that some official maintainer would have changed anything in this is a load of nonsense.

In the last driver change where a "feature" was yanked out from under me, it was the dammed maintainer
that decided that "no-one" was using that device feature, and it was OK for him to change it.
Even after several notifications and my sending an explicit patch file, that maintainer still would
not fix the problem. "His" fix looks OK to him, and he does not care past that point.

If I need a feature of the kernel, then how am I supposed to guard it against being changed?
How many hundreds of features of the kernel do I rely upon every day? Am I supposed to arrange
for someone to guard all those features against the chance that someone with a "whim" will decide
to unravel it all to satisfy their limited expectations of how it is being used.
Which features do I need to guard, and how am I to know which are under threat ahead of time?
Are we all supposed to have representatives to guard our interests in certain kernel features?
Do we really want to have some host of representatives, protecting our interests, as that will resemble the US government.

I was a maintainer once. It became a battle to maintain existing capabilities. Those wanting change
had their ways of forcing that change. I was just there to be used to do the dirty work.
It was either I did their dirty work, or they would just do it themselves, worse.

I cannot see how to fix the current console driver anymore, so what would be be point of trying
to be the maintainer of the console scrollback.

A proper way of doing this would have to made the scrollback a compile option, and left it
to the users to decide. The point of just trashing it and waiting for complaints, is that
the complaints come later, and then later they can just ignore the complaints.
Requests for fixing this have been sent in, and there is no sign of restoring the scrollback,
even as an option.

7 members found this post helpful.

Volunteer to maintain it.
Subscribe to the Linux Kernel Mailing List.
Imagine what it must be like to do all of that work on a project which you don't charge people to use... but they complain anyway.

Indeed I configure my machines for terminal use, starting X using traditional 'startx' if necessary.

Guys: the scrollback buffer, fortunately, is still available if you won't use framebuffer neither KMS — but I wonder for how long… if one day they decide to „improve” also this…

Screen doesn't have enough scrollback to see all 'ps aux': what can one do?

There was a recent thread which took me on a voyage of discovery about text consoles.

Scroll back has been removed from the frame buffer, but is still present in the pure text console. If you want to use it, you can. The way to do it is by disabling the frame buffer on boot.

The only catch is that you have to use legacy booting with LILO, because you cannot disable the frame buffer if you use UEFI.

See these two posts for more information:

https://www.linuxquestions.org/quest...ml#post6367692

https://www.linuxquestions.org/quest...ml#post6367683

4 members found this post helpful.

A console on serial port may help. Probably needs virtualization (e.g. with qemu) if the bare metal system does not have one.

Don't "PageUp" and "PageDown" keys still work?

You mean shift-PageUp and shift-PageDown? No, in later kernels that feature has been removed, at least if you use KMS or framebuffer.

regards Henrik

Ahh that explains it, mostly. I totally avoid KMS, but I'm uncertain about framebuffer since I have both CMS Legacy boot systems and EFI, which has it's own species of framebuffer. Thanks, Henrik.