Mga9 backport kernel 6.18.4, Bug 34962, is now old and should be updated for security and improvements.
I see that yesterday, kernel-stable-testing-6.18.26-1.stabletesting.mga9 was built, and it works well on three systems tested so far. Ready for QA? Needs files list.
OK kernel-stable-testing-desktop-6.18.26-1.stabletesting.mga9-1-1.mga9 Machine details in Bug 35459 Comment 8 Machine: Acer Aspire A717 Integrated Intel HD Graphics (the nvidia GPU not used) Using an LUKS encrypted partition for LVM, which contain /, /home, swap. Separate /boot partition. All was set up by installer. Clean update, reboot § suspend-resume § hibernate-restore (both really feels snappy, also true for other machines i will report) Playing video in Firefox over wifi from internet Appimage Nextcloud client
Yes, it was building overnight, now completed. Files list can be retrieved from this: https://pkgsubmit.mageia.org/uploads/done/9/core/backports_testing/20260502222531.ghibo.duvel.1864989/kernel-stable-testing-6.18.26-1.stabletesting.mga9/packages.x86_64.0.20260502222603.log https://pkgsubmit.mageia.org/uploads/done/9/core/backports_testing/20260502222531.ghibo.duvel.1864989/kernel-stable-testing-6.18.26-1.stabletesting.mga9/packages.i586.0.20260502222606.log
CC: (none) => ghibomgx
(In reply to Morgan Leijström from comment #2) > (both really feels snappy, also true for other machines i will report) That kernel is substantially the same as the one in mga10.
OK i586 on Thinkpad T43, LXDE Both flavours: 6.18.26-desktop586-1.stabletesting.mga9 6.18.26-desktop-1.stabletesting.mga9 Plain ext4 partitions, IDE disk on mainboard SATA bridge suspend-resume hibernate-restore Firefox playing internet video in small window via wifi, and writing this. [ettan@localhost ~]$ inxi -SMCGN System: Host: localhost Kernel: 6.18.26-desktop586-1.stabletesting.mga9 arch: i686 bits: 32 Desktop: LXDE v: 0.10.1 Distro: Mageia 9 Machine: Type: Laptop System: IBM product: 2668R1G v: ThinkPad T43 serial: <superuser required> Mobo: IBM model: 2668R1G serial: <superuser required> BIOS: IBM v: 1YET62WW (1.27 ) date: 05/18/2006 CPU: Info: single core model: Intel Pentium M bits: 32 cache: 2 MiB note: check Speed (MHz): 800 min/max: 800/1866 core: 1: 800 Graphics: Device-1: Advanced Micro Devices [AMD/ATI] RV370/M22 [Mobility Radeon X300] driver: radeon v: kernel Display: x11 server: X.org v: 1.21.1.8 with: Xwayland v: 22.1.9 driver: X: loaded: radeon,v4l dri: r300 gpu: radeon resolution: 1024x768~60Hz API: EGL v: 1.4,1.5 drivers: kms_swrast,r300,swrast platforms: gbm,x11,surfaceless,device API: OpenGL v: 4.5 compat-v: 2.1 vendor: mesa v: 25.0.7 renderer: llvmpipe (LLVM 15.0.6 128 bits) Network: Device-1: Broadcom NetXtreme BCM5751M Gigabit Ethernet PCI Express driver: tg3 Device-2: Intel PRO/Wireless 2200BG [Calexico2] Network driver: ipw2200
I set it to depend on kernel 6.6.137 as we tell users to use the latest cpupower and lib(64)bpf1 for backport kernel - and shall test so too. Also, I set same priority due to security. (actually our current backport is elder than released 6.6 series) Should we also likewise set QA contact to sec team?
Severity: normal => majorDepends on: (none) => 35459Assignee: kernel => qa-bugsPriority: Normal => High
OK x86_64 desktop flavour on Thinkpad T510, Plasma X11, nouveau kernel-stable-testing-desktop-6.18.26-1.stabletesting.mga9 Filesystems: separate /boot, then an LUKS encrypted pv used for LVM for /, /home, swap. All set up by installer. __OK: Surfing with Firefox watching video on internet over wifi LibreOffice, etc.. syncthing binary OK: suspend-resume hibernate works but fail to shut off power, instead blinks lamp and user need to hold power button to power off. (like all previus kernels for long time, maybe need nvidia binary blob) It restores the session next boot perfectly. inxi output like Bug 35459 Comment 16
OK x86_64 desktop, nvidia470 kernel-stable-testing-desktop-6.18.26-1.stabletesting.mga9 Machine: Asus G75V (with replaced GPU, downgraded) Integrated Intel HD Graphics (the nvidia GPU not used) Using an LUKS encrypted partition for LVM, which contain /, /home, swap. Separate /boot partition. All was set up by installer. Clean update, reboot § suspend-resume § hibernate-restore Minor issue, like always (maybe not kernel related): No sound, but is OK after suspend-resume or hibernate-restore cycle. Playing video in Firefox over wifi from internet Flatpak "update" command, flatpak Signal app Native binary Syncthing built-in video cam [morgan@republic ~]$ inxi -SMCGN System: Host: republic.tribun Kernel: 6.18.26-desktop-1.stabletesting.mga9 arch: x86_64 bits: 64 Desktop: KDE Plasma v: 5.27.10 Distro: Mageia 9 Machine: Type: Laptop System: ASUSTeK product: G75VW v: 1.0 serial: <superuser required> Mobo: ASUSTeK model: G75VW v: 1.0 serial: <superuser required> UEFI: American Megatrends v: G75VW.223 date: 01/07/2013 CPU: Info: quad core model: Intel Core i7-3610QM bits: 64 type: MT MCP cache: L2: 1024 KiB Speed (MHz): avg: 1197 min/max: 1200/3300 cores: 1: 1197 2: 1197 3: 1197 4: 1197 5: 1197 6: 1197 7: 1197 8: 1197 Graphics: Device-1: NVIDIA GK107M [GeForce GTX 660M] driver: nvidia v: 470.256.02 Device-2: Sunplus Innovation ASUS Webcam driver: uvcvideo type: USB Display: x11 server: X.org v: 1.21.1.8 with: Xwayland v: 22.1.9 driver: X: loaded: nvidia,v4l gpu: nvidia resolution: 1920x1080~60Hz API: EGL v: 1.5 drivers: nvidia,swrast platforms: x11,surfaceless,device API: OpenGL v: 4.6.0 compat-v: 4.5 vendor: nvidia mesa v: 470.256.02 renderer: NVIDIA GeForce GTX 660M/PCIe/SSE2 API: Vulkan v: 1.3.231 drivers: nvidia,llvmpipe surfaces: xcb,xlib Network: Device-1: Qualcomm Atheros AR9485 Wireless Network Adapter driver: ath9k Device-2: Qualcomm Atheros AR8151 v2.0 Gigabit Ethernet driver: atl1c
inxi -SMCGN System: Host: localhost Kernel: 6.18.26-desktop-1.stabletesting.mga9 arch: x86_64 bits: 64 Desktop: KDE Plasma v: 5.27.10 Distro: Mageia 9 Machine: Type: Desktop Mobo: ASUSTeK model: PRIME Q270M-C v: Rev X.0x serial: <superuser required> UEFI: American Megatrends v: 2201 date: 12/21/2023 CPU: Info: quad core model: Intel Core i5-7500 bits: 64 type: MCP cache: L2: 1024 KiB Speed (MHz): avg: 800 min/max: 800/3800 cores: 1: 800 2: 800 3: 800 4: 800 Graphics: Device-1: NVIDIA GM107GL [Quadro K620] driver: nouveau v: kernel Display: x11 server: X.org v: 1.21.1.8 with: Xwayland v: 22.1.9 driver: X: loaded: modesetting,v4l dri: nouveau gpu: nouveau resolution: 1920x1080~60Hz API: EGL v: 1.5 drivers: nouveau,swrast platforms: gbm,x11,surfaceless,device API: OpenGL v: 4.5 compat-v: 4.3 vendor: mesa v: 25.0.7 renderer: NV117 API: Vulkan v: 1.3.231 drivers: llvmpipe surfaces: xcb,xlib Network: Device-1: Intel Ethernet I219-LM driver: e1000e No installation issues. After the reboot I tried vlc(sound is OK), Gnome-Boxes, Dolphin, aVPN through Network Manager, Firefox, all with no issues.
CC: (none) => andrewsfarm
RH x86_64 installing kernel-stable-testing-server-devel-6.18.26-1.stabletesting.mga9-1-1.mga9.x86_64.rpm kernel-stable-testing-server-6.18.26-1.stabletesting.mga9-1-1.mga9.x86_64.rpm kernel-stable-testing-server-latest-6.18.26-1.stabletesting.mga9.x86_64.rpm kernel-stable-testing-server-devel-latest-6.18.26-1.stabletesting.mga9.x86_64.rpm from //home/katnatek/qa-testing/x86_64 Preparing... ################################################################################################### 1/4: kernel-stable-testing-server-latest ################################################################################################### 2/4: kernel-stable-testing-server-6.18.26-1.stabletesting.mga9 ################################################################################################### 3/4: kernel-stable-testing-server-devel-latest ################################################################################################### 4/4: kernel-stable-testing-server-devel-6.18.26-1.stabletesting.mga9 ################################################################################################### 1/2: removing kernel-stable-testing-server-devel-latest-6.18.4-3.stabletesting.mga9.x86_64 ################################################################################################### 2/2: removing kernel-stable-testing-server-latest-6.18.4-3.stabletesting.mga9.x86_64 ################################################################################################### vhba (20250329-1.mga9): Installing module. .................. ........ virtualbox (7.1.18-1.mga9): Installing module. .............. ........ You should restart your computer for kernel-stable-testing-server-6.18.26-1.stabletesting.mga9 LC_ALL=C urpmi kernel-stable-testing-userspace-headers The following package has to be removed for others to be upgraded: kernel-userspace-headers-6.6.137-1.mga9.x86_64 (due to conflicts with linux-userspace-headers[> 6.6.137-1.mga9]) (y/N) y installing kernel-stable-testing-userspace-headers-6.18.26-1.stabletesting.mga9.x86_64.rpm from //home/katnatek/qa-testing/x86_64 Preparing... ################################################################################################### 1/1: kernel-stable-testing-userspace-headers ################################################################################################### removing package kernel-userspace-headers-6.6.137-1.mga9.x86_64 1/1: removing kernel-userspace-headers-6.6.137-1.mga9.x86_64 ################################################################################################### Is normal to have to manually install kernel-stable-testing-userspace-headers? Will reboot to test
RH x86_64 uname -r 6.18.26-server-1.stabletesting.mga9 systemctl status shorewall shorewall6 ● shorewall.service - Shorewall IPv4 firewall Loaded: loaded (/usr/lib/systemd/system/shorewall.service; enabled; preset: enabled) Active: active (exited) since Sun 2026-05-03 18:48:56 CST; 35s ago Process: 2847 ExecStart=/sbin/shorewall $OPTIONS start $STARTOPTIONS (code=exited, status=0/SUCCESS) Main PID: 2847 (code=exited, status=0/SUCCESS) CPU: 416ms may 03 18:48:55 jgrey.phoenix shorewall[4030]: iptables: No chain/target/match by that name. may 03 18:48:55 jgrey.phoenix shorewall[4033]: Warning: Extension IFWLOG revision 0 not supported, missing kernel module? may 03 18:48:55 jgrey.phoenix shorewall[4033]: iptables: No chain/target/match by that name. may 03 18:48:56 jgrey.phoenix shorewall[4036]: Warning: Extension IFWLOG revision 0 not supported, missing kernel module? may 03 18:48:56 jgrey.phoenix shorewall[4036]: iptables: No chain/target/match by that name. may 03 18:48:56 jgrey.phoenix shorewall[4039]: Warning: Extension IFWLOG revision 0 not supported, missing kernel module? may 03 18:48:56 jgrey.phoenix shorewall[4039]: iptables: No chain/target/match by that name. may 03 18:48:56 jgrey.phoenix shorewall[3070]: Processing /etc/shorewall/started ... may 03 18:48:56 jgrey.phoenix shorewall[3070]: done. may 03 18:48:56 jgrey.phoenix systemd[1]: Finished shorewall.service. ● shorewall6.service - Shorewall IPv6 firewall Loaded: loaded (/usr/lib/systemd/system/shorewall6.service; enabled; preset: enabled) Active: active (exited) since Sun 2026-05-03 18:49:04 CST; 28s ago Process: 4057 ExecStart=/sbin/shorewall -6 $OPTIONS start $STARTOPTIONS (code=exited, status=0/SUCCESS) Main PID: 4057 (code=exited, status=0/SUCCESS) CPU: 266ms may 03 18:49:03 jgrey.phoenix shorewall[4396]: iptables: No chain/target/match by that name. may 03 18:49:03 jgrey.phoenix shorewall[4579]: Warning: Extension IFWLOG revision 0 not supported, missing kernel module? may 03 18:49:04 jgrey.phoenix shorewall[4579]: iptables: No chain/target/match by that name. may 03 18:49:04 jgrey.phoenix shorewall[4582]: Warning: Extension IFWLOG revision 0 not supported, missing kernel module? may 03 18:49:04 jgrey.phoenix shorewall[4582]: iptables: No chain/target/match by that name. may 03 18:49:04 jgrey.phoenix shorewall[4645]: ip6tables v1.8.9 (legacy): Couldn't load target `Ifw':No such file or directory may 03 18:49:04 jgrey.phoenix shorewall[4645]: Try `ip6tables -h' or 'ip6tables --help' for more information. may 03 18:49:04 jgrey.phoenix shorewall[4089]: Processing /etc/shorewall6/started ... may 03 18:49:04 jgrey.phoenix shorewall[4089]: done. may 03 18:49:04 jgrey.phoenix systemd[1]: Finished shorewall6.service. Will test the recomendation in https://bugs.mageia.org/show_bug.cgi?id=35459#c23
modprobe ipt_IFWLOG modprobe: ERROR: could not insert 'ipt_IFWLOG': Cannot allocate memory
(In reply to katnatek from comment #12) > modprobe ipt_IFWLOG > modprobe: ERROR: could not insert 'ipt_IFWLOG': Cannot allocate memory what is the output of the "free" command? If you're experiencing a shortage of free RAM with the command above and want to avoid excessive swapping, you can use compressed zram. E.g. install the "zramstart" package and then start it with "systemctl start mkzram.service".
(In reply to Giuseppe Ghibò from comment #13) > (In reply to katnatek from comment #12) > > > modprobe ipt_IFWLOG > > modprobe: ERROR: could not insert 'ipt_IFWLOG': Cannot allocate memory > > what is the output of the "free" command? > > If you're experiencing a shortage of free RAM with the command above and > want to avoid excessive swapping, you can use compressed zram. E.g. install > the "zramstart" package and then start it with "systemctl start > mkzram.service". free -h total used free shared buff/cache available Mem: 5.6Gi 2.1Gi 712Mi 82Mi 2.8Gi 3.1Gi Swap: 31Gi 0B 31Gi Have to make additional work to fix the issue just not look OK to me
That deserves further investigation, as you have 32GB of swap, for a total of 36GB. I tried booting a VM with just 2GB of RAM and then running swapoff -a, and it didn't produce the memory allocation error.
(In reply to Giuseppe Ghibò from comment #15) > That deserves further investigation, as you have 32GB of swap, for a total > of 36GB. I tried booting a VM with just 2GB of RAM and then running swapoff > -a, and it didn't produce the memory allocation error. I think the issue could be in kernel-stable-testing-userspace-headers And also get this now in uname -r 6.18.4-server-3.stabletesting.mga9 And I was not have the error in this kernel Will test now
uname -r 6.18.26-server-1.stabletesting.mga9 rpm -q kernel-userspace-headers kernel-userspace-headers-6.6.137-1.mga9 systemctl status shorewall shorewall6 ● shorewall.service - Shorewall IPv4 firewall Loaded: loaded (/usr/lib/systemd/system/shorewall.service; enabled; preset: enabled) Active: active (exited) since Sun 2026-05-03 19:51:55 CST; 55s ago ● shorewall.service - Shorewall IPv4 firewall Loaded: loaded (/usr/lib/systemd/system/shorewall.service; enabled; preset: enabled) Active: active (exited) since Sun 2026-05-03 19:51:55 CST; 55s ago Process: 2612 ExecStart=/sbin/shorewall $OPTIONS start $STARTOPTIONS (code=exited, status=0/SUCCESS) Main PID: 2612 (code=exited, status=0/SUCCESS) CPU: 338ms may 03 19:51:50 jgrey.phoenix shorewall[2741]: Processing /etc/shorewall/tcclear ... may 03 19:51:51 jgrey.phoenix shorewall[2741]: Setting up Route Filtering... may 03 19:51:51 jgrey.phoenix shorewall[2741]: Setting up Martian Logging... may 03 19:51:51 jgrey.phoenix shorewall[2741]: Setting up Proxy ARP... may 03 19:51:51 jgrey.phoenix shorewall[2741]: Preparing iptables-restore input... may 03 19:51:51 jgrey.phoenix shorewall[2741]: Running /sbin/iptables-restore --wait 60... may 03 19:51:52 jgrey.phoenix shorewall[2741]: Processing /etc/shorewall/start ... may 03 19:51:57 jgrey.phoenix shorewall[2741]: Processing /etc/shorewall/started ... may 03 19:51:57 jgrey.phoenix shorewall[2741]: done. may 03 19:51:55 jgrey.phoenix systemd[1]: Finished shorewall.service. ● shorewall6.service - Shorewall IPv6 firewall Loaded: loaded (/usr/lib/systemd/system/shorewall6.service; enabled; preset: enabled) Active: active (exited) since Sun 2026-05-03 19:51:58 CST; 55s ago Process: 3341 ExecStart=/sbin/shorewall -6 $OPTIONS start $STARTOPTIONS (code=exited, status=0/SUCCESS) Main PID: 3341 (code=exited, status=0/SUCCESS) CPU: 222ms may 03 19:51:58 jgrey.phoenix shorewall[3375]: Running /sbin/ip6tables-restore --wait 60... may 03 19:51:58 jgrey.phoenix shorewall[3375]: Processing /etc/shorewall6/start ... may 03 19:51:58 jgrey.phoenix shorewall[3442]: iptables: Chain already exists. may 03 19:51:58 jgrey.phoenix shorewall[3443]: ipset v7.21: Set cannot be created: set with the same name already exists may 03 19:51:58 jgrey.phoenix shorewall[3445]: ipset v7.21: Set cannot be created: set with the same name already exists may 03 19:51:58 jgrey.phoenix shorewall[3470]: ip6tables v1.8.9 (legacy): Couldn't load target `Ifw':No such file or directory may 03 19:51:58 jgrey.phoenix shorewall[3470]: Try `ip6tables -h' or 'ip6tables --help' for more information. may 03 19:51:58 jgrey.phoenix shorewall[3375]: Processing /etc/shorewall6/started ... may 03 19:51:58 jgrey.phoenix shorewall[3375]: done. may 03 19:51:58 jgrey.phoenix systemd[1]: Finished shorewall6.service. lsmod|grep ipt_IFWLOG ipt_IFWLOG 12288 46 x_tables 53248 28 ipt_psd,ip6table_filter,xt_conntrack,ip6table_raw,iptable_filter,ip6table_nat,xt_LOG,xt_multiport,xt_NFLOG,xt_tcpudp,xt_hashlimit,xt_addrtype,xt_CHECKSUM,xt_recent,xt_comment,xt_set,ip6_tables,ipt_REJECT,ipt_IFWLOG,xt_CT,iptable_raw,ip_tables,iptable_nat,ip6table_mangle,xt_MASQUERADE,ip6t_REJECT,iptable_mangle,xt_mark So something is not compatible with kernel-stable-testing-userspace-headers
I dont know how to tag a bug to be both backport and security...
QA Contact: (none) => security
I think this is tested enough. @katnatek, you handle the procedure for releasing backport.
(In reply to Morgan Leijström from comment #19) > I think this is tested enough. > > @katnatek, you handle the procedure for releasing backport. As always team leader have to validate, I'll send a mail to backports-announce, when packages have been moved from testing to backports, but will need a CVE list for this if we want additional information beyond "this release fix security vulnerabilities" BTW, the issue with kernel-stable-testing-userspace-headers and shorewall/iptables is for me bad enough to not ask for validation (comment 11 & comment 12 vs comment 17)
OK Do you know if that same problem is in mga10 kernel? I dont really understand, not my cup of tea, but user should manually select the *userspace-headers for chosen kernel, right? ( Mentioned in https://wiki.mageia.org/en/Kernel_flavours#Backport_kernels )
(In reply to Morgan Leijström from comment #21) > OK > > Do you know if that same problem is in mga10 kernel? > > I dont really understand, not my cup of tea, but user should manually select > the *userspace-headers for chosen kernel, right? > ( Mentioned in https://wiki.mageia.org/en/Kernel_flavours#Backport_kernels ) I will check today (I hope)
uname -r 6.18.26-desktop-3.mga10 uname -r 6.18.26-desktop-3.mga10 rpm -q kernel-userspace-headers kernel-userspace-headers-6.18.26-3.mga10 systemctl status shorewall sho shorewall6.service shorewall.service [root@localhost ~]# systemctl status shorewall shorewall6 ● shorewall.service - Shorewall IPv4 firewall Loaded: loaded (/usr/lib/systemd/system/shorewall.service; enabled; preset: enabled) Active: active (exited) since Tue 2026-05-05 12:22:37 CST; 2min 39s ago Invocation: 668587a72088479c9086c6adca8e3875 Process: 1341 ExecStart=/sbin/shorewall $OPTIONS start $STARTOPTIONS (code=exited, status=0/SUCCESS) Main PID: 1341 (code=exited, status=0/SUCCESS) Mem peak: 10.5M CPU: 347ms may 05 12:22:34 localhost.localdomain shorewall[1388]: Processing /etc/shorewall/tcclear ... may 05 12:22:34 localhost.localdomain shorewall[1388]: Setting up Route Filtering... may 05 12:22:34 localhost.localdomain shorewall[1388]: Setting up Martian Logging... may 05 12:22:34 localhost.localdomain shorewall[1388]: Setting up Proxy ARP... may 05 12:22:34 localhost.localdomain shorewall[1388]: Preparing iptables-restore input... may 05 12:22:34 localhost.localdomain shorewall[1388]: Running /sbin/iptables-restore --wait 60... may 05 12:22:36 localhost.localdomain shorewall[1388]: Processing /etc/shorewall/start ... may 05 12:22:37 localhost.localdomain shorewall[1388]: Processing /etc/shorewall/started ... may 05 12:22:37 localhost.localdomain shorewall[1388]: done. may 05 12:22:37 localhost.localdomain systemd[1]: Finished Shorewall IPv4 firewall. ● shorewall6.service - Shorewall IPv6 firewall Loaded: loaded (/usr/lib/systemd/system/shorewall6.service; enabled; preset: enabled) Active: active (exited) since Tue 2026-05-05 12:22:38 CST; 2min 39s ago Invocation: ecd70fa5f8ca47ef8742eb3353e195d5 Process: 1500 ExecStart=/sbin/shorewall -6 $OPTIONS start $STARTOPTIONS (code=exited, status=0/SUCCESS) Main PID: 1500 (code=exited, status=0/SUCCESS) Mem peak: 7.2M CPU: 194ms may 05 12:22:37 localhost.localdomain shorewall[1551]: Starting Shorewall6.... may 05 12:22:37 localhost.localdomain shorewall[1551]: Initializing... may 05 12:22:37 localhost.localdomain shorewall[1551]: Processing /etc/shorewall6/init ... may 05 12:22:37 localhost.localdomain shorewall[1551]: Setting up Proxy NDP... may 05 12:22:37 localhost.localdomain shorewall[1551]: Preparing ip6tables-restore input... may 05 12:22:37 localhost.localdomain shorewall[1551]: Running /sbin/ip6tables-restore --wait 60... may 05 12:22:37 localhost.localdomain shorewall[1551]: Processing /etc/shorewall6/start ... may 05 12:22:38 localhost.localdomain shorewall[1551]: Processing /etc/shorewall6/started ... may 05 12:22:38 localhost.localdomain shorewall[1551]: done. may 05 12:22:38 localhost.localdomain systemd[1]: Finished Shorewall IPv6 firewall. lsmod|grep ipt_IFWLOG ipt_IFWLOG 12288 1 x_tables 53248 25 ipt_psd,ip6table_filter,xt_conntrack,ip6table_raw,iptable_filter,ip6table_nat,xt_LOG,xt_NFLOG,xt_tcpudp,xt_hashlimit,xt_addrtype,xt_recent,xt_comment,xt_set,ip6_tables,ipt_REJECT,ipt_IFWLOG,xt_CT,iptable_raw,ip_tables,iptable_nat,ip6table_mangle,ip6t_REJECT,iptable_mangle,xt_mark The issue not exist here, same hardware
Same hardware as comment 9: $ uname -r 6.18.26-desktop-1.stabletesting.mga9 # systemctl status shorewall shorewall6 ● shorewall.service - Shorewall IPv4 firewall Loaded: loaded (/usr/lib/systemd/system/shorewall.service; enabled; preset: enabled) Active: active (exited) since Tue 2026-05-05 19:51:59 EDT; 3h 55min left Process: 4778 ExecStart=/sbin/shorewall $OPTIONS start $STARTOPTIONS (code=exited, status=0/SUCCESS) Main PID: 4778 (code=exited, status=0/SUCCESS) CPU: 207ms May 05 19:51:59 localhost shorewall[4832]: Setting up Route Filtering... May 05 19:51:59 localhost shorewall[4832]: Setting up Martian Logging... May 05 19:51:59 localhost shorewall[4832]: Setting up Proxy ARP... May 05 19:51:59 localhost shorewall[4832]: Preparing iptables-restore input... May 05 19:51:59 localhost shorewall[4832]: Running /sbin/iptables-restore --wait 60... May 05 19:51:59 localhost shorewall[4832]: Processing /etc/shorewall/start ... May 05 19:51:59 localhost shorewall[4832]: Processing /etc/shorewall/started ... May 05 19:51:59 localhost root[5026]: Shorewall started May 05 19:51:59 localhost shorewall[4832]: done. May 05 19:51:59 localhost systemd[1]: Finished shorewall.service. ● shorewall6.service - Shorewall IPv6 firewall Loaded: loaded (/usr/lib/systemd/system/shorewall6.service; enabled; preset: enabled) Active: active (exited) since Tue 2026-05-05 19:51:59 EDT; 3h 55min left Process: 5030 ExecStart=/sbin/shorewall -6 $OPTIONS start $STARTOPTIONS (code=exited, status=0/SUCCESS) Main PID: 5030 (code=exited, status=0/SUCCESS) CPU: 190ms May 05 19:51:59 localhost shorewall[5072]: Processing /etc/shorewall6/start ... May 05 19:51:59 localhost shorewall[5121]: iptables: Chain already exists. May 05 19:51:59 localhost shorewall[5122]: ipset v7.21: Set cannot be created: set with the same name already exists May 05 19:51:59 localhost shorewall[5124]: ipset v7.21: Set cannot be created: set with the same name already exists May 05 19:51:59 localhost shorewall[5127]: ip6tables v1.8.9 (legacy): Couldn't load target `Ifw':No such file or directory May 05 19:51:59 localhost shorewall[5127]: Try `ip6tables -h' or 'ip6tables --help' for more information. May 05 19:51:59 localhost shorewall[5072]: Processing /etc/shorewall6/started ... May 05 19:51:59 localhost root[5136]: Shorewall6 started May 05 19:51:59 localhost shorewall[5072]: done. May 05 19:51:59 localhost systemd[1]: Finished shorewall6.service. [root@localhost ~]# modprobe ipt_IFWLOG That last command doesn't return anything. So I'm not seeing it. But, this machine has 48GB of RAM to play with. That might make a difference. And one other thing I just noticed - My test and katnatek's MGA10 test were both with the desktop kernel, but the failed tests were with the MGA9 server kernel. Probably wouldn't make a difference, but it is a variable.
I removed the desktop kernel and installed the server kernel, then tried again. Essentially the same results.
(In reply to katnatek from comment #17) > > So something is not compatible with kernel-stable-testing-userspace-headers What are you / your system using that package for? From the package description: "C header files from the Linux kernel. The header files define structures and constants that are needed for building most standard programs."
Created attachment 15549 [details] List of CVEs
Isn't it possible you're using a particularly complex Shorewall rule? Or a customized rule that might cause recursion and exhaust memory?
(In reply to Thomas Andrews from comment #24) > So I'm not seeing it. But, this machine has 48GB of RAM to play with. That > might make a difference. > > And one other thing I just noticed - My test and katnatek's MGA10 test were > both with the desktop kernel, but the failed tests were with the MGA9 server > kernel. Probably wouldn't make a difference, but it is a variable. try after install kernel-stable-testing-userspace-headers
(In reply to Giuseppe Ghibò from comment #28) > Isn't it possible you're using a particularly complex Shorewall rule? Or a > customized rule that might cause recursion and exhaust memory? The only "complex" thing I do in this system is enabling the sssh jail for fail2ban I'm not have any particular knowledge that allows me complex shorewall/iptables rules Later will try to add fail2ban to cauldron system (I forgot to do it)
(In reply to Morgan Leijström from comment #26) > What are you / your system using that package for? > > From the package description: > > "C header files from the Linux kernel. The header files define structures > and constants that are needed for building most standard programs." LC_ALL=C urpme kernel-userspace-headers --test To satisfy dependencies, the following 43 packages will be removed (1.5GB): bm-3.4-1.mga9.noarch (due to missing rpm-build) cargo-1.82.0-1.mga9.x86_64 (due to missing rust) cdemu-client-3.2.5-2.mga9.noarch (due to unsatisfied cdemu-daemon >= 3.2.5) cdemu-daemon-3.2.7-1.2.mga9.x86_64 (due to missing kmod(vhba.ko)) cmake-rpm-macros-9-9.mga9.noarch (due to unsatisfied rpm-mageia-setup-build >= 2.46-3) dkms-2.0.19-46.mga9.noarch (due to missing kernel-devel) dkms-vhba-20250329-1.mga9.noarch (due to missing dkms, due to missing dkms[*]) dkms-virtualbox-7.1.18-1.mga9.x86_64 (due to unsatisfied dkms >= 2.0.19-37, due to unsatisfied dkms >= 2.0.19-37) fonts-srpm-macros-2.0.5-6.mga9.noarch (due to missing rpm-mageia-setup-build) gcc-12.3.0-3.mga9.x86_64 (due to missing devel(libm(64bit)), due to unsatisfied glibc-devel >= 2.4-1) gcc-c++-12.3.0-3.mga9.x86_64 (due to unsatisfied gcc == 12.3.0-3.mga9, due to missing libgomp-devel) glibc-devel-2.36-59.mga9.x86_64 (due to missing linux-userspace-headers) go-srpm-macros-3.2.0-1.mga9.noarch (due to missing rpm-mageia-setup-build) kernel-desktop-devel-6.6.130-1.mga9.x86_64 (due to missing glibc-devel, due to missing gcc, due to missing ncurses-devel, due to missing pkgconfig(libelf)) kernel-desktop-devel-6.6.137-1.mga9.x86_64 (due to missing glibc-devel, due to missing gcc, due to missing ncurses-devel, due to missing pkgconfig(libelf)) kernel-linus-devel-6.6.130-1.mga9.x86_64 (due to missing glibc-devel, due to missing gcc, due to missing ncurses-devel, due to missing pkgconfig(libelf)) kernel-linus-devel-6.6.137-1.mga9.x86_64 (due to missing glibc-devel, due to missing gcc, due to missing ncurses-devel, due to missing pkgconfig(libelf)) kernel-server-devel-6.6.120-1.mga9.x86_64 (due to missing glibc-devel, due to missing gcc, due to missing ncurses-devel, due to missing pkgconfig(libelf)) kernel-server-devel-6.6.130-1.mga9.x86_64 (due to missing glibc-devel, due to missing gcc, due to missing ncurses-devel, due to missing pkgconfig(libelf)) kernel-server-devel-6.6.137-1.mga9.x86_64 (due to missing glibc-devel, due to missing gcc, due to missing ncurses-devel, due to missing pkgconfig(libelf)) kernel-stable-testing-server-devel-6.18.26-1.stabletesting.mga9-1-1.mga9.x86_64 (due to missing glibc-devel, due to missing gcc, due to missing ncurses-devel, due to missing pkgconfig(libelf)) kernel-stable-testing-server-devel-6.18.4-3.stabletesting.mga9-1-1.mga9.x86_64 (due to missing glibc-devel, due to missing gcc, due to missing ncurses-devel, due to missing pkgconfig(libelf)) kernel-stable-testing-server-devel-latest-6.18.26-1.stabletesting.mga9.x86_64 (due to missing kernel-stable-testing-server-devel-6.18.26-1.stabletesting.mga9) kernel-userspace-headers-6.6.137-1.mga9.x86_64 lib64audit-devel-3.1.2-1.mga9.x86_64 (due to missing devel(libcap-ng(64bit)), due to missing pkgconfig(libcap-ng)) lib64brotli-devel-1.0.9-5.mga9.x86_64 (due to missing devel(libm(64bit))) lib64cap-ng-devel-0.8.3-3.mga9.x86_64 (due to unsatisfied kernel-headers >= 2.6.11) lib64curl-devel-7.88.1-4.9.mga9.x86_64 (due to missing devel(libbrotlidec(64bit)), due to missing devel(libgssapi_krb5(64bit)), due to missing devel(libssh(64bit)), due to missing devel(liblber-2.5(64bit)), due to missing devel(libldap-2.5(64bit))) lib64elfutils-devel-0.189-1.1.mga9.x86_64 (due to missing devel(libcurl(64bit))) lib64krb53-devel-1.20.1-1.4.mga9.x86_64 (due to missing devel(libresolv(64bit))) lib64ldap2.5_0-devel-2.5.14-1.mga9.x86_64 (due to missing devel(libsasl2(64bit))) lib64marnav-devel-0.14.0-8.git20230504.mga9.x86_64 (due to missing devel(libm(64bit)), due to missing devel(libgcc_s(64bit))) lib64ncurses-devel-6.3-20221203.2.1.mga9.x86_64 (due to missing devel(libgcc_s(64bit))) lib64pam-devel-1.5.2-5.2.mga9.x86_64 (due to missing devel(libaudit(64bit))) lib64sasl2-devel-2.1.27-7.mga9.x86_64 (due to missing pam-devel) lib64ssh-devel-0.10.6-1.mga9.x86_64 (due to missing devel(libgssapi_krb5(64bit))) libgomp-devel-12.3.0-3.mga9.x86_64 (due to unsatisfied gcc == 12.3.0-3.mga9) mgarepo-1.14.4-2.mga9.noarch (due to missing rpm-build, due to missing rpm-mageia-setup-build) rpm-build-4.18.2-1.mga9.x86_64 (due to missing gcc-c++, due to unsatisfied rpm-mageia-setup-build >= 1.34) rpm-mageia-setup-build-2.71-1.1.mga9.x86_64 (due to missing rpm-build, due to missing go-srpm-macros, due to missing fonts-srpm-macros, due to unsatisfied cmake-rpm-macros >= 1:9-8) rust-1.82.0-1.mga9.x86_64 (due to missing devel(libgcc_s(64bit)), due to missing gcc, due to unsatisfied rust-std-static(x86-64) == 1.82.0-1.mga9) rust-std-static-1.82.0-1.mga9.x86_64 (due to unsatisfied glibc-devel(x86-64) >= 2.17, due to unsatisfied rust == 1.82.0-1.mga9) virtualbox-7.1.18-1.mga9.x86_64 (due to unsatisfied kmod(vboxdrv.ko) == 7.1.18) Remove 43 packages? (y/N)
(In reply to katnatek from comment #29) > (In reply to Thomas Andrews from comment #24) > > So I'm not seeing it. But, this machine has 48GB of RAM to play with. That > > might make a difference. > > > > And one other thing I just noticed - My test and katnatek's MGA10 test were > > both with the desktop kernel, but the failed tests were with the MGA9 server > > kernel. Probably wouldn't make a difference, but it is a variable. > > try after install kernel-stable-testing-userspace-headers Tests in comment 24 and comment 25 were done with that package installed.
(In reply to Morgan Leijström from comment #26) > (In reply to katnatek from comment #17) > > > > So something is not compatible with kernel-stable-testing-userspace-headers > > What are you / your system using that package for? > > From the package description: > > "C header files from the Linux kernel. The header files define structures > and constants that are needed for building most standard programs." dkms uses it when building modules locally, like the proprietary nvidia drivers, or virtualbox.
(In reply to katnatek from comment #10) > RH x86_64 > > installing > kernel-stable-testing-server-devel-6.18.26-1.stabletesting.mga9-1-1.mga9. > x86_64.rpm > kernel-stable-testing-server-6.18.26-1.stabletesting.mga9-1-1.mga9.x86_64. > rpm > kernel-stable-testing-server-latest-6.18.26-1.stabletesting.mga9.x86_64.rpm > kernel-stable-testing-server-devel-latest-6.18.26-1.stabletesting.mga9. > x86_64.rpm from //home/katnatek/qa-testing/x86_64 > Preparing... > ############################################################################# > ###################### > 1/4: kernel-stable-testing-server-latest > > ############################################################################# > ###################### > 2/4: kernel-stable-testing-server-6.18.26-1.stabletesting.mga9 > > ############################################################################# > ###################### > 3/4: kernel-stable-testing-server-devel-latest > > ############################################################################# > ###################### > 4/4: kernel-stable-testing-server-devel-6.18.26-1.stabletesting.mga9 > > ############################################################################# > ###################### > 1/2: removing > kernel-stable-testing-server-devel-latest-6.18.4-3.stabletesting.mga9.x86_64 > > ############################################################################# > ###################### > 2/2: removing > kernel-stable-testing-server-latest-6.18.4-3.stabletesting.mga9.x86_64 > > ############################################################################# > ###################### > > vhba (20250329-1.mga9): Installing module. > .................. > ........ > virtualbox (7.1.18-1.mga9): Installing module. > .............. > ........ > You should restart your computer for > kernel-stable-testing-server-6.18.26-1.stabletesting.mga9 > > LC_ALL=C urpmi kernel-stable-testing-userspace-headers > The following package has to be removed for others to be upgraded: > kernel-userspace-headers-6.6.137-1.mga9.x86_64 > (due to conflicts with linux-userspace-headers[> 6.6.137-1.mga9]) (y/N) y > > > installing > kernel-stable-testing-userspace-headers-6.18.26-1.stabletesting.mga9.x86_64. > rpm from //home/katnatek/qa-testing/x86_64 > Preparing... > ############################################################################# > ###################### > 1/1: kernel-stable-testing-userspace-headers > > ############################################################################# > ###################### > removing package kernel-userspace-headers-6.6.137-1.mga9.x86_64 > 1/1: removing kernel-userspace-headers-6.6.137-1.mga9.x86_64 > > ############################################################################# > ###################### > > Is normal to have to manually install > kernel-stable-testing-userspace-headers? > > Will reboot to test It is normal to have to install the userspace-headers in backports, for two reasons: the backports repos are not normally activated for updating, and even if the are, kernel-stable-testing-userspace-headers would not be seen as an update to kernel-userspace-headers. I see that you installed the kernel before you installed the headers. That means the virtualbox modules were built using the wrong headers. Dkms and the devel package don't care which headers package is installed, they only look to see that there is one. I don't know what difference that makes. In my tests, I installed the headers package before going after the kernels, so nvidia-current was built using the correct headers. I neglected to have dkms-virtualbox installed on this machine, because I didn't think of it, so VirtualBox won't work with this kernel as a consequence.
(In reply to Thomas Andrews from comment #34) > (In reply to katnatek from comment #10) > > Is normal to have to manually install > > kernel-stable-testing-userspace-headers? > > > > Will reboot to test > > It is normal to have to install the userspace-headers in backports, for two > reasons: the backports repos are not normally activated for updating, and > even if the are, kernel-stable-testing-userspace-headers would not be seen > as an update to kernel-userspace-headers. > > I see that you installed the kernel before you installed the headers. That > means the virtualbox modules were built using the wrong headers. Dkms and > the devel package don't care which headers package is installed, they only > look to see that there is one. I don't know what difference that makes. > > In my tests, I installed the headers package before going after the kernels, > so nvidia-current was built using the correct headers. I neglected to have > dkms-virtualbox installed on this machine, because I didn't think of it, so > VirtualBox won't work with this kernel as a consequence. I figure that, but not affect to behavior of shorewall issue , next iteration I'll try to install first the kernel-stable-testing-userspace-headers. BTW virtualbox is working with this kernel and dkms-virtualbox
(In reply to Thomas Andrews from comment #33) > (In reply to Morgan Leijström from comment #26) > > (In reply to katnatek from comment #17) > > > > > > So something is not compatible with kernel-stable-testing-userspace-headers > > > > What are you / your system using that package for? > > > > From the package description: > > > > "C header files from the Linux kernel. The header files define structures > > and constants that are needed for building most standard programs." > > dkms uses it when building modules locally, like the proprietary nvidia > drivers, or virtualbox. Oh... Shit, I had the backport kernel-stable-testing-userspace-headers installed while installing kernel 6.6.137 on my Asus G75V, so it was used when building nvidia470 and virtualbox kernel modules... The result worked well, and I then erroneously reported OK for my tests for desktop and linus kernel flavours 6.6.137 with nvidia470 and VirtualBox 7.1.18 - using kmods built using the wrong *-userspace-headers package for that kernel :( I now added the "Take care to have the corresponding *-userspace-headers"... paragraph in https://wiki.mageia.org/en/Kernel_flavours#Backport_kernels Please check if I got that correct.
We'd have to ask Giuseppe, but I have reason to believe that building modules with a header package that's newer than the kernel is usually less of a problem than using an older one. I base this on the fact that unlike the kernels and kernel-devel packages, the userspace-headers package is treated like any ordinary update - it's replaced by the update. Like cpupower. That means that it's not there if you boot into an older kernel where a module had not yet been built. Again, that's mere speculation on my part. If I'm wrong, it makes things tricky to handle. Just as the headers package for the backported kernel has to be installed manually before installing the kernel, the headers package for the non-backported kernel would have to be installed manually before installing/updating that kernel. (You see where I'm going with this...)
(In reply to Thomas Andrews from comment #37) > We'd have to ask Giuseppe, but I have reason to believe that building > modules with a header package that's newer than the kernel is usually less > of a problem than using an older one. I base this on the fact that unlike > the kernels and kernel-devel packages, the userspace-headers package is > treated like any ordinary update - it's replaced by the update. Like > cpupower. That means that it's not there if you boot into an older kernel > where a module had not yet been built. > > Again, that's mere speculation on my part. If I'm wrong, it makes things > tricky to handle. Just as the headers package for the backported kernel has > to be installed manually before installing the kernel, the headers package > for the non-backported kernel would have to be installed manually before > installing/updating that kernel. (You see where I'm going with this...) Your intuition is mostly correct. It' not that you have to follow manually the -userspace-headers. The kernel-stable-testing series for Mageia 9 (but also kernel-stable, kernel-lts, and kernel-mainline) was designed to be mostly "invisible", meaning you can install and uninstall them as you wish without "interfering" with the stock kernel (which remains at 6.6.137), or to have the smallest footprint as possible (otherwise they'd be provided as fully update of stock kernel). It was added, with some limitations, to allow users to benefit from and test the latest series, e.g., to see if a certain new hardware is supported, without risking breakage or losing the most stable kernel, as well as to start testing upcoming next releases. This should be considered as an extra added value. AFAIK, it won't update or obsolete anything of the older stock kernel. This is true for the main binaries, but with some limitations for -sources or -userspace-headers. If you install just: kernel-stable-testing-desktop-latest kernel-stable-testing-desktop-devel-latest you'll have already everything required to build the modules (nvidia and virtualbox, mainly, as well as other dkms- packages). Of course, since prebuilt kernel modules for virtualbox aren't provided for this series (like for kernel-linus), you need to install dkms-virtualbox manually, as this package isn't installed automatically if you never did previously and were relying only on prebuilt modules. But AFAIK, this information was alrady included in the notes when the stable-testing series was released in backports the first time. In this case, by default, the older (stock) kernel-userspace-headers-6.6.137 will be *kept* and used to build the modules even under kernel-stable-testing-desktop 6.18.26-1.mga9, and will work. These are "userspace" headers, which are generally stable across releases, so you can use the older version even with the new kernel. The kernelspace headers are, instead, in their own -devel package and are (fully multiversioned) installed at the same kernel version. The same applies to the cpufreq utils, which are userspace utilities and change less frequently. These utils aren't yet provided in a fully "multiversioned" or simply "updated to the latest", but you'll continue to use the ones from stock kernel. The kernel-stable-testing-userspace-headers package can be installed, if you want to 'develop' with this kernel, such as building other newer packages, or if you want the userspace headers to be "strictly" in sync with the kernel you're using, but you are not obliged to do so by the package Requirements topology. You get it automatically installed also when you install all the packages from the 'filelist' in this bug, but it isn't automatically retrieved by the minimal requirement. Of course, since there can only be ONE set of -userspace-headers (as I said, this it's not fully "multiversioned"), it's "mutually exclusive" with the package kernel-userspace-headers. So, if you install it, 'kernel-userspace-headers-6.6.137' will be uninstalled, and vice versa, if you want to reinstall 'kernel-userspace-headers-6.6.137', then 'kernel-stable-testing-userspace-headers-6.18.26-1.mga9' will be uninstalled, but you aren't obliged to do so. Of course, if you install "kernel-stable-testing-userspace-headers", it will be used to build for any dkms module (older or newer, it doesn’t matter) from that point on. You might wonder why -userspace-headers, cpufreq, etc., weren't also "fully" multiversioned too, but that's another story. So to resume, the minimal requirement for end users is just to install: kernel-stable-testing-desktop-latest for plain operations, as well as: kernel-stable-testing-desktop-devel-latest and the corresponding dkms-<package>, for operations involving building of kernel modules (e.g., virtualbox, etc.). The other userspace headers are facultative and aren't installed automatically.
Thanks, corrected wiki page.
Maybe we should should we move this bug to 6.18.28-1, now building.
(In reply to Morgan Leijström from comment #40) > Maybe we should should we move this bug to 6.18.28-1, now building. I asked for a stop building for 6.18.28 in sysadmin, because I pushed too early and missed this had yet to be validated.
I didn't validate because the source of katnatek's shorewall issue hasn't been identified yet. I was wrong about needing a certain kernel-userspace-headers to build modules correctly, but that doesn't explain why the issue comes up on his hardware if the backported headers package is installed after those modules are built.
(In reply to Thomas Andrews from comment #42) > I didn't validate because the source of katnatek's shorewall issue hasn't > been identified yet. I was wrong about needing a certain > kernel-userspace-headers to build modules correctly, but that doesn't > explain why the issue comes up on his hardware if the backported headers > package is installed after those modules are built. OK. Build stopped. The new bug, to be addressed after this is completed, is being prepared as #35503.
I think we should jump to the new backport kernel as it fix an additional cve If I and only I got the shorewall/ipatables issue then after a decent test we could validate
I think so too. I any user get problem, he can easily boot the former version. (which would not be the case if problem was in release repo kernel in mga10)
Need to move on! Comment 44 I read as jump to new version and release it after other have not found shorewall/ipatables (or other) issues. Did I read that correctly? If so we should get backport kernel updated now to 6.18.29+ to test, as we need that DirtyFrag fixes anyway.
(In reply to Morgan Leijström from comment #46) > Need to move on! > > Comment 44 I read as jump to new version and release it after other have not > found shorewall/ipatables (or other) issues. > > Did I read that correctly? > > If so we should get backport kernel updated now to 6.18.29+ to test, > as we need that DirtyFrag fixes anyway. I try to say that current kernel in backport testing should dropped and new backport testing kernel with the additional cve fixed be tested. I think we should not hurry up backport kernel, users worried of vulnerabilities fixed should use regular kernel meanwhile
Ok, then let's skip this version, and move directly to the next one (6.18.30+ or 6.18.31).