Control: tags -1 + moreinfo Hi
On Thu, Mar 20, 2025 at 09:35:30AM +0100, zebonaut wrote: > Package: src:linux > Version: 6.1.129-1 > Severity: normal > X-Debbugs-Cc: zb-pub...@mnet-online.de > > Dear Maintainer, > > after a fresh installation from a netinst usb flash drive, version > debian-12.5.0-amd64-netinst.iso, > the system did not boot because it went into a loop that repeatedly failed to > start job > systemd-journald.service. > > I managed to eventually boot the system by telling grub not to boot using > linux-image-6.1.0-32-amd64 (default) but > linux-image-6.1.0-18-amd64 (chosen manually), > which was the second choice still available in grub's start-up menu. > > I am aware that the kernel may not be the package that is the actual root > cause. However, I chose > linux-image-6.1.0-32-amd64 as the affected package because choosing an older > version made the > problem disappear. > > I believe this "fix" was available because my netinst iso was already a bit > older and during the > installation, a newer kernel version was installed and used as a default by > grub. > > When re-installing from a new netinst image > (debian-12.10.0-amd64-netinst.iso), > linux-image-6.1.0-32-amd64 was the only option available to grub, and I could > not use > an alternative version to start the system. > > This was displayed during the boot process: > > [ *** ] Job systemd-journald.service/start running (1min 19s / 1min 19s) > [ *** ] Job systemd-journald.service/start running (2min 49s / 2min 49s) > [ 189.455547] systemd [1]: systemd-journald.service: State 'stop-sigterm' > timed out. Killing. > > This continued in a loop-like fashion until it repeatedly [FAILED]: > > [FAILED] Failed to start systemd-journald.service/start - Journal Service. Two questions: - Can you please post the kernel log/dmesg from a boot with 6.1.129-1? If the system is not accessible, we might be lucky getting some information by using the netconsole[1]. [1]: <https://www.kernel.org/doc/html/latest/networking/netconsole.html#netconsole - Since you have a known working Debian revision, and a bad one, can you bisect first the Debian revisions to find the one which introduces the problem? Once that is done we might need you to bisect the upstream versions between those, but let's first try to determine n which Debian revision the problem appears. Regards, Salvatore
