>
> The processors shown were not necessarily the ones running the load,
> easily seen by not matching temp and speed measurements.
>
Oh yes, I agree, that's annoying. More annoying than seeing the unused CPUs
actually.
However the situation of the OP in issue
On Tue, Dec 5, 2023 at 4:56 PM Daniel Lange wrote:
> The rationale is given on top of the patch that you found
> (001_remove_lxc_special_handling.patch) and the matching commit
>
> <
> https://github.com/htop-dev/htop/commit/11318b5ef6de6b2f80186a888cd5477e0ff167bb
> >
>
> We don't have any
Package: htop
Version: 3.2.2-2
Severity: normal
Dear Maintainer,
It seems that htop 3.2.2 for Debian 12/Bookworm contains a patch which
removes LXC specific code to identify cgroup limited cpu cores.
Due to that patch, which removes that cgroup limit lookup, htop shows
all physical cores inside
Just FYI, this bug still happens on the new Debian 12 Bookworm Alpha2,
currently Debian Testing.
Solution is the same as previously stated: Disable (blacklsit) hpwdt Kernel
module.
Possibly related: https://github.com/lxc/lxc-ci/pull/487
> Can you attach the output of
> systemctl status systemd-networkd.service
> journalctl -ulb systemd-networkd.service
>
> for both containers.
>
Older 11.2 container:
root@11-2:~# systemctl status systemd-networkd.service
Warning: The unit file, source configuration file or drop-ins of
On Tue, Apr 12, 2022 at 11:33 AM Michael Biebl wrote:
>
> Hm, works fine here, i.e. I can't reproduce your problem.
> I'm running LXC on a Debian sid host though.
> Maybe it's something related to your LXC configuration/installation?
>
Hi Michael
LXC host runs on Debian Bullseye.
ck@host:~$
This situation causes a problem whenever trying to remove an old Python
version within an LXC container/guest.
E.g. after a dist-upgrade from Debian 10 to 11, running apt autoremove:
Removing python3.7 (3.7.3-2+deb10u3) ...
Removing libpython3.7-stdlib:amd64 (3.7.3-2+deb10u3) ...
Removing
The fact that a later Kernel versions work fine _could_ be because of a
hpwdt commit after 5.10:
https://github.com/torvalds/linux/commit/acc195bd2cc48445ea35d00036d8c0afcc4fcc9c#diff-994ee4b010b5c6222ad7a20e160f733401f46894b36fa3e1fb6ffbb48bedb817
I have not tested sid or a newer Kernel on our HP
Also look at the following links and compare. Might be related or even the
same as you are seeing:
https://www.claudiokuenzler.com/blog/1125/debian-11-bullseye-boot-freeze-kernel-panic-hp-proliant-dl380
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=898336
I've seen this too and documented my findings here:
https://www.claudiokuenzler.com/blog/1125/debian-11-bullseye-boot-freeze-kernel-panic-hp-proliant-dl380
(reason is the hpwdt module)
This bug is most likely a duplicate of
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=898336 where the same
I can confirm (somewhat) similar issues with the newest Debian 11
(Bullseye) and Kernel 5.10 on HP Proliant DL380 G7 servers. Boot does
sometimes work, then it doesn't work (with a freeze caused by NMI), leading
to a very unstable OS.
After disabling hpwdt (module blacklist), the problems were
> In your case you could simply remove the stanzas for enp4s0f0 and enp4s0f1
> which would leave you with just the stanza for bond1:
> iface bond1 inet static
> bond-slaves enp4s0f0 enp4s0f1
Thank you Oleander. It works with this hint (the physical interfaces
were left out of the config).
Non-working bonding config in /etc/network/interfaces:
auto enp4s0f0
iface enp4s0f0 inet manual
auto enp4s0f1
iface enp4s0f1 inet manual
auto bond1
iface bond1 inet static
address 192.168.12.4/24
gateway 192.168.12.1
slaves enp4s0f0 enp4s0f1
bond-mode 802.3ad
bond-miimon 100
Package: ifenslave
Version: 2.12
Severity: important
Dear Maintainer,
Bonding on Debian 11 Bullseye is not working, when using "bond-slaves int1
int2" syntax on the bonding interface.
However it seems to work, when defining bonding the other way around using
"bond-master bond1" on the
The same bug can also be reproduced in the current unstable (bullseye) by
the way.
apache2 2.4.46-2
libapache2-mod-perl2 2.0.11-2+b1
libapache2-mod-php7.4 7.4.11-1
perl 5.32.0-5
As there is another bug in Mageia Linux (see
https://bugs.mageia.org/show_bug.cgi?id=25411) which points to (probably)
Hi Damyan,
Thanks for your follow-up!
> It would be nice if you could share the translate.php contents (or
> a minimal version) so that the issue can be reproduced and any
> prospective fixes/workarounds be tested.
>
As a matter of fact, I was right in the middle of reproducing this on
another
Package: libapache2-mod-perl2
Version: 2.0.10-3
Severity: important
Tags: l10n
Dear Maintainer,
*** Reporter, please consider answering these questions, where appropriate ***
* What led up to the situation?
* What exactly did you do (or not do) that was effective (or
ineffective)?
Source: nagios-nrpe
Version: 3.0.1-3
Severity: important
Tags: upstream
Dear Maintainer,
With the current version, it is impossible to build nagios-nrpe on Debian
Stretch using openssl 1.1.x.
This applies to both the Debian source package nagios-nrpe and the upstream
source code.
The problem
Package: rsnapshot
Version: 1.3.1-4
Severity: normal
Tags: newcomer
The bug was already discussed in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=721043 but the problem on
Jessie (current stable) remains.
Please backport the fixed version (1.4.0-1) to Jessie as well.
-- System
Package: nginx-naxsi
Version: 1.2.1-2.2+wheezy2
Severity: important
Dear Maintainer,
When using naxsi installed through nginx-naxsi package, and by activating it in
the config files, certain web-applications were affected and could not be
loaded, even when Naxsi was set to be in LearningMode.
Package: grub
Version: 0.97-64
Severity: important
Tags: squeeze
The command update-grub should update /boot/grub/device.map if there was a
change of hdd (e.g. replacement).
I had two servers where I recently replaced a defect hdd but even after running
update-grub the device.map was not
22 matches
Mail list logo
