XPost: linux.debian.kernel

On Fri, Mar 07, 2025 at 05:44:00PM +0100, Eric Valette wrote:

See additionnal info. What type of compression do you have for initrd
and modules?

2 [2/5411]mh@swivel:~ $ grep CONFIG_RD /boot/config-6.12.17-amd64 CONFIG_RD_GZIP=y
CONFIG_RD_BZIP2=y
CONFIG_RD_LZMA=y
CONFIG_RD_XZ=y
CONFIG_RD_LZO=y
CONFIG_RD_LZ4=y
CONFIG_RD_ZSTD=y
CONFIG_RDS=m
CONFIG_RDS_RDMA=m
CONFIG_RDS_TCP=m
# CONFIG_RDS_DEBUG is not set
CONFIG_RDMA_RXE=m
# CONFIG_RDMA_SIW is not set
[3/5412]mh@swivel:~ $ grep CONFIG_MODULE /boot/config-6.12.17-amd64 CONFIG_MODULES_USE_ELF_RELA=y
CONFIG_MODULE_SIG_FORMAT=y
CONFIG_MODULES=y
# CONFIG_MODULE_DEBUG is not set
CONFIG_MODULE_FORCE_LOAD=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
# CONFIG_MODULE_UNLOAD_TAINT_TRACKING is not set
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_MODULE_SIG=y
# CONFIG_MODULE_SIG_FORCE is not set
# CONFIG_MODULE_SIG_SHA1 is not set
CONFIG_MODULE_SIG_SHA256=y
# CONFIG_MODULE_SIG_SHA384 is not set
# CONFIG_MODULE_SIG_SHA512 is not set
# CONFIG_MODULE_SIG_SHA3_256 is not set
# CONFIG_MODULE_SIG_SHA3_384 is not set
# CONFIG_MODULE_SIG_SHA3_512 is not set
CONFIG_MODULE_SIG_HASH="sha256"
CONFIG_MODULE_COMPRESS=y
# CONFIG_MODULE_COMPRESS_GZIP is not set
CONFIG_MODULE_COMPRESS_XZ=y
# CONFIG_MODULE_COMPRESS_ZSTD is not set
CONFIG_MODULE_COMPRESS_ALL=y
CONFIG_MODULE_DECOMPRESS=y
# CONFIG_MODULE_ALLOW_MISSING_NAMESPACE_IMPORTS is not set CONFIG_MODULES_TREE_LOOKUP=y
CONFIG_MODULE_SIG_KEY_TYPE_RSA=y
CONFIG_MODULE_ALLOW_BTF_MISMATCH=y
[4/5413]mh@swivel:~ $

I am using the Debian kernel on unstable.

Greetings
Marc
-- ----------------------------------------------------------------------------- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.kernel

On Sat, Mar 08, 2025 at 12:29:06PM +0100, Eric Valette wrote:

On Fri, 7 Mar 2025 20:43:08 +0100 Marc Haber <mh+debian-bugs@zugschlus.de> wrote:

On Fri, Mar 07, 2025 at 05:44:00PM +0100, Eric Valette wrote:

CONFIG_MODULE_DECOMPRESS=y

So the culprit is there. It is not set in my own kernel build (never been so far although config has been created via the official linux-source-6.6) and thus I cannot load compressed modules without user space helpers that probably not exist in initrd busybox version. Of course I can load
compressed modules once the pivot_root/switch_root is done.

So it remains a bug because the script store compressed modules in initrd without checking this compilation flag and the kernel does not boot. If was not doing this in 145. This is the reason for the bug I have.

A second bug is that the initrd does not seems to be compressed while config says it should be with zstd (and the CONFIG_RD_* is ok). I can change to xz.

A third one is that compressing compressed file is not efficient in term of size. There has been bug opened exactly on this theme on other
distributions.

AFAICT this is an intentional change: https://salsa.debian.org/kernel-team/initramfs-tools/-/merge_requests/128

C.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.kernel

Control: tag -1 moreinfo unreproducible

On Sat, 2025-03-08 at 12:29 +0100, Eric Valette wrote:

