linux-kernel - Re: Intermittent inability to type in graphical Plymouth on UEFI VMs since kernel 6.9

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Wed, 29 May 2024 19:12:57 +0200
From: "Linux regression tracking (Thorsten Leemhuis)"
 <regressions@...mhuis.info>
To: Adam Williamson <awilliam@...hat.com>, Genes Lists <lists@...ience.com>,
 Linux regressions mailing list <regressions@...ts.linux.dev>,
 linux-kernel@...r.kernel.org
Cc: jforbes@...hat.com, rstrode@...hat.com
Subject: Re: Intermittent inability to type in graphical Plymouth on UEFI VMs
 since kernel 6.9

On 29.05.24 17:09, Adam Williamson wrote:
> On 2024-05-29 06:35, Genes Lists wrote:
>> On Wed, 2024-05-29 at 15:01 +0200, Linux regression tracking (Thorsten
>> Leemhuis) wrote:
>>>>
>>>>      cpu i9-12900K  / Raptor Lake-P [Iris Xe Graphics]
>>
>>    Sorry, this should be:  13th Gen Intel(R) Core(TM) i7-1360P
>>>
>>> Does this happen every boot or only sometimes? Could you maybe upload
>>> the full dmesg from a boot where things worked and one where only the
>>
>> For me it is every boot - the first few key strokes are accepted but no
>> asterisks are displayed - and it works fine even though fewer asterisks
>> are displayed than characters typed.
> 
> That sounds different from my case.

Hmm, bummer. That might have made things a lot easier...

> In openQA (and the one time I saw it
> live), the keystrokes do not appear to have any effect - no dots are
> echoed at all, and hitting enter does not submit the passphrase.

And no dmesg for working and non-working I suppose? Argh. :-/

> I have no idea where to send emails reporting kernel bugs. It's a very
> difficult world to penetrate

I totally agree so far.

> if you're not already in it.

Up to a point that's what I'm here for. But right now I'm a bit
uncertain who to involve. The input folks? The drm maintainers? But
without a bit more data I doubt any of them will take a closer look at
the problem.

> A proper bug tracker would make things much easier.

Not really I'd say, as the problem is the same here: someone needs to
triage bugs and assign them to developers that are willing to look into
them.

Ciao, Thorsten