ian_br...@mail.ru wrote at Mon, 2 Dec 2024 22:56:25 -0800
> However, having now installed systemd v257~rc3-1, the problem seems to
> have gone away, without altering the boot parameters. This is the case
> at least with kernel linux-image-6.11.10-amd64.
I cannot confirm that. The hang in with syst
Dear Salvatore,
now up to date with testing's kernel 6.11.10-1 and systemd 257rc3-1, the same
issue. In that config I saw the hang even once with my kvm virtualized system.
> Would you still as well be able to configure a netconsole so we see if
> we get more information of it
Of course, howeve
Dear Salvatore,
that seems to be a wired thing!?
No matter of temporarily within grub bootmenu e and F10 or permanently by
changing /etc/default/grub and update-grub, as soon I replace kernel parameter
quit by -- systemd.log_level=debug the system boots successfully on ever
trie. I did mor
I also can confirm that booting is not possible in testing any more: Kernel
6.11.9 and 6.11.7 and systemd v257~rc2-3 in a standard grub/efi/ext setup
without cryptofs or similar on a sata ssd (so probably better to change the
title of the thread). This happens since the upgrade which (among othe
Hi Norbert,
> But I guess you had, or some cosmic radiation induced bit switch did it
> for you on your hard disk ;-) The default for all installations is being
> on.
yeah, then lets say "maybe" or "probably" I did that, nevertheless, at least it
was a couple of years ago and I cannot remeber ;-
Hi Norbert,
thanks to your repsonse!
> Can you try/check the following:
> * In the Plasma Settings app, go to
> Display and Monitor > Compositor
> and check whether
> Enable compositor on startup
> is selected (on).
Indeed, turning that switch to on and restarting helps. Great!!!
Today all packages of plasma 5.23 migrated to testing, and it works fine in my
(libvirt) vm. However, on bare metal mesa makes problems (see my bug report
#998386), so in fact there plasma 5.23 stays unusable.
Unfortunately, mesa 21.2.4-1 shows the same problem under plasma 5.23 in
testing. The latter has finally migrated to testing with all packages
yesterday. The combination works fine within my libvirt vm, as I think, it does
not use hw accelleration there. However, on bare metal (see above) it sta
Package: mesa
Version: 20.3.5-1
Severity: critical
Justification: breaks graphical system like KDE
After updateing mesa from 20.3.5 to 21.2.4 in bookworm (migrated on October
21th to testing) my graphical KDE plasma 5.21 under x11 renders unusable. Note
plasma 5.23 is currently unusable in testi
KDE/Plasma (package dependencies) are currently completely broken under
testing. Is there currently a chance to (somehow simply) block the partial
transition of plasma 5.23 to testing (so that not related package updates are
easy)? Selectively upgrading single packages with dependencies one afte
Upon further inspection, it seems that there is something amiss with
package dependencies. After manually installing libjpeg8, the jvm
crashes no more. But now we have 2 jpeg libs, which seems odd.
ii libjpeg626b1-1The
Independent JPEG Group's J
Package: openjdk-6-jre-headless
Version: 6b27-1.12.6-1~deb6u1
Severity: critical
This is new error that occurs since the last security update of
openjdk-6-jre-headless (installed on 7/26/2013).
This fatal error crashes the jvm. The error occurred at least 3 times
in the last 24 hours on diff
12 matches
Mail list logo