On Fri, 7 Mar 2025 20:43:08 +0100 Marc Haber
<mh+debian-bugs@zugschlus.de> wrote:

On Fri, Mar 07, 2025 at 05:44:00PM +0100, Eric Valette wrote:

CONFIG_MODULE_DECOMPRESS=y

So the culprit is there. It is not set in my own kernel build (never
been so far although config has been created via the official linux-source-6.6) and thus I cannot load compressed modules without user space helpers that probably not exist in initrd busybox version. Of
course I can load compressed modules once the pivot_root/switch_root is done.

The initramfs is supposed to use modprobe etc. from kmod, not from
busybox. So there should be no difference in capabilities from the main
Debian system.

Does your initramfs image include the right version of modprobe?
Boot with "break=top" and run "modprobe --version" to check this.


[...]

A second bug is that the initrd does not seems to be compressed while
config says it should be with zstd (and the CONFIG_RD_* is ok). I can
change to xz.

As explained, it is intentional that the modules are not recompressed,
while other files are. We made a trade-off between size and speed (of mkinitramfs), and I don't intend to revisit that.

[...]

Additional note : enabling this compilation flags, cause the signature
of external modules to be incorrect as XZ with this flag *must* be used
with CRC32 checksum and not the xz default CRC64. I had to add
--check=crc32 to my signature scripts for external modules.

[...]

When does this signature script run?

I built a kernel from Linux 6.6.80 using the cloud-amd64 configuration
from linux-config-6.6, and an initramfs using initramfs-tools 0.146.
Module loading worked OK, so I don't believe this is a general problem.

Ben.

--
Ben Hutchings
Lowery's Law:
If it jams, force it. If it breaks, it needed replacing anyway.

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEErCspvTSmr92z9o8157/I7JWGEQkFAmfXIscACgkQ57/I7JWG EQl2phAA1JZukBmmlfNQDMmX1ke6A4T2JTMG152rmQjreaEkYUnG5FqrI2++9o1n 3YIJqyGwmtgzP2Se15lCCWn/wZTZXn6Oc19vR4wpGr0W0JRLjHYxNnfpbu1hfx9g N7RyOyk0YTAYgLOyr1A8tZM8dYuMwUa7bPydjf5x9B/jb8cZoous0rbMgccZxaix dgjq46xJAlGM8SvAZv1MF8tiWtPr2EO/XaIIwc9e6rGBdAt4pknQC2WZdBF6rkFL cRwX7/ghvwCqVDvlhvzIpSEL3QQUC4YTSpm8l7egsSuzimoew37H4TlXjr0/Vr1I 5tTto7dmfqUV+yjr+bcoi65edgKvSU2lfaKz/6Hp+WA8yGnBB1rNvE0j1j18G9QR /a5pXISORXTzPY+lz5ttnr/2Q6MWDTXKXplKMw0wNg13KFYURaZSeJeCbir6XQYE R53SWHLGMsviTQgs0AnU+qdc423EASKrTKPUeRcDqwo4ycXXSXItE2rgFKVfezHl ryo5sIDLQ5+DyihljWYXOnCc67nay4cXq6Bgx4OSXKYL0uduczx6uvetU8MMZsr0 tjZduQKOhPkxquuc/VPAdTNIwGbWYEKvuJAjI54IfcNlCW1NE1ea63Vwiqy2V6vG YAQPsdQ7KC7lvCpByWdStOfs6lrWAx/JtKblMZbT6hBnRl8fJ4U=
=9FKr
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:

XPost: linux.debian.kernel

On Sun, 2025-03-16 at 20:21 +0100, Eric Valette wrote:

On 16/03/2025 20:13, Ben Hutchings wrote:

[...]

Does your initramfs image include the right version of modprobe?
Boot with "break=top" and run "modprobe --version" to check this.

It use wahever is put in. I did not make any chnage.

And yet module loading is going wrong in a way that can't be reproduced elsewhere. So please check.

[...]

