Dear Maintainer,
* What led up to the situation?
* What exactly did you do (or not do) that was effective (or
ineffective)?
after updating to kernel 7.1.x i'm no longer able to shutdown my pc from
desktop shutdown menu (xfce), neither with a shell and 'systemctl poweroff' or
'sudo poweroff'
* What was the outcome of this action?
the power led shut off and screen goes blank but the pc keeps running
* What outcome did you expect instead?
the power led shut off, screen goes blank and the pc shuts down too
i have so far tested with all 7.1.x versions including the today released
7.1.12 and also all 7.2 versions all without any luck
for the time being i'm running 7.0.14 where everything is working regarding
shutdown
Control: tags -1 moreinfo The kernel thinks your system is weird. Please provide the complete kernel log, "journalctl -b 0". It needs to show the reason for this taint. Oh, 15 years old now. Bastian
On Sat, 29 Aug 2026 13:20:30 +0200 Bastian Blank <waldi@debian.org> wrote: > Control: tags -1 moreinfo > > On Sat, Aug 29, 2026 at 12:14:38PM +0200, Ole Carlsen wrote: > > ** Tainted: S (4) > > * kernel running on an out of specification system > > The kernel thinks your system is weird. Please provide the complete > kernel log, "journalctl -b 0". It needs to show the reason for this > taint. > > > ** Model information > > sys_vendor: LENOVO > > product_name: 4384Y22 > > product_version: ThinkPad T510 > > Oh, 15 years old now. > > Bastian > > -- > Live long and prosper. > -- Spock, "Amok Time", stardate 3372.7 > > i have two other machines +16 years old both running same setup as this one so it can work :-) i have attached the detailed kernel log, not sure if it is the right way to do it ...
On Sat, 29 Aug 2026 14:22:27 +0200 ole.carlsen@tutamail.com wrote: > On Sat, 29 Aug 2026 13:20:30 +0200 Bastian Blank <waldi@debian.org> wrote: > > Control: tags -1 moreinfo > > > > On Sat, Aug 29, 2026 at 12:14:38PM +0200, Ole Carlsen wrote: > > > ** Tainted: S (4) > > > * kernel running on an out of specification system > > > > The kernel thinks your system is weird. Please provide the complete > > kernel log, "journalctl -b 0". It needs to show the reason for this > > taint. > > > > > ** Model information > > > sys_vendor: LENOVO > > > product_name: 4384Y22 > > > product_version: ThinkPad T510 > > > > Oh, 15 years old now. > > > > Bastian > > > > -- > > Live long and prosper. > > -- Spock, "Amok Time", stardate 3372.7 > > > > > > i have two other machines +16 years old both running same setup as this > one so it can work :-) > > i have attached the detailed kernel log, not sure if it is the right way > to do it ... > > -- > Ole > i have now tested with 7.1.13 and 7.2.3 from unstable and experimental but both with same outcome no proper shutdown is there any other information i can provide apart form the more detailed kernel.log attached in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1146033#17 ?
Hello Ole, Can you try to install `intel-microcode`, regenerate the initramfs and reboot? Does that help? Best regards Uwe
On Wed, 23 Sep 2026 16:12:05 +0200 Uwe =?utf-8?Q?Kleine-K=C3=B6nig?= <ukleinek@debian.org> wrote: > Hello Ole, > > On Sat, Aug 29, 2026 at 02:22:27PM +0200, ole.carlsen@tutamail.com wrote: > > aug 29 14:10:05 twike3 kernel: x86/CPU: Running old microcode > > Can you try to install `intel-microcode`, regenerate the initramfs and > reboot? > > Does that help? > > Best regards > Uwe i already did install intel-microcode some time ago, as i also saw the information about running old microcode, tested it al today with the image 7.2.7 and a regenerated initramfs but unfortunately no luck
On Thu, 24 Sep 2026 08:50:07 +0200 ole.carlsen@tutamail.com wrote: > On Wed, 23 Sep 2026 16:12:05 +0200 Uwe =?utf-8?Q?Kleine-K=C3=B6nig?= > <ukleinek@debian.org> wrote: > > Hello Ole, > > > > On Sat, Aug 29, 2026 at 02:22:27PM +0200, ole.carlsen@tutamail.com wrote: > > > aug 29 14:10:05 twike3 kernel: x86/CPU: Running old microcode > > > > Can you try to install `intel-microcode`, regenerate the initramfs and > > reboot? > > > > Does that help? > > > > Best regards > > Uwe > > i already did install intel-microcode some time ago, as i also saw the > information about running old microcode, tested it al today with the > image 7.2.7 and a regenerated initramfs but unfortunately no luck > > -- > Ole > tested with image 7.2.8 and 7.2.9 but no changes so far and i'm not even sure the issue for this problem really is targetted it was working in <7.0.x so it should be fixable but there might be reasons, i don't know, of why it is not working any more
Hi Ole,
So given we were out of luck with ideas on possible causes, the only
viable way forward we see is to ask you for a bisect between the 7.0
and 7.1 upstream versions. Can you please do that? The steps will
involve compiling and testing a couple of kernels, but given we will
use a targeted config, things should go reasonably fast, and you have
a clear idicator when things are 'bad'. As I understand every 7.1.y
release was a problem, so looks we should bisect between v7.0 and v7.1
(but if that understanding was wrong, then we should adapt the
following procedure):
git clone https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
cd linux
git checkout v7.0
cp /boot/config-$(uname -r) .config
yes '' | make localmodconfig
make savedefconfig
mv defconfig arch/x86/configs/my_defconfig
# test 7.0 to ensure this is "good"
make my_defconfig
make -j $(nproc) bindeb-pkg
... install the resulting .deb package and confirm problem does not exist
# test 7.1 to ensure this is "bad"
git checkout v7.1
make my_defconfig
make -j $(nproc) bindeb-pkg
... install the resulting .deb package and confirm problem exists
With that confirmed, the bisection can start:
git bisect start --first-parent
git bisect good v7.0
git bisect bad v7.1
(note the --first-parent flag for the bisect start, this is useful as
we bisect in mainline where we will see a lot of merges from other
branches)
In each bisection step git checks out a state between the oldest
known-bad and the newest known-good commit. In each step test using:
make my_defconfig
make -j $(nproc) bindeb-pkg
... install, verify if problem exists
and if the problem is hit run:
git bisect bad
and if the problem doesn't trigger run:
git bisect good
. Please pay attention to always select the just built kernel for
booting, it won't always be the default kernel picked up by grub.
Iterate until git announces to have identified the first bad commit.
Then provide the output of
git bisect log
In the course of the bisection you might have to uninstall previous
kernels again to not exhaust the disk space in /boot. Also in the end
uninstall all self-built kernels again.
Regards,
Salvatore
On Sat, 10 Oct 2026 21:56:29 +0200 Salvatore Bonaccorso <carnil@debian.org> wrote: > Control: tags -1 + moreinfo > > Hi Ole, > > On Mon, Oct 05, 2026 at 09:57:41AM +0200, ole.carlsen@tutamail.com wrote: > > On Thu, 24 Sep 2026 08:50:07 +0200 ole.carlsen@tutamail.com wrote: > > > On Wed, 23 Sep 2026 16:12:05 +0200 Uwe =?utf-8?Q?Kleine-K=C3=B6nig?= > > > <ukleinek@debian.org> wrote: > > > > Hello Ole, > > > > > > > > On Sat, Aug 29, 2026 at 02:22:27PM +0200, ole.carlsen@tutamail.com > > wrote: > > > > > aug 29 14:10:05 twike3 kernel: x86/CPU: Running old microcode > > > > > > > > Can you try to install `intel-microcode`, regenerate the initramfs and > > > > reboot? > > > > > > > > Does that help? > > > > > > > > Best regards > > > > Uwe > > > > > > i already did install intel-microcode some time ago, as i also saw the > > > information about running old microcode, tested it al today with the > > > image 7.2.7 and a regenerated initramfs but unfortunately no luck > > > > > > -- > > > Ole > > > > > > > tested with image 7.2.8 and 7.2.9 but no changes so far and i'm not even > > sure the issue for this problem really is targetted > > > > it was working in <7.0.x so it should be fixable but there might be reasons, > > i don't know, of why it is not working any more > > So given we were out of luck with ideas on possible causes, the only > viable way forward we see is to ask you for a bisect between the 7.0 > and 7.1 upstream versions. Can you please do that? The steps will > involve compiling and testing a couple of kernels, but given we will > use a targeted config, things should go reasonably fast, and you have > a clear idicator when things are 'bad'. As I understand every 7.1.y > release was a problem, so looks we should bisect between v7.0 and v7.1 > (but if that understanding was wrong, then we should adapt the > following procedure): > > git clone https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > cd linux > git checkout v7.0 > cp /boot/config-$(uname -r) .config > yes '' | make localmodconfig > make savedefconfig > mv defconfig arch/x86/configs/my_defconfig > > # test 7.0 to ensure this is "good" > make my_defconfig > make -j $(nproc) bindeb-pkg > ... install the resulting .deb package and confirm problem does not exist > > # test 7.1 to ensure this is "bad" hi salvatore your understanding is correct i will try and build/test the kernels following your description asap will i need any additional installation for this? it is a long time since i compiled anything (+15 years)
Hi Ole, Perfect thanks for that. You might need to install some packages needing to build if they are not yet available, but this should be pointed out if the builds fails. But please come back to us with any problem you encounter. https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html would be helpful as well. Let me know how it goes and we will try to assist in case of trouble. Regards, Salvatore