This kernel has been pretty awful for me. On my desktop it barfs while trying to build nvidia support via dkms, with some sort of signing error. On my laptop, after install I get a 251Mb initrd after install, compared to the 44Mb initrd of the 6.7.12 kernel it replaced. Is anyone else that is running debian testing seeing these issues? -- Michael Galea
I don't have the 6.7 kernel anymore, I am on Sid so things move a bit faster I did notice that .10's initrd is huge, but when .12 came out, the sized was halved So maybe an experiment gone wrong? $ ls -lhtr /boot/initrd.img-6.* -rw-r--r-- 1 root root 252M Jul 20 11:58 /boot/initrd.img-6.9.10-amd64 -rw-r--r-- 1 root root 123M Jul 29 16:49 /boot/initrd.img-6.9.12-amd64 -rw-r--r-- 1 root root 123M Aug 6 10:17 /boot/initrd.img-6.10.3-amd64 $ This the default kernel with not extra dkms added at all On Mon, Aug 5, 2024 at 7:38 PM Michael Galea via talk <talk@gtalug.org> wrote:
This kernel has been pretty awful for me. On my desktop it barfs while trying to build nvidia support via dkms, with some sort of signing error.
On my laptop, after install I get a 251Mb initrd after install, compared to the 44Mb initrd of the 6.7.12 kernel it replaced.
Is anyone else that is running debian testing seeing these issues?
-- Michael Galea --- Post to this mailing list talk@gtalug.org Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk
On Mon, Aug 05, 2024 at 07:38:12PM -0400, Michael Galea via talk wrote:
This kernel has been pretty awful for me. On my desktop it barfs while trying to build nvidia support via dkms, with some sort of signing error.
On my laptop, after install I get a 251Mb initrd after install, compared to the 44Mb initrd of the 6.7.12 kernel it replaced.
Is anyone else that is running debian testing seeing these issues?
Some initrd growth has definitely happened recently due to some kernel changes. I don't recall exactly what was added, maybe a bunch of firmware files or something. Looks like it is some enormous nvidia firmware files: https://forums.debian.net/viewtopic.php?p=804049#p804049 As for signing, I have never run the signed kernel as I have never turned on secureboot on any system, so signing issues have never been a problem. -- Len Sorensen
On 2024-08-06 10:34, Lennart Sorensen wrote:
On Mon, Aug 05, 2024 at 07:38:12PM -0400, Michael Galea via talk wrote:
This kernel has been pretty awful for me. On my desktop it barfs while trying to build nvidia support via dkms, with some sort of signing error.
On my laptop, after install I get a 251Mb initrd after install, compared to the 44Mb initrd of the 6.7.12 kernel it replaced.
Is anyone else that is running debian testing seeing these issues?
Some initrd growth has definitely happened recently due to some kernel changes. I don't recall exactly what was added, maybe a bunch of firmware files or something.
Looks like it is some enormous nvidia firmware files: https://forums.debian.net/viewtopic.php?p=804049#p804049
As for signing, I have never run the signed kernel as I have never turned on secureboot on any system, so signing issues have never been a problem.
Thanks! I'm mow on 6.10.3 unsigned from sid now, with new nvidia sources. Everything running fine. But I'm confused on two issues. 1) It seems that debian has some sort of preference for signed over unsigned kernels. When I uninstalled a 6.9.12 unsigned kernel, it launched into installing a 6.9.12 signed kernel which I had around. 2) My linux-image-amd64 package is status rc at 6.9.12-1. But upgrading it wants to uninstall linux-image-6.10.3-amd64-unsigned and install linux-image-6.10.3-amd64! Is there some way to make debian prefer the unsigned kernel? -- Michael Galea
On Tue, Aug 06, 2024 at 01:27:19PM -0400, Michael Galea wrote:
Thanks! I'm mow on 6.10.3 unsigned from sid now, with new nvidia sources. Everything running fine. But I'm confused on two issues. 1) It seems that debian has some sort of preference for signed over unsigned kernels. When I uninstalled a 6.9.12 unsigned kernel, it launched into installing a 6.9.12 signed kernel which I had around. 2) My linux-image-amd64 package is status rc at 6.9.12-1. But upgrading it wants to uninstall linux-image-6.10.3-amd64-unsigned and install linux-image-6.10.3-amd64!
Yes it explicitly depends on the normal (signed) package. And the two kernel packages are listed as conflicting, so you either have the signed or the unsigned but not both.
Is there some way to make debian prefer the unsigned kernel?
Well I just went and checked, and sure enough, all my installed kernels are signed. I didn't know that, given I have never seen any messages about signing. Maybe because my system is BIOS not UEFI? All my machines are rather old by now. I don't see any obvious way to install unsigned kernels automatically. The meta package for the kernel depends on the signed one. -- Len Sorensen
On 2024-08-07 11:14, Lennart Sorensen wrote:
On Tue, Aug 06, 2024 at 01:27:19PM -0400, Michael Galea wrote:
Thanks! I'm mow on 6.10.3 unsigned from sid now, with new nvidia sources. Everything running fine. But I'm confused on two issues. 1) It seems that debian has some sort of preference for signed over unsigned kernels. When I uninstalled a 6.9.12 unsigned kernel, it launched into installing a 6.9.12 signed kernel which I had around. 2) My linux-image-amd64 package is status rc at 6.9.12-1. But upgrading it wants to uninstall linux-image-6.10.3-amd64-unsigned and install linux-image-6.10.3-amd64!
Yes it explicitly depends on the normal (signed) package. And the two kernel packages are listed as conflicting, so you either have the signed or the unsigned but not both.
Is there some way to make debian prefer the unsigned kernel?
Well I just went and checked, and sure enough, all my installed kernels are signed. I didn't know that, given I have never seen any messages about signing. Maybe because my system is BIOS not UEFI? All my machines are rather old by now.
I don't see any obvious way to install unsigned kernels automatically. The meta package for the kernel depends on the signed one.
I found out my problem on the laptop and its not signed vs unsigned. linux-image-6.10.3-amd64 installs a 44M initrd on my desktop and a 261M initrd on the laptop! The desktop is ext4 on disk while the laptop is crypted data on mmc flash memory. I'm guessing encryted fs doesn't compress so well. So far Ive tried upping the compression level in intramfs-tools.conf but to no avail, the initrd always is 261M. That's a problem for me as the standard debian crypt setup gave me only a 448M /boot and one kernel uses 66% of it! -- Michael Galea
On Wed, Aug 07, 2024 at 06:09:28PM -0400, Michael Galea wrote:
I found out my problem on the laptop and its not signed vs unsigned. linux-image-6.10.3-amd64 installs a 44M initrd on my desktop and a 261M initrd on the laptop! The desktop is ext4 on disk while the laptop is crypted data on mmc flash memory. I'm guessing encryted fs doesn't compress so well.
So far Ive tried upping the compression level in intramfs-tools.conf but to no avail, the initrd always is 261M. That's a problem for me as the standard debian crypt setup gave me only a 448M /boot and one kernel uses 66% of it!
You could change the initramfs settings from MODULES=most to MODULES=dep to make it only include what is needed to boot your system, rather than most generic systems. Setting the initramfs compression to zstd or something else modern can also reduce the size compared to gzip a bit. And it does seem having the nvidia drivers installed means a bunch more firmware files are included in the initrd than systems without the nvidia driver. I would not expect the encrytion to affect the initrd size, since the compression should be done on the file, not the encrypted disk. Now this is the sizes I see on one of my systems: -rw-r--r-- 1 root root 271K Aug 4 16:10 config-6.10.3-amd64 -rw-r--r-- 1 root root 258K Aug 31 2023 config-6.4.0-4-amd64 -rw-r--r-- 1 root root 270K Jul 19 12:55 config-6.9.10-amd64 drwxr-xr-x 5 root root 12K Aug 7 18:20 grub -rw-r--r-- 1 root root 84M Aug 7 13:45 initrd.img-6.10.3-amd64 -rw-r--r-- 1 root root 82M Jul 21 21:42 initrd.img-6.4.0-4-amd64 -rw-r--r-- 1 root root 84M Jul 21 21:44 initrd.img-6.9.10-amd64 -rw-r--r-- 1 root root 83 Aug 4 16:10 System.map-6.10.3-amd64 -rw-r--r-- 1 root root 83 Aug 31 2023 System.map-6.4.0-4-amd64 -rw-r--r-- 1 root root 83 Jul 19 12:55 System.map-6.9.10-amd64 -rw-r--r-- 1 root root 9.3M Aug 4 16:10 vmlinuz-6.10.3-amd64 -rw-r--r-- 1 root root 8.7M Aug 31 2023 vmlinuz-6.4.0-4-amd64 -rw-r--r-- 1 root root 9.2M Jul 19 12:55 vmlinuz-6.9.10-amd64 It uses zstd compression and MODULES=most for initramfs. It has nvidia-legacy-340xx-drive installed, but I think the huge firmware is only in the current nvidia drivers, not the legacy ones. Interestingly these are the largest files I see in my initrd: -rw-r--r-- 1 root root 3984265 Aug 4 16:10 usr/lib/modules/6.10.3-amd64/kernel/drivers/gpu/drm/radeon/radeon.ko -rw-r--r-- 1 root root 4374313 Aug 4 16:10 usr/lib/modules/6.10.3-amd64/kernel/drivers/net/ethernet/mellanox/mlx5/core/mlx5_core.ko -rw-r--r-- 1 root root 4696473 Aug 4 16:10 usr/lib/modules/6.10.3-amd64/kernel/fs/btrfs/btrfs.ko -rw-r--r-- 1 root root 5525401 Aug 4 16:10 usr/lib/modules/6.10.3-amd64/kernel/fs/xfs/xfs.ko -rw-r--r-- 1 root root 5772408 Aug 3 10:17 usr/lib/x86_64-linux-gnu/libcrypto.so.3 -rw-r--r-- 1 root root 6669193 Aug 4 16:10 usr/lib/modules/6.10.3-amd64/kernel/drivers/gpu/drm/nouveau/nouveau.ko -rw-r--r-- 1 root root 7955456 Feb 5 2024 kernel/x86/microcode/GenuineIntel.bin -rw-r--r-- 1 root root 9538825 Aug 4 16:10 usr/lib/modules/6.10.3-amd64/kernel/drivers/gpu/drm/i915/i915.ko -rw-r--r-- 1 root root 26577969 Aug 4 16:10 usr/lib/modules/6.10.3-amd64/kernel/drivers/gpu/drm/amd/amdgpu/amdgpu.ko I got that using: lsinitramfs -l /boot/initrd.img-6.10.3-amd64 |sort -n -k5 Maybe you can find out what is making yours so large. -- Len Sorensen
On 2024-08-07 18:28, Lennart Sorensen wrote:
On Wed, Aug 07, 2024 at 06:09:28PM -0400, Michael Galea wrote:
I found out my problem on the laptop and its not signed vs unsigned. linux-image-6.10.3-amd64 installs a 44M initrd on my desktop and a 261M initrd on the laptop! The desktop is ext4 on disk while the laptop is crypted data on mmc flash memory. I'm guessing encryted fs doesn't compress so well.
So far Ive tried upping the compression level in intramfs-tools.conf but to no avail, the initrd always is 261M. That's a problem for me as the standard debian crypt setup gave me only a 448M /boot and one kernel uses 66% of it!
You could change the initramfs settings from MODULES=most to MODULES=dep to make it only include what is needed to boot your system, rather than most generic systems.
Setting the initramfs compression to zstd or something else modern can also reduce the size compared to gzip a bit.
And it does seem having the nvidia drivers installed means a bunch more firmware files are included in the initrd than systems without the nvidia driver.
I would not expect the encrytion to affect the initrd size, since the compression should be done on the file, not the encrypted disk.
Now this is the sizes I see on one of my systems:
-rw-r--r-- 1 root root 271K Aug 4 16:10 config-6.10.3-amd64 -rw-r--r-- 1 root root 258K Aug 31 2023 config-6.4.0-4-amd64 -rw-r--r-- 1 root root 270K Jul 19 12:55 config-6.9.10-amd64 drwxr-xr-x 5 root root 12K Aug 7 18:20 grub -rw-r--r-- 1 root root 84M Aug 7 13:45 initrd.img-6.10.3-amd64 -rw-r--r-- 1 root root 82M Jul 21 21:42 initrd.img-6.4.0-4-amd64 -rw-r--r-- 1 root root 84M Jul 21 21:44 initrd.img-6.9.10-amd64 -rw-r--r-- 1 root root 83 Aug 4 16:10 System.map-6.10.3-amd64 -rw-r--r-- 1 root root 83 Aug 31 2023 System.map-6.4.0-4-amd64 -rw-r--r-- 1 root root 83 Jul 19 12:55 System.map-6.9.10-amd64 -rw-r--r-- 1 root root 9.3M Aug 4 16:10 vmlinuz-6.10.3-amd64 -rw-r--r-- 1 root root 8.7M Aug 31 2023 vmlinuz-6.4.0-4-amd64 -rw-r--r-- 1 root root 9.2M Jul 19 12:55 vmlinuz-6.9.10-amd64
It uses zstd compression and MODULES=most for initramfs.
It has nvidia-legacy-340xx-drive installed, but I think the huge firmware is only in the current nvidia drivers, not the legacy ones.
Interestingly these are the largest files I see in my initrd: -rw-r--r-- 1 root root 3984265 Aug 4 16:10 usr/lib/modules/6.10.3-amd64/kernel/drivers/gpu/drm/radeon/radeon.ko -rw-r--r-- 1 root root 4374313 Aug 4 16:10 usr/lib/modules/6.10.3-amd64/kernel/drivers/net/ethernet/mellanox/mlx5/core/mlx5_core.ko -rw-r--r-- 1 root root 4696473 Aug 4 16:10 usr/lib/modules/6.10.3-amd64/kernel/fs/btrfs/btrfs.ko -rw-r--r-- 1 root root 5525401 Aug 4 16:10 usr/lib/modules/6.10.3-amd64/kernel/fs/xfs/xfs.ko -rw-r--r-- 1 root root 5772408 Aug 3 10:17 usr/lib/x86_64-linux-gnu/libcrypto.so.3 -rw-r--r-- 1 root root 6669193 Aug 4 16:10 usr/lib/modules/6.10.3-amd64/kernel/drivers/gpu/drm/nouveau/nouveau.ko -rw-r--r-- 1 root root 7955456 Feb 5 2024 kernel/x86/microcode/GenuineIntel.bin -rw-r--r-- 1 root root 9538825 Aug 4 16:10 usr/lib/modules/6.10.3-amd64/kernel/drivers/gpu/drm/i915/i915.ko -rw-r--r-- 1 root root 26577969 Aug 4 16:10 usr/lib/modules/6.10.3-amd64/kernel/drivers/gpu/drm/amd/amdgpu/amdgpu.ko
I got that using: lsinitramfs -l /boot/initrd.img-6.10.3-amd64 |sort -n -k5
Maybe you can find out what is making yours so large.
Thanks greatly, my initrd.img-6.10.3-amd64 was full of nvidia .ko files, but after =dep and reinstall, I went from 231M to 26M! I'm still confused about one thing though. My desktop uses =most for 6.10.3 but doesn't include the same .ko files. Also, my module list is still different from yours. What is initramfs using to decide what to add/subtract at initrd build time? -- Michael Galea
On Wed, Aug 07, 2024 at 09:50:20PM -0400, Michael Galea via talk wrote:
Thanks greatly, my initrd.img-6.10.3-amd64 was full of nvidia .ko files, but after =dep and reinstall, I went from 231M to 26M!
I'm still confused about one thing though. My desktop uses =most for 6.10.3 but doesn't include the same .ko files. Also, my module list is still different from yours. What is initramfs using to decide what to add/subtract at initrd build time?
Well at least if your system doesn't have the nvidia drivers installed and built, it can't include them in the initrd. I have never actually looked at how the initrd decides what to do, but I have changed it to MODULES=dep on systems where the size mattered. -- Len Sorensen
participants (3)
-
Lennart Sorensen -
Michael Galea -
Nick Accad