Additional note : enabling this compilation flags, cause the signature
of external modules to be incorrect as XZ with this flag *must* be used with CRC32 checksum and not the xz default CRC64. I had to add --check=crc32 to my signature scripts for external modules.

[...]

When does this signature script run?

After I do a dkms. I do not want to put the signature key available
directly in the fs.

Yes, that's a sensible policy.

I was wondering whether the modules installed in the main system are
properly signed but due to some mis-ordering the modules copied into the initramfs are not.

Can you unpack the initramfs (with unmkinitramfs) and check that the
modules have the same contents as those installed in the main system?
(With the current version of unmkinitramfs, they will be unpacked under
a cpio<n> subdirectory.)

I built a kernel from Linux 6.6.80 using the cloud-amd64 configuration
from linux-config-6.6, and an initramfs using initramfs-tools 0.146.
Module loading worked OK, so I don't believe this is a general problem.

I do not use cloud config. Did you check if CONFIG_MODULE_DECOMPRESS=y
is set in this config? If yes then the bug goes untoticed as the kernel itself decompress the modules not the module loader.

It is not set.

Ben.

--
Ben Hutchings
Lowery's Law:
If it jams, force it. If it breaks, it needed replacing anyway.

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEErCspvTSmr92z9o8157/I7JWGEQkFAmfXLjYACgkQ57/I7JWG EQmpbA/+KxXXt74CvfCzw5h3qk4lFawGFtJ3cckTPnEUKnUMh7tUi5cLl29YNr71 l15iHWDYZMR0y79AFFoHmcrSaIbQgfdg/Oq03CC+pz384diipOF6mummghLcUNfG mCD0nZK9B4bSSREa6yz2mkSY16/vzcAagXyaHaK1O6RhlU6sDCVVXa7CHJSvpgLL vEqv3RTT17FDXhS+rs4Z0M5bN+Yt/rr0sj9FB6jW4K+9ukd7GDyIcegNzcepfzz0 mbENxXVXuJ9qHeobaa2HTOhrLf+cArrF1Ykb5PeWN+nsQb6+5WP+yxe9asifRsjl 33JwLItgIJ4nym7wFhC0r8MmjHw8uIspBhw0C9uwDVq4KIxmaebp8nqVVfHeeor3 q0wLpg5CTBQEbdyApGrs1obJSJSqYaE/2unvnWVllBbzLyxw9PijyEx2uR/KCjUF zPVNjuiRs1qGxMge2ME/YlVwIQeI0f8hMo7sxU5a2sl92OtFv2tEydA49scaRnSE LdMWfKuUSjrcxOYAJQ0j0Sq3+fRDdHsqXAiYg3cWyLkLTm474HWW5TmHkNci6iC/ 2AVFH0Lv7S8AMZx+pIL4pI/B1pwLHS66ZV3+D5ZpblERchMkq/UbOO7/X2qU3U3q nzCYGWD7ywK6RHV4LN6bQphGDxbJAaf+VureOH3WNyyD2cF70VY=
=XJIW
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:

XPost: linux.debian.kernel

Hi Eric,

You wrote:
[...]

kmod binaries are identical

[...]

more generally, the modules that exist in the CPIO and the one in the
rootfs are identical

[...]

here is my complete module config if it helps (note that I keep the DECOMPRESS so far).

