Mir fiel auf:
Der neueste Siduction-Kernel (6.19.11-2) ist seltsam. Das .deb-Paket ist größer als 800MB, der Kernel selber mit knapp 300MB etwa viermal so groß wie "üblich". Ist da etwas schiefgegangen? (Debug-Info beibehalten oder so?)
-rw-r--r-- 1 root root 10M 9. Apr 20:40 vmlinuz-6.19.11-2-siduction-amd64
-rw-r--r-- 1 root root 9,0M 6. Apr 13:10 vmlinuz-7.0-rc7-siduction-amd64
Ich sehe da keine 300 MB für den Kernel, aber ja, durch Aktivierung des BPF Systems ist da etwas an debug hinzugekommen.
Wenn ich mir das gut 850 MB große Debianpaket anschaue, dann ist _da_ doch was im Argen:
xz -l data.tar.xz
Str. Blöcke Kompr. Unkompr. Verh. Check Dateiname
1 260 834,6 MiB 6.228,7 MiB 0,134 CRC64 data.tar.xz
Da muss vermutlich irgendwo eine dicke Leiche drin liegen, die da nicht hin sollte.
edlin
Nachtrag: Ich hab das mal ausgepackt und mit
find . -type f -exec du -Sh {} + | sort -rh | head -n 1
Ergebnis:
674M ./lib/modules/6.19.11-2-siduction-amd64/kernel/drivers/gpu/drm/amd/amdgpu/amdgpu.ko
Beim Vorgänger war das "etwas" weniger:
24M ./lib/modules/6.19.11-1-siduction-amd64/kernel/drivers/gpu/drm/amd/amdgpu/amdgpu.ko
edlin
Quote from: towo on 2026/04/10, 10:31:23
-rw-r--r-- 1 root root 10M 9. Apr 20:40 vmlinuz-6.19.11-2-siduction-amd64
-rw-r--r-- 1 root root 9,0M 6. Apr 13:10 vmlinuz-7.0-rc7-siduction-amd64
Ich sehe da keine 300 MB für den Kernel, aber ja, durch Aktivierung des BPF Systems ist da etwas an debug hinzugekommen.
Ja, ich bitte um Entschuldigung, es ist die initrd, die so (übermäßig) groß ist.
Habe die config nochmal geändert, die Größe ist jetzt wieder moderater, allerdings sind da nicht mehr alle BPF Optionen aktiv, welche noch mehr debugging benötigen würden.
Danke. Der Sprung von Größe M auf 7XL war doch etwas unerwartet heftig.
edlin
Es bleibt trotzdem seltsam:
$ ls -la linux-image-6.19.11-*
-rw-r--r-- 1 tr tr 63174040 2. Apr 20:27 linux-image-6.19.11-1-siduction-amd64_6.19-11_amd64.deb
-rw-r--r-- 1 tr tr 97859332 10. Apr 12:01 linux-image-6.19.11-2-siduction-amd64_6.19-11.2_amd64.deb
Die neue Version ist um ca. 50% größer als die ältere. Packt man beide Debianpakete samt
control Dateien aus, so erhält man:
i$ grep 'CONFIG_MODULE_COMPRESS ' /tmp/deb.MnDOSteepZ/boot/config-6.19.11-1-siduction-amd64;\
du -BM /tmp/deb.MnDOSteepZ/|tail -5; echo;\
grep CONFIG_MODULE_COMPRESS= /tmp/deb.IAAsL71Yn2/boot/config-6.19.11-2-siduction-amd64;\
du -BM /tmp/deb.IAAsL71Yn2/|tail -5
# CONFIG_MODULE_COMPRESS is not set
327M /tmp/deb.MnDOSteepZ/lib/modules/6.19.11-1-siduction-amd64
327M /tmp/deb.MnDOSteepZ/lib/modules
327M /tmp/deb.MnDOSteepZ/lib
16M /tmp/deb.MnDOSteepZ/boot
343M /tmp/deb.MnDOSteepZ/
CONFIG_MODULE_COMPRESS=y
91M /tmp/deb.IAAsL71Yn2/lib/modules/6.19.11-2-siduction-amd64
91M /tmp/deb.IAAsL71Yn2/lib/modules
91M /tmp/deb.IAAsL71Yn2/lib
19M /tmp/deb.IAAsL71Yn2/boot
111M /tmp/deb.IAAsL71Yn2/
Das um ca. 50% größere Debianpacket hat also im ausgepackten Zustand
eine um ca. 60% kleinere Größe. Die kleinere Größe erklärt sich natürlich durch die
Kompression der Module, was aber erklärt den Anstieg der Größe nach
Erzeugung des Debian Pakets? Das ist eine gute Einstellungsfrage für zukünftige
Siduction System Administratoren.
111M -> 97M (6.19.11-2)
343M -> 63M (6.19-11)