No, I was talking about using shift-page to scroll up. Bash history doesn't depend on the kernel in any way; scrolling does. On any kind of xterm, you can scroll using the scrollbar, but on a Linux console, you used to be able to do it too. Not being able to go back and look at output is crippling when you've had boot problems as I recently did. How are you supposed to diagnose problems if the relevant output is out of reach?

Using the Linux Serial Console https://www.kernel.org/doc/html/late...l-console.html

That looks absolutely fantastic. I'd certainly like to try it. But the instructions seem to assume a static device directory where you can create a permanent /dev/console node. How does that work with udev?

Scrolling up still works using the "vga = normal" console (as listed in /etc/lilo.conf). Also, to keep the kernel from switching to some other mode of console I think it is necessary to specify "nomodeset" on the "append" line (in /etc/lilo.conf).

When I found this I had recently installed Slackware 14.2 on a fileserver which is intended to run headless, and has no GUI software installed. The kernel is 4.4.240 64bit.

2 members found this post helpful.

Ah, that may be it then. I have an Intel framebuffer console though I didn't ask for it. It starts out as efifb and then switches to Intelfb.

I'll try specifying vga and report back.

PS: just checked. I had "vga=791". I'll change it to "normal" and add nomodeset.

nevermind

I just tried this in 14.2 with a 5.11.5 kernel, and it worked even there. (And startx worked but used the vesa driver instead of the usual intel one.)

I think that all of the computers I tend are so old as to not have the EFI system, or still have functional code to boot in the old method. In any case, I am not familiar with the EFI system. For all I know, it may be that the EFI system will not permit using "vga = normal".

Most of the computers I tend use the Intel i915 module, and for years problems have existed. I do not know whether the fault is in the hardware or the module's software or an incompatibility between the two. In any case, in my attempts to stop these computers from locking-up I have found the version of X currently in 14.2 expects for the "inteldrmfb" to be in use. For a while I attempted to get X to work in the manner used before a framebuffer was in vogue; this was several years ago, and I do not remember what prevented this. The problems still exist; there is something wrong in the i915 area; using windowmaker (instead of Xfce) reduces the severity of the problem.

Well, that didn't work! Using both "vga=normal" and "nomodeset" gave me the worst of both worlds. The console still wouldn't scroll and X wouldn't load either. That seems to be something new btw. On older systems, "nomodeset" only affects booting but in -current, it locks the console permanently into vga mode. Though, on reflection, that may be because X in -current launches on the same console that you are currently on and not a newly created one.

If I remove "nomodeset" from the command line and reboot, X works again, but it still won't scroll.

But let's look on the bright side. I have my four penguins back again. I really missed those! And if I reboot from this version, it usually goes all the way without halting anywhere, whereas I haven't been able to reboot from 14.2 for ages without having to power-cycle at some point.

1 members found this post helpful.

You're talking about stuff over 8 years old at least if it doesn't have EFI. Received wisdom is/used to be not to use 'nomodeset' because it nobbles X. Software has progressed past the point that it needs a lot of hand holding to the point where it's pretty good at looking around and checking what's there to work with. Try specifying nothing in console. In X, use the 'modesetting' driver. The 'intel' driver has been superceded.

Hi Hazel,

I wonder whether the EFI system is not compatible with the setting "vga = normal", or if the video 'card' in your computer does not have the firmware for VGA mode? And consequently ignored the setting, and started up using "efifb", and this frame-buffer does not have the ability to do scrollback?

When I was installing Slackware64 14.2 on the fileserver I mentioned earlier, I found:
(A) Specifying "vga = normal" and nomodeset in /etc/lilo.conf gave me the 640x480 console which I expected, and I was surprised to see it had the scrollback feature.
(B) Specifying "vga = 791" and nomodeset in /etc/lilo.conf gave me the 1024x768 console which I expected, but I was disgusted to find scrollback no longer worked. Looking in /var/log/messages I was surprised to see the console was using vesafb, which I had not previously known was a possibility for the console.
(Note, this server was made in 2009.)

I tested the server only with nomodeset in /etc/lilo.conf, because I did not want any problems related to the i915 module.

I had vga=791 too and got a non-scrolling console. But using vga=normal doesn't seem to make any difference on my system, as shown in my post 219.

In practice it doesn't matter any more because I don't usually use the Linux console once I've got X working.

Personally, I'd recommend using no video instructions. The kernel module driving a vga console look after that stuff.

Hi business_kid,

I remember a few months ago there was a thread on LQ about this, and I was quite interested. If I remember correctly, it was said an easy way to prevent X from using the Intel software was to remove the xf86-video-intel package.

Well, I have a small laptop (running Slackware 14.2 32bit) I took out of service because of the random crashing which seems to be related to something about the i915 module. So, I removed the xf86-video-intel package, and found that X would not start. I have not yet spent any time diagnosing the problem, because of other tasks of higher priority... Someday, if I can figure this out, then perhaps I can employ the method on all the other computers I tend which have Intel video 'cards'.

Hello again hazel
I don't know if my video driver makes any difference in this, but after "slackpkg upgrade-all" yesterday (maybe before as well, never checked) both Yakuake and Konsole Shift-PageUp just fine for me. I tried it on an extremely long compile, actually one I knew would fail before completion as wine-staging takes many minutes to complete, but I knew the staging patches for wine 6.4 are not out yet so it would cease after just 40 seconds or so. In any case it was long enough that I had to hit Shift-PageUp at least 10 times to get to the top, but it did. Could it be some config?