grep CONFIG_MODULE /boot/config-6.6.83
CONFIG_MODULES_USE_ELF_RELA=y
CONFIG_MODULE_SIG_FORMAT=y
CONFIG_MODULES=y
# CONFIG_MODULE_DEBUG is not set
CONFIG_MODULE_FORCE_LOAD=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
# CONFIG_MODULE_UNLOAD_TAINT_TRACKING is not set
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_MODULE_SIG=y
# CONFIG_MODULE_SIG_FORCE is not set
CONFIG_MODULE_SIG_ALL=y
# CONFIG_MODULE_SIG_SHA1 is not set
# CONFIG_MODULE_SIG_SHA224 is not set
CONFIG_MODULE_SIG_SHA256=y
# CONFIG_MODULE_SIG_SHA384 is not set
# CONFIG_MODULE_SIG_SHA512 is not set
CONFIG_MODULE_SIG_HASH="sha256"
# CONFIG_MODULE_COMPRESS_NONE is not set
# CONFIG_MODULE_COMPRESS_GZIP is not set
CONFIG_MODULE_COMPRESS_XZ=y
# CONFIG_MODULE_COMPRESS_ZSTD is not set
CONFIG_MODULE_DECOMPRESS=y
# CONFIG_MODULE_ALLOW_MISSING_NAMESPACE_IMPORTS is not set CONFIG_MODULES_TREE_LOOKUP=y
CONFIG_MODULE_SIG_KEY="certs/signing_key.pem"
# CONFIG_MODULE_SIG_KEY_TYPE_RSA is not set CONFIG_MODULE_SIG_KEY_TYPE_ECDSA=y

This all matches what I used in my local test (except for the CONFIG_MODULE_DECOMPRESS which was disabled). So I still don't
understand what's special about your configuration that results in the
failure.

Could you please send:

- The *complete* kernel config that you were using (before enabling CONFIG_MODULE_DECOMPRESS).

- All the error messages from the initramfs when using this kernel and initramfs-tools 0.146. (A photograph of the screen is fine, if it's
readable.)

Ben.

--
Ben Hutchings
Man invented language to satisfy his deep need to complain.
- Lily Tomlin

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEErCspvTSmr92z9o8157/I7JWGEQkFAmfh9NoACgkQ57/I7JWG EQkFNw//cXDSSJszqg2BZvjCuWu4PxpMEScZiwykjo84z0ORpnKK2BeS1411JbJj peOFfabNFvpwiqzhOuSHtBaMG+kaifAsL7lKCrhymRk8qznI6drB30RhYHg6iMO9 hAYTbBnGOTirTKAA/HDB/FXffv7gkjsD6j5OEPKmifqAJi8CpJcR3IJH79LRpBYq Zkuo626f6AA0kmMqysiQKOKQ8sI8pWbRGokvf9A7ZeZA/tvug2nDUZB/6sLIUu54 6XzluuwKeG1l1zPT8Q0H89oguRh/JWXeynYhM/HGhBT/mSitOd5KxpWGP1fL0Eq/ pj3ymFiE62y5QjGp6m9sIiGJ+WuV5C+DYTDcy1A914F3zzNo1qe4A1Wq9Dd6odoL z6z9c+GqkZQDOgG22pDTWCRCbTXpxec8kfxj+cueAKHDB+OCSRb7J9AuWwH8yGZI JK9wXH17or+B2FbbBsIaMztUT0bV0IU9pkl3U0hj16ZwadeWcyOhIRzdE8S00WWk tHVxJwgYLq+3EPkfuk6j5XprXX+VXlSIOsVx0CbFN1FQDr46Y+jkSoYLkVRToPOm YtMDrd8RLN/tSokwRmaqCnHsGCFB+G9JhYTf3lP9K7jwUXkYjXAhUJWzoThhezjm XjB+NMcZmEjFuEQnNhMMZlxyy2+KwjzgJJvs8v1d+OvwFysM45Y=
=xcd/
-----END PGP SIGNATURE-----

--- SoupGate-Win3

XPost: linux.debian.kernel

On Thu, 2025-03-27 at 16:46 +0100, Eric Valette wrote:

On 25/03/2025 01:12, Ben Hutchings wrote:

Hi Eric,

- The *complete* kernel config that you were using (before enabling CONFIG_MODULE_DECOMPRESS).

I switched tp 6.12.20 but same problem. Config attached.

