This message was deleted.
# rancher-desktop
a
This message was deleted.
馃憤 2
w
What was the driver for the WSL kernel level bump? with WSL being OS features, kernel msi, and msix for the rest orchestrating for a large audience can be fun. especially if general store access is blocked. wasn't sure if some of the new features in WSL are being used instead of the older host-resolver and gvisor type products.
f
Because the distro switched to Alpine 3.19, which switches from iptables-legacy to nftables, which needs kernel support that is only in 5.15+
馃憤 1
I'm not keen on trying to support both iptables and nftables, but if this turns out to be a bigger problem, and somebody can figure out how to dynamically downgrade back to iptables-legacy for older kernel versions, then we may consider doing this for 1.14. I just worry that in the end this will create bigger problems in support, so somebody will have to twist my arm at least a little to make this happen 馃槃
This is the Alpine change that is the root cause for this requirement: Alpine Linux should default to nf_tables backend (#14058) 路 Issues 路 alpine / aports 路 GitLab
w
cool makes complete sense. wasn't aware of the switch to nftables so good to know myself as there always seems to be wsl gremlins I get called in on
I completely understand the frustration, but requiring support for an ancient kernel doesn't seem sensible to me.
馃憤 1
w
yup in our case its how to get folks to the recent releases that has been the challenge. there are some bugs in both the MSIX and Store based integration that can trip up normal maintenance activity so we have needed to put all the bits in custom installer and try and handle the possible issues. What this means is for the moment we are chasing all the versions of the installs. We are hoping to get back to Store maintenance and auto-updates, but involves moving to WU4B and a couple other tweaks. hybrid managed/public is not ell supported just yet from the policy controls in the OS.