Iām not sure how it could happen. The dnf wrapper is pretty straight forward. It just checks to see if you used the update subcommand or any of its aliases.
case "$arg" in
(update|upgrade|up) UPDATE=1 ;;
If so, it adds the --exclude=kernel* as a dnf parameter (and --disablerepo=zfs* to prevent ZFS from being updated).
I donāt know either. Using dnf up --refresh should be fine. And according to your history, the wrapper added --exclude=kernel* and --disablerepo=zfs* just like it was supposed to, so I donāt see how the kernel could have been updated when that command ran unless there is a problem with dnf itself.
Let me know if you figure it out. I just tested it on my system and it seems to be working correctly.
You might check your Bash history (using the history command) to be sure you ran what you thought you ran.
only thing i did was install git before updating your scripts from your main repo, git had not been installed on this older system, and the earlier versions of your zfs-update didnāt use it iirc..
also by memory when the upgrade was complete, there was no message output noting that zfs and kernel were skipped, like usual.
So i have no clue, for some reason it didnāt use your wrapper. Immediately before running dnf up --refresh, i did delete your scripts from /usr/local/bin/, and download new ones, and chmod +x them.
Only thing i can think of is somehow the new files in /usr/local/bin/ did not have time to āpercolateā through the system, and so the actual system dnf ran instead?
You may have fallen foul of a slightly obscure bit of bash functionality - it remembers where it last found a command to save time next time you call it (see 3.7.2 Command Search and Execution, point 3 in the bash manual)
If youāre adding programs / scripts that you want to override something further down your path, then you should run e.g. hash dnf to force an update (or justhash -r to forget the current cached list entirely)
If you had run dnf in that bash instance before downloading the scripts, that would explain /usr/bin/dnf being run instead of /usr/local/bin/dnf - and Iām assuming thatās how you installed git.
in this case, dnf install git should have still used the wrapper script. only after was it deleted and replaced (pretty quick though as the whole delete, wget and chmod command is copypasted at once)..
Itās not a bug in the script. There really isnāt anything I can do about it. It is just the way Bash/Shell has always worked. It isnāt a problem when the scripts are provided from the main Fedora-on-ZFS install script. It is just something that you have to be aware of if you try to āoverrideā a system executable with a wrapper script. You must know to run hash <command> as Thomas pointed out. (Or start a new shell.)
just to note, iām getting the error again doing kernel-update:
# kernel-update
Kernel update kernel-6.17.4-200.fc42.x86_64 is available.
Your current version of OpenZFS is zfs-2.3.4-1.fc42.x86_64.
Before proceeding, check https://github.com/openzfs/zfs/releases to veri-
fy that your version of OpenZFS is compatible with this kernel update.
Update to kernel-6.17.4-200.fc42.x86_64 [y/n]?: y
Updating and loading repositories:
Repositories loaded.
Problem 1: installed package zfs-dkms-2.3.4-1.fc42.noarch conflicts with kernel-devel > 6.16.999 provided by kernel-devel-6.17.4-200.fc42.x86_64 from updates
- cannot install the best update candidate for package kernel-devel-6.15.7-200.fc42.x86_64
- problem with installed package
Problem 2: installed package zfs-dkms-2.3.4-1.fc42.noarch conflicts with kernel-uname-r > 6.16.999 provided by kernel-core-6.17.4-200.fc42.x86_64 from updates
- installed package zfs-2.3.4-1.fc42.x86_64 requires zfs-kmod = 2.3.4, but none of the providers can be installed
- cannot install the best update candidate for package kernel-core-6.15.7-200.fc42.x86_64
- problem with installed package
Problem 3: installed package zfs-2.3.4-1.fc42.x86_64 requires zfs-kmod = 2.3.4, but none of the providers can be installed
- installed package zfs-dkms-2.3.4-1.fc42.noarch conflicts with kernel-uname-r > 6.16.999 provided by kernel-core-6.17.4-200.fc42.x86_64 from updates
- installed package zfs-dracut-2.3.4-1.fc42.noarch requires zfs >= 2.3.4, but none of the providers can be installed
- cannot install the best update candidate for package kernel-core-6.16.7-200.fc42.x86_64
- problem with installed package
Package Arch Version Repository Size
Skipping packages with conflicts:
kernel-core x86_64 6.17.4-200.fc42 updates 98.8 MiB
kernel-devel x86_64 6.17.4-200.fc42 updates 81.1 MiB
Nothing to do.
ERROR: The zfs module does not appear to be in the updated initramfs.
Without the zfs module, the new kernel+initramfs will not be able to boot
your root-on-zfs system. You have a choice:
1. Run dnf history undo last to undo this kernel update.
2. Try running dkms autoinstall ... && kernel-install add ... This
might suffice to fix situations where kernel-core was updated without using
this script (try to avoid doing that).
3. Exit now. (You can attempt to fix the problem manually with dkms
uninstall/install and/or kernel-install remove/add.)
What is your choice [1/2/3]?:
I donāt know what to do, none of the 3 options help..
I just posted here to @glb , because i use his kernel-update wrapper script, and so thought if this is related.. But youāre right, i need to just wait, and actually it works as expected. On test VM, i tried removing the kernel-update wrapper script, and just do a normal update, and indeed it says:
Skipping packages with conflicts:
zfs-dkms noarch 2.2.8-1.fc42 zfs 56.7 MiB
zfs-dkms noarch 2.3.2-1.fc42 zfs 58.7 MiB
zfs-dkms noarch 2.3.3-1.fc42 zfs 58.7 MiB
kernel-core x86_64 6.17.4-200.fc42 updates 98.8 MiB
kernel-devel x86_64 6.17.4-200.fc42 updates 81.1 MiB
Skipping packages with broken dependencies:
zfs x86_64 2.2.8-1.fc42 zfs 1.8 MiB
zfs x86_64 2.3.2-1.fc42 zfs 1.9 MiB
zfs x86_64 2.3.3-1.fc42 zfs 1.9 MiB
zfs x86_64 2.3.4-1.fc42 zfs 1.9 MiB
zfs-dracut noarch 2.2.8-1.fc42 zfs 25.4 KiB
zfs-dracut noarch 2.3.2-1.fc42 zfs 25.4 KiB
zfs-dracut noarch 2.3.3-1.fc42 zfs 25.4 KiB
zfs-dracut noarch 2.3.4-1.fc42 zfs 25.4 KiB
Transaction Summary:
Installing: 3 packages
Upgrading: 491 packages
Replacing: 491 packages
Skipping: 13 packages
Total size of inbound packages is 1 GiB. Need to download 1 GiB.
After this operation, 6 MiB extra will be used (install 3 GiB, remove 3 GiB).
Is this ok [y/N]:
Yes, there was a problem with the kernel-update script and I have corrected it. A change was made a while ago that prevents the kernel from updating if it is not compatible with the currently-installed version of ZFS. But my wrapper script was looking for the new kernel anyway after the dnf command had run because the dnf command had returned success (arguably this is a flaw in dnf). I have fixed my wrapper script to run an addition verification that the kernel was actually updated before checking to see if the corresponding initramfs image is valid.
But as they had not changed for awhile, i stopped bothering, and this time i should have.. Itās a pretty annoying step to have to do every time.. But if the script would notify it has been updated, it would be nice
Yes, that makes sense. The script could generate a simple hash of itself and fetch the version from the GitHub repo and see if they differ. Iāve got some other things Iām working on at the moment, but Iāll put this on my todo list. Thanks for the suggestion.
This behavior is intentional here. The intent behind the changes to how ZFS handles dnf dependencies (ZFS 2.3 onwards) was to have dnf continue to work normally but skip updating the core kernel packages (kernel-core/kernel-uki-virt and kernel-devel) if the kernel update would make the kernel incompatible with ZFS. This allows people to still use dnf update to update the rest of their packages while they wait for a new ZFS version that is compatible with the new kernel to be released.
Id argue that this is probably the best way to handle the āZFS doesnt support the new kernelā situation, but it does mean that you cant rely on the dnf exit status to detect if the new kernel is compatible with ZFS.
side note: the first few 2.3 releases this didnāt work correctly, but in either ZFS 2.3.2 or 2.3.3 it was fixed and now works properly.
I see. Thanks for the explanation. I wrote these āwrapper scriptsā before ZFS 2.3. They might not really be necessary anymore. I still use them just because I prefer to update and recompile ZFS as a separate step that is run strictly after the rest of the system (compilers et al) is fully updated and after I have run rpmconf -a to make sure config changes are also up-to-date. But at this point, I think that is just me and my old habits. I think dnf and ZFSās default handling is probably adequate now. It is much better than it used to be. Thanks!