- All the error messages from the initramfs when using this kernel and initramfs-tools 0.146. (A photograph of the screen is fine, if it's readable.)

Photo attached

No module loaded at all.

Indeed. But the root device is there anyway, presumably because the
nvme driver is built-in. So I think the "No such device" error is
actually because the *filesystem* module fails to load.

So I have more questions:

- Your kernel config has ext4 enabled as a module. Is that the root
filesystem type?
- What does the command "/usr/lib/klibc/bin/fstype /dev/nvme0n1p5"
print?
- Using the bad initramfs, in the rescue shell:
- What does "echo $ROOTFSTYPE" print?
- What does "cat /proc/filesystems" print?
- What does "modprobe fs-ext4" print, if anything?
- If you then exit the rescue shell, does the boot process succeed?

Ben.

--
Ben Hutchings
If at first you don't succeed, you're doing about average.

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEErCspvTSmr92z9o8157/I7JWGEQkFAmfl7SgACgkQ57/I7JWG EQkZMA//XqDCXR8QM2A2LGgdMsyaGOz4rIcyV0MlOvCVoFtReCpVpOA5oqRm2168 vRp3j8AZU71tqNCE1pP8ANm/90s41qlR2e/4lpINJVC3MoS7odlMM8FcCXzIAm47 iU8Di9xcBvGPrUIDB1gU4xgG9iI5Vs17Rrr1+uSzKD42Dwoao2W9EsrCd3I6smeL sNriOvYML/hdRjaQ0KXLzMrkq1EhppAOlHFdLGiLw7qIQxvy2vH9jrETfLXx+GFL 3mKWaLudESrvKmBjMMNb6TaQFh4VuWm3qlGqt78qTEeGiZ7Fx4C5cy6ADFPSyWkV 6v+zmcYnW1jd7E1+flYkInG7XYXRB2y2omdWaLq63mMR2oRaUIR8V+5JKpucal4f L4VDs+qN0whTzprZJp6AkSoa9W+ClN8UwGiBslG2C+vp8+6Etgw7xeX1uw3zp/Nu 3VYhHx4eND8pPoKZnF2xjBuYlUKic6ZTObFy1j+CjhL59doe35hp8yKOJt82KDT8 y3anNCrG80PjxrxCv0vUpNEYyz5MkLs66c8X+4RbABW/MKXC3/2d88BLPP47qy4d CEOd77BhRYrQMIaQVPhEUa0V2a5lJkBG4qkSYnWITLABVmNNwVbpIImYE3hsGvJC +QpvKoPrx2DnpHL82o13Itcm5yUW07SizHNxZZH2zsILTbMPFzg=
=3eJL
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.kernel

On Fri, 2025-04-25 at 19:38 +0200, Eric Valette wrote:
[...]

I think the bug #1099801 Marco d'Itri <md@Linux.IT> closed is a
dupplicate from mine that must also be closed I guess.

Do you mean that the new version of kmod fixes this for you?

Ben.

--
Ben Hutchings
If more than one person is responsible for a bug, no one is at fault.

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEErCspvTSmr92z9o8157/I7JWGEQkFAmgReo0ACgkQ57/I7JWG EQlE0Q//YfH7nbh8RXgYcsbOBMlsZcRZUwJvMwp/Lc2n9e1EmcgSnLzUHSDNXQaA DSZNpHUVF5AgxPpPxRi9kjd5vJGb8LijZ0FZIpGj6T6+w9kmrt5lfqtgO6cPMvUd v8Kh8LWRQmYCc4jw5OV29vzoAnnI8NfCYiRzVTsUkU0mtwyG/ZRyY97PVhqR8COS fVqCi6beDYSXOU0XwgeGwwVdmDg59xTK9AHlSTv1TEUXzjcQn7HNWwWCmtp+Hihv 8iSbYsJzXjK8/iNfZ1UtSe/7KPfUlPYaISvSThkJ9fNFVc5F5pxr0bboV+MxcxdM Og54avQ0Z+vNm3/d6255Z/JvhvRjm4qs38yugsvMV5Mju7zkFDtsiOo5QrkGA8uY QHsaiFKXhLPUFoueryq8rC3ClPC797PUbB4xjh67wncB425EH0cHgrrWw3WCZ/BC Zmbx/K2DUMsiincFrBYynZ8CAfYGCleFcLpYVRrRkLQW6Jt2MukfgmvoxI8XF/i0 tWt59gadpcUZBYvUT8xoGsraIM1glLmAuTM6CA/gU3ApbxmKvNhvLpSv0N6xyBi5 ldSoGGf02/51LQVNMV+JjIbg7GZL9Y8gmIKGI0X7+zqMTc++qKFdj4FlEZnK9V4M cVu7DMtRMSkxt01yLP9r8XdPLse93qZpk89eFIG/DX5vgc8Ad98=
=QzCw
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 2025-04-30 at 10:38 +0200, Eric Valette wrote:

On 30/04/2025 03:19, Ben Hutchings wrote:

On Fri, 2025-04-25 at 19:38 +0200, Eric Valette wrote:
[...]

I think the bug #1099801 Marco d'Itri <md@Linux.IT> closed is a dupplicate from mine that must also be closed I guess.

Do you mean that the new version of kmod fixes this for you?

If you read the changelog for #1099801 it was obvious that kmod was
unable to decompress modules as required shared lib used by dlopen was missing and kernel was unable to do the job itself. This is exactly the
root cause of my problem and BTW if you read the comment I made in the
bug I suggested something like that.

I read that, but I wanted to check that you had already verified the fix because that wasn't clear to me.

Did the effort to validate the fix on my faulty computer by removing the MODULES_DECOMPRESS option again (as it was not set originally) and yes
this time it boots.

So this bug can indeed be closed but it was truly due to the change in initramfs-tool that was not tested with the old 6.1 config that was set
by linux-source-6.1

I consider this a bug in kmod exposed by the change in initramfs-tools.
So I merged this with #1099801.

Ben.

--
Ben Hutchings
If more than one person is responsible for a bug, no one is at fault.

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEErCspvTSmr92z9o8157/I7JWGEQkFAmgSIHIACgkQ57/I7JWG EQmTSQ/8C3Rc8tb5ztGjc7Bq2j1KSISOtTGVAcQ9/W/FViTuT5oIvQ2YOAS9YDXh wRgKFddJ4pt891VXfcJy8pSQjnjEoFQy19s46r9X6xZxnPct5s1UprcrQreY8uX3 KpxBmGQTiT60Lh0R6MpSOKQf6IbMmaCxYwYBfnwEU0pV3WNIxHWMmrsWq9KYDu3l yWJHqnehHSYHM9p59B/6ti4n8CinKqiUBlh/Z9Tolw+h4dv955Jxeb6CE1lXASmy NdX8k9vjUHlIt9vqQhciZ5nRRVmTVL3JEJVwLFM8FfG8nRSIIEbpqeVcqvQRyPh9 SYQGlTpV9YMzpR4mUGZpTDikJVueOVMDtH91L/5ZGVi5bU+x3wO+BQjjB9OPBcWr GhEY3Pp3bdgD7ajidi64PHK9FzFW3LhU7zUWBMT/A7UR5UypSM/vCqmCYPOuczVR 89Kd22pKeWeCnnHtbfQDuLA6KG9lF+Rv1B6/DP2BJTnxIzG7oMv3X9Cyc4FuRIJx TlNQ/grxyaXNBipRScnsZjV4/ykr0q+nOzaDHV+ufq34KuBHztl6FIqhtvnCJvAm 08bkKMzHReClYqg0QHBoCUO7F1rHVPN1LKzBHNPM0X4MgxoA5/ZGJ5zlDRUJI6pN MZJrQMjVkJoV5zRENBPPRz7A7YDH4YGoYiEJkMxF8b3+ukeYs6c=
=sc1h
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

I can reproduce this issue on Debian 12.11 (Bookworm) with kernel 6.1.0-35-amd64.

After upgrading from 12.9, my system hangs at "Loading initial ramdisk". The issue disappears when booting the fallback recovery mode or using an older kernel (6.1.0-30-amd64).

I verified that CONFIG_MODULE_DECOMPRESS is not set in the broken kernel.

The system is running on a Hyper-V Generation 2 virtual machine (EFI boot).

My version of initramfs-tools is 0.142+deb12u3, so the problem does not require 0.146 to manifest.

Let me know if I you need any other infos to reproduce the problem.

Guillaume

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)