I run installer. After login as root I tried to scroll up terminal with shift+PgUp - it scrolled but afterthat installer stopped to respond. Like locked input - none of combinations of keys worked. Had to switch off power. Computer is Lenovo ThinkPad T430. -current was updated 10-th June. I have used mini-install iso image from AlienBob script. For sure I dd'ed image on two different pen-drives. At night I will update -current - will create iso again, and I will pick up torrent from external source, maybe image I created is broken, will see. Nice if somone would try to confirm.

I can confirm this has happened to me on at least three occasions, although I can't be more specific than that. It happened when I used cat and/or less to read a text file containing instructions.

1 members found this post helpful.

Same here!

This has never happened to me, are you sure you didn't press C-s while scrolling?

BTW, that 'logging in as root' is a joke, it was explained in the source code somewhere.

When a system appears to be locked up, the first thing I do is tap Caps Lock, Num Lock, and Scroll Lock, to see if the keyboard lights change. If they don't, then either:

A) the lights are all burnt out, or
B) the system is hard-locked

In the case of B), only a power cycle will recover things.

So, my advice is to reproduce your situation, then try tapping Caps Lock and Num Lock. Do they switch on/off?

@average_user, they're running the installer, not (I think) an installed system. And the Slackware installer frankly doesn't care what username you use to log in; it's a shell script running inside Busybox.

I know. That's exactly what I was trying to say. You just press ENTER, you don't need to 'log in'.

Yep, this bug is actually just over a year old, and no-one seems to want to do anything about it.

It's not a Slackware issue, it's a kernel bug that affects the "speakup" subsystem. Since the Slackware install kernel has speakup support built in, the installer is affected.

1 members found this post helpful.

So I have to rebuild kernel without speakup subsystem? Say I am running installer and during partitioning installer explodes - rather unpleasant scenario. Maybe just run installer for 14.2 and then to upgrade to -current? Can I run installer with older kernel? Say I would run usboot.img from 14.2 but to point it to -current? So it will de facto install -current not 14.2. It is just bad and some kind workaround is needed.

Edit:

I can confirm that I have also encountered this behaviour when installing -current on a number of systems. At the time I put it down to the relatively recent hardware in use. However, it's clear that the issue is more wide-spread than that.

This is useful information: it means that if Speakup is disabled in the kernel used on the installation media then the problem can be avoided. It's a little fiddly, but it at least provides a workaround in the context of install images I distribute.

The console crash on scroll-back is highly irritating: I am so used to being able to scroll up after booting the Slackware install media that I've triggered the crash frequently - often multiple times within 5 minutes. Since the kernel developers do not seem to be addressing this issue (for whatever reason), perhaps the default Slackware installation kernel needs to disable Speakup, with a Speakup kernel returning for those who rely on that. Scrolling the console is a well known and fundamental feature of the Linux text console, and having it crash the Slackware installation environment is very frustrating (and it isn't a good look either).

1 members found this post helpful.

Slackware is esentially one of few systems which use console-based (text) installer. Perhaps this is why kernel developers are not eager to fix this. Most distributions use graphic installers. So I think this is up to us to resolve problem. It may take very long time fix to appear. But there is no graphic installer for Slackware. What really worries me is that this seems influence only installer. On running installed system issue disappears. For me it is strange. I would rather expect this always to happen if it is kernel-related. Maybe we should try to play with kernel parameters to look for clue.

I was just beginning to wonder if there exists any kernel parameter that we could specify on the boot: prompt when the installer starts?

My first thougth was acpi=off

Edit: it is just senseless, why speakup subsystem damages console scrollback?

Ok I did something like that, first disable acpi
then press shift+pgup - kernel panics and provides backtrace. I am curious does it possible to do the same on virtual machine - it would be much more convenient to gather some information. Instead of taking shot of display.

That has nothing to do with ACPI.If you take a look at the bug report in Bugzilla (as linked earlier in the thread) you'll see that not only was the Bug/Oops captured and posted, but the offending commit was even identified and a LKML link was provided.