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

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

Bug#1127682: linux-image-6.18.9+deb14-amd64: Kernel 6.18 fails to suspend (hangs) if any VeraCrypt volume is mounted

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#1127682: linux-image-6.18.9+deb14-amd64: Kernel 6.18 fails to suspend (hangs) if any VeraCrypt volume is mounted Salvatore Bonaccorso <carnil@debian.org> - 2026-02-11 19:40 +0100

#91177 — Bug#1127682: linux-image-6.18.9+deb14-amd64: Kernel 6.18 fails to suspend (hangs) if any VeraCrypt volume is mounted

Control: tags -1 + moreinfo

Hi,

On Wed, Feb 11, 2026 at 05:12:49PM +0000, Nolan Leasy wrote:
> Package: src:linux
> Version: 6.18.9-1
> Severity: normal
> X-Debbugs-Cc: nsleasy@hotmail.com
> 
> Dear Maintainer,
> 
> Laptop fails to enter Suspend mode with all versions of Kernel 6.18 (and Kernel
> 6.19.0-rc_) if any VeraCrypt volume is mounted. This is true whether the
> VeraCrypt volume is partition-based or file-based. All previous kernels,
> including 6.17 are fine.
> 
> I am opening this report to make the Debian maintainers aware of the problem.
> Open bug reports are here:
> 
> https://bugzilla.kernel.org/show_bug.cgi?id=220996
> 
> https://bugzilla.opensuse.org/show_bug.cgi?id=1256893
> 
> The kernel developers do not seem inclined to work on the problem.

I think to see something moving forward would be to have someone
affected doing a bisect, as mentioned in that upstream bug.

The person which can reproduce the problem is you, so your help is
needed. In case you are willing to bisect the changes here is how it
goes (otherwise there is nothing we as donwstream can do):

    git clone https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
    cd linux
    git checkout v6.17
    cp /boot/config-$(uname -r) .config
    yes '' | make localmodconfig
    make savedefconfig
    mv defconfig arch/x86/configs/my_defconfig

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

    # test 6.18 to ensure this is "bad"
    git checkout v6.18
    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
    git bisect good v6.17
    git bisect bad v6.18

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 the 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.

Once you have identified the breaking commit provide the information
here in this bug and to upstream. With the identified commit you can
run as well script/get_maintainers.pl to see which other people should
be reached at.

This should help moving things forward.

Regards,
Salvatore

[toc] | [standalone]

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

csiph-web