Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #93504 > unrolled thread

Bug#1142099: /usr/share/bug/linux-image-6.12.95+deb13-amd64-unsigned/include-1cmdline: Kernel 6.12.95 does not start boot sequence without setting acpi=off or recovery mode (logs in this mode)

Back to article view | Back to linux.debian.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Bug#1142099: /usr/share/bug/linux-image-6.12.95+deb13-amd64-unsigned/include-1cmdline: Kernel 6.12.95 does not start boot sequence without setting acpi=off or recovery mode (logs in this mode) Salvatore Bonaccorso <carnil@debian.org> - 2026-07-29 16:40 +0200
    Bug#1142099: /usr/share/bug/linux-image-6.12.95+deb13-amd64-unsigned/include-1cmdline: Kernel 6.12.95 does not start boot sequence without setting acpi=off or recovery mode (logs in this mode) <jfavrel@free.fr> - 2026-07-29 17:40 +0200

#93504 — Bug#1142099: /usr/share/bug/linux-image-6.12.95+deb13-amd64-unsigned/include-1cmdline: Kernel 6.12.95 does not start boot sequence without setting acpi=off or recovery mode (logs in this mode)

Control: tags -1 + moreinfo

Hi Jerome,

I see you had some progress on making the system boot. We would still
be interested in isolating the problem, so given you can reliably
assert the problem and if I understood correctly this is an
experienced regression from upgrading to 6.12.95? Which was the
previously last working kernel?

Once we have this range, could you please bisect the problem with the
following procedure, let's assume 6.12.94-1 was the last working one
and with 6.12.95-1 you fist experienced the problem, then bisecting
would involve compiling and testing a couple of kernels.

    git clone --single-branch -b linux-6.12.y https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
    cd linux-stable
    git checkout v6.12.94
    cp /boot/config-$(uname -r) .config
    yes '' | make localmodconfig
    make savedefconfig
    mv defconfig arch/x86/configs/my_defconfig

    # test 6.12.94 to ensure this is "good"
    make my_defconfig
    make -j $(nproc) bindeb-pkg
    ... install the resulting .deb package and confirm it successfully boots

    # test 6.12.95 to ensure this is "bad"
    git checkout v6.12.95
    make my_defconfig
    make -j $(nproc) bindeb-pkg
    ... install the resulting .deb package and confirm it fails to boot

With that confirmed, the bisection can start:

    git bisect start
    git bisect good v6.12.94
    git bisect bad v6.12.95

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, try to boot

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

[toc] | [next] | [standalone]

#93515

Thank's, I will try probably end of august 

At this point, I could use the 6.12.96 kernel in standard startup mode with
option "dis_ucode_ldr" set in default grub startup variable

Best regards
Jerome

-----Message d'origine-----
De : Salvatore Bonaccorso <carnil@debian.org> 
Envoyé : mercredi 29 juillet 2026 16:38
À : jerome Favrel <jfavrel@free.fr> <jfavrel@free.fr>;
1142099@bugs.debian.org
Objet : Re: Bug#1142099:
/usr/share/bug/linux-image-6.12.95+deb13-amd64-unsigned/include-1cmdline:
Kernel 6.12.95 does not start boot sequence without setting acpi=off or
recovery mode (logs in this mode)

Control: tags -1 + moreinfo

Hi Jerome,

I see you had some progress on making the system boot. We would still be
interested in isolating the problem, so given you can reliably assert the
problem and if I understood correctly this is an experienced regression from
upgrading to 6.12.95? Which was the previously last working kernel?

Once we have this range, could you please bisect the problem with the
following procedure, let's assume 6.12.94-1 was the last working one and
with 6.12.95-1 you fist experienced the problem, then bisecting would
involve compiling and testing a couple of kernels.

    git clone --single-branch -b linux-6.12.y
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
    cd linux-stable
    git checkout v6.12.94
    cp /boot/config-$(uname -r) .config
    yes '' | make localmodconfig
    make savedefconfig
    mv defconfig arch/x86/configs/my_defconfig

    # test 6.12.94 to ensure this is "good"
    make my_defconfig
    make -j $(nproc) bindeb-pkg
    ... install the resulting .deb package and confirm it successfully boots

    # test 6.12.95 to ensure this is "bad"
    git checkout v6.12.95
    make my_defconfig
    make -j $(nproc) bindeb-pkg
    ... install the resulting .deb package and confirm it fails to boot

With that confirmed, the bisection can start:

    git bisect start
    git bisect good v6.12.94
    git bisect bad v6.12.95

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, try to boot

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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web