config/env/sys-fs/zfs-kmod: un-break zfs-kmod binpkg install

[t-lo]

This change sets SKIP_KERNEL_BINPKG_ENV_RESET in the zfs-kmod env so linux-info.eclass keeps kernel env variables. This resolves an issue with installing zfs-kmod as a binpkg when the kernel was not yet installed. In a pure binpkg install the zfs-kmod package might be installed before the kernel, leading to the kmod's kernel version detection to fail.

The original issue may be reproduced by running a rebuild of a release tag (which will use binpkgs from our mirrors). Note that the reproduction is flaky because the issue is caused by a race condition between installing the kernel binpkg and zfs-kmod.

How to use

• Reproduce by rebuilding a recent release tag

   git clone https://github.com/flatcar/scripts.git
   cd scripts
   git checkout alpha-4054.0.0
   ./run_sdk_container -t
         ./build_packages
  

  As noted above it might be necessary to run the package build multiple times to reproduce the issue. Make sure to docker container prune between runs so the build starts from scratch.
• Apply patch from this branch, try to repro. The issue should not repro anymore.

Testing done

Ran the above builds.

Cherry-pick / backport

Should be cherry-picked to all maintenance branches that ship the zfs sysext (i.e. all except LTS): flatcar-3975 flatcar-4012 flatcar-4054

[github-actions]

Build action triggered: https://github.com/flatcar/scripts/actions/runs/10630574877

[jepio]

is the function below (cros_pre_pkg_setup_kernel_version) still useful with this change?

[t-lo]

is the function below (cros_pre_pkg_setup_kernel_version) still useful with this change?

That's a good question - I'm not really close to this part of our eclasses. We might want to simply try removing it in a follow-up PR and see what happens...

[t-lo]

Merged to main and cherry-picked to flatcar-3975, flatcar-4012, and flatcar-4054.