Control: retitle -1 initramfs-tools-core: Please depend on logsave
On 2019-07-23 22:37 +, Colin Booth wrote:
> Package: initramfs-tools-core
> Version: 0.133
>
> The functions file shipped with initramfs-tools-core version 0.133 and
> earlier contains a call to logsave(8) in the _checkfs_once
Processing control commands:
> retitle -1 initramfs-tools-core: Please depend on logsave
Bug #932854 [initramfs-tools-core] Missing dependency for initramfs-tools-core
Changed Bug title to 'initramfs-tools-core: Please depend on logsave' from
'Missing dependency for initramfs-tools-core'.
--
93
Processing control commands:
> reassign -1 e2fsprogs 1.45.3-1
Bug #932881 [initramfs-tools] add dependency on logsave
Bug reassigned from package 'initramfs-tools' to 'e2fsprogs'.
No longer marked as found in versions initramfs-tools/0.133.
Ignoring request to alter fixed versions of bug #932881 t
Control: reassign -1 e2fsprogs 1.45.3-1
Control: forcemerge 932861 -1
On 2019-07-24 08:32 +0300, Aleksi Suhonen wrote:
> Package: initramfs-tools
> Severity: grave
> Version: 0.133
>
> After upgrading e2fsprogs to 1.45.3-1, computer fails to boot because
> rootfs fails to fsck. And fsck fails bec
Package: initramfs-tools
Severity: grave
Version: 0.133
After upgrading e2fsprogs to 1.45.3-1, computer fails to boot because
rootfs fails to fsck. And fsck fails because binary for logsave is
missing. Or in fact, fsck doesn't fail, but the init script reports it
did, because it cannot tell th
I can confirm this problem. After manually fsck the root partition and
still get the same initramfs shell I downgraded e2fsprogs and
libext2fs2 to the previous versions I found in /var/cache/apt/archives
(1.45.2-1) and the system booted again.
Package: initramfs-tools-core
Version: 0.133
The functions file shipped with initramfs-tools-core version 0.133 and
earlier contains a call to logsave(8) in the _checkfs_once() function.
The latest version of e2fsprogs (1.45.3-1) has removed logsave and it is
now shipped in a separate package. Thi
On Tue, 2019-07-23 at 15:56 +0200, Philipp Hahn wrote:
[...]
> - when the job / session terminates, the directory is deleted by
> pam_systemd.
>
> - but the Linux kernel still uses the CGroup to track kernel internal
> memory (SLAB objects, pending cache pages, ...?)
>
> - inside the kernel the C
Thank you for the suggestion.
I've installed 4.19.60 but that gives the same kernel panic.
Where do I start in getting some more information to track what's causing this?
On Tue, 23 Jul 2019 14:40:59 +0200 Kinky Nekoboi
wrote:
> i had and have several problems with 4.19.37-5 ... an selfbuild v
Package: linux-image-4.19.0-5-marvell
Status: install ok installed
Priority: optional
Section: kernel
Installed-Size: 97721
Maintainer: Debian Kernel Team
Architecture: armel
Source: linux
Version: 4.19.37-5
Depends: kmod, linux-base (>= 4.3~), initramfs-tools (>= 0.120+deb8u2) |
linux-initramfs
Hi Debian Kernel Team,
I'm running a TS-119P+ and a TS-219P II Qnap NAS with Debian Buster.
Both are now running a linux-image-4.19.0-5-marvell kernel.
But since my update from Linux 4.9 (Stretch) to Linux 4.19 (Buster) the
hardware clock of both boxes refuse to work.
After some digging in ke
Hi Debian Kernel Team,
I'm running a TS-119P+ and a TS-219P II Qnap NAS with Debian Buster.
Both are now running a linux-image-4.19.0-5-marvell kernel.
But since my update from Linux 4.9 (Stretch) to Linux 4.19 (Buster) the
hardware clock of both boxes refuse to work.
After some digging in ke
Package: src:linux
Version: 4.19.37-5+deb10u1
Severity: important
Bug is triggered after trying to cp --reflink a large file (30 GB).
Process 'btrfs-transacti' gets stuck at 100% CPU with no disk activity
and no visible progress (I let it run for over an hour).
All processes which require disk acc
ORTOGRAFÍA Y REDACCIÓN
CURSO INTENSIVO
Fecha: 02 de Agosto de 2019
Una buena redacción debe ser sencilla y congruente. Cualquier escrito que
sea confuso provoca invariablemente errores de interpretación. Al dominar los
principios de la redacción moderna y saber utilizar la fuerza del leng
Hi,
I analyzed the issue and the problem seems to be CGroup related:
- we're using 'pam_systemd' in "/etc/pam.d/common-session"
- each cron-job / login then creates a new CGroup below
"/sys/fs/cgroup/systemd/user.slice/" while that job / session is running
- when the job / session terminates, t
i had and have several problems with 4.19.37-5 ... an selfbuild vanila
kernel 4.19.60 with default options fixed most of them for me ...
Debian should really push a newer 4.19.y kernel for buster
Am 23.07.19 um 14:01 schrieb Terry Glanfield:
> This is still failing after an update to 4.19.37-5+d
This is still failing after an update to 4.19.37-5+deb10u1
Any clues on where to start tracking this down?
17 matches
Mail list logo
