Control: fixed -1 6.12.5-1
Hi,
Looks like there are other users reporting that they can reproduce the
issue in the systemd bug.
The workaround of removing quiet or adding TERM=dumb to the kernel
cmdline works for me.
It is probably worth moving the Debian bug over to systemd versions
257~rc1, 257~rc2, 257~rc3 and 257.
Chee
On Tue, 2024-12-10 at 18:57 +0100, Uwe Kleine-König wrote:
> Hello,
Hi.
> On Tue, Dec 10, 2024 at 12:08:17PM +, Scott Ashcroft wrote:
> > Still happening with 6.12.3.
> > Pressing a number of keys (it doesn't need to be enter) will get
> > the
> >
Still happening with 6.12.3.
Pressing a number of keys (it doesn't need to be enter) will get the
boot moving again.
Adding any sort of debug also seems to mask the issue.
I suspect it could be a change in systemd which triggered it.
Could it something needing more entropy in /dev/random which mash
> Could you boot a working kernel with memblock=debug on the kernel
I'm not seeing any 'memblock: Could not reserve boot range' lines.
See attached.
Tried the patch anyway and it didn't work.
Cheers,
Scott[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys
The patch makes no difference.
Is there anything else I can do to help figure this out?
Cheers,
Scott
I'm still seeing the same failure in efi_call with 4.4.4-1 and 4.5-rc4
and 4.5-rc7 from experimental on an HP x360.
It has the INSYDE Corp implementation of EFI which seems to be a common
factor.
I'll try build the kernel with the patch suggested and test that.
Cheers,
Scott
7 matches
Mail list logo
