0.6.5.3 DKMS fails ({spl,zfs}-dkms version mismatch) #184
Comments
|
I noticed the same thing happening. The logic for choosing a "compatible" version of The relevant part is this: --with-spl=${source_tree}/spl-$(subver=`echo ${PACKAGE_VERSION} | sed "s@\([0-9]\.[0-9]\.[0-9]\)\(\.[0-9]\)@\1@"`
if [ -e ${source_tree}/spl-${PACKAGE_VERSION} ]; then
echo ${PACKAGE_VERSION}
elif [ -e ${source_tree}/spl-${subver} ]; then
echo ${subver}
fi)
--with-spl-obj=${dkms_tree}/spl/$(subver=`echo ${PACKAGE_VERSION} | sed "s@\([0-9]\.[0-9]\.[0-9]\)\(\.[0-9]\)@\1@"`
if [ -e ${source_tree}/spl-${PACKAGE_VERSION} ]; then
echo ${PACKAGE_VERSION}
elif [ -e ${source_tree}/spl-${subver} ]; then
echo ${subver}
fi)/${kernelver}/${arch}Naturally, this code on my system yields the following value: On which the build process chokes. As can be seen, it tries to find either the same It seems to me line spl and zol are using semantic versioning, which means that the latest in the same minor version bracket 0.6.5.* should work for any zfs 0.6.5.*. So the situation for Debian Stretch and possibly ubuntu could be improved with something like this: spl_new=${source_tree}/spl-$(
subver=$(echo ${PACKAGE_VERSION} | sed "s@\([0-9]\.[0-9]\.[0-9]\)\(\.[0-9]\)@\1@")
subver_max=$(cd ${source_tree}; for max in spl-${subver}.?; do :; done; echo "${max#spl-}")
if [ -e ${source_tree}/spl-${PACKAGE_VERSION} ]; then
echo ${PACKAGE_VERSION}
elif [ -e ${source_tree}/spl-${subver} ]; then
echo ${subver}
elif [ -e ${source_tree}/spl-${subver_max} ]; then
echo ${subver_max}
fi)
spl_obj_new=${dkms_tree}/spl/$(
subver=`echo ${PACKAGE_VERSION} | sed "s@\([0-9]\.[0-9]\.[0-9]\)\(\.[0-9]\)@\1@"`
subver_max=$(cd ${source_tree}; for max in spl-${subver}.?; do :; done; echo "${max#spl-}")
if [ -e ${source_tree}/spl-${PACKAGE_VERSION} ]; then
echo ${PACKAGE_VERSION}
elif [ -e ${source_tree}/spl-${subver} ]; then
echo ${subver}
elif [ -e ${source_tree}/spl-${subver_max} ]; then
echo ${subver_max}
fi)/${kernelver}/${arch}Which yields Which is better, IMHO. The salient part is the @FransUrbo what do you think? |
|
Sadly though, looking for this decision code so I could alter it (or send a PR), I can't find it in this repository. The closes I get is https://github.com/zfsonlinux/pkg-zfs/blob/snapshot/debian/jessie/debian/zfs-dkms.dkms. Strangely, although it looks a whole lot like the dkms.conf I found on my system, it's missing the spl version selection parts: --with-spl=${source_tree}/spl-${PACKAGE_VERSION}
--with-spl-obj=${dkms_tree}/spl/${PACKAGE_VERSION}/${kernelver}/${arch}Is this some dkms magic? I'm confused. |
|
I just said that I couldn't find the $ git grep 'subver=.echo ${PACKAGE_VERSION}' $(git rev-list --all)So it would seem that the current zfs-dkms package was not built from the snapshot/debian/jessie branch as I originally thought, but from something else. However these raw hashes don't give me a good idea of what I should make the PR too, if any. Also, this seems related to #181. |
|
Possibly last update to my last comment, trying to find where this $ git log -S 'subver=' --source --allSo, a fix for openzfs/zfs#3807 introduced it. |
|
@aktau excellent investigation. Re: your proposed improved code, I've got one question: subver_max=$(cd ${source_tree}; for max in spl-${subver}.?; do :; done; echo "${max#spl-}")Is the glob Re: PR; I think the branch |
|
does anyone know a quick fix, please? |
|
@mailinglists35 Your problem is not relevant to this issue, but to #181. If you want to install 0.6.5.3 on debian, you'll simply have to wait. |
|
@roeme I thought this issue was about mismatching spl/zfs versions on zol repo (see the apt-cache policy output) on both debian jessie and debian wheezy! Did I understand wrong? |
|
@roeme and what I was pointing out is that zol repo for ubuntu has spl and zfs versions in sync (which happens to be 0.6.5.3) |
|
@mailinglists35 Yes, you did understand wrong, or rather, didn't read thoroughly. As outlined in the initial report, Debian stable (a.k.a jessie) is not broken, as zfs 0.6.5.2 is compatible with spl 0.6.5. |
|
I just spent an hour trying to fix a {headless,remote} server that fell victim to this, however. In light of the fact that spl+zfs installs are not atomic, but single package installs are... perhaps it would make sense to package both the modules in a single package? |
|
@Baughn I don't know if there is a rule/practice but from what I've observed so far in the linux ecosystem, kernel modules are distributed in their own packages. I don't know the reason/logic for this, but as an end-user I feel the same that there should be a single package to install. |
|
This is one of those won't fix, because it will be absolutely impossible to keep track on what version of zfs is compatible with which version of spl (and possibly vise-versa). They usually go hand-in-hand, and I always upload both of them simultaneous. However, this is getting even more complicated now that Debian GNU/Linux provides spl, but not zfs. There is very little I can do to rectify this. And I've been saying all along that one needs to pay close attention on what's happening with spl/zfs. |
|
Yea, it's annoying. But:
If I understood the current build script correctly, it chooses either an exact match, as you said, or it cuts of the last version number. So 0.6.5.3 will compile with 0.6.5 if present. Why is why I thought my hack would be OK. It would allow 0.6.5.3 to compile with 0.6.5.2, for example. Perhaps I'm misunderstanding the versioning semantics of ZFS. |
|
We can't guarantee that that will always work. It might now, but in a future release, it might not. Hence the problem... |
|
@behlendorf I haven't been keeping up-to-date with the releases the last couple of months, but CAN we say that |
@FransUrbo Dunno if it's already done this way, IMO we might then apt-pin both spl and zfs to ZoL's repository, instead of upstream...? Since the system where I encountered this is running a mix between testing and stable, and I'm away from it currently, I'm not too sure wether the breakage described in OP is and will be just my own (in which case I'm totally fine with WONTFIX), or if users of the next stable, stretch, could/will be affected as well. In the latter case, a more stable (or more gracefully failing) approach might be needed. |
It's kinda the definition (or used to be) of "Debian GNU/Linux Testing"! Also, to few people is doing this, so it doesn't make sense to provide workarounds for a few people, when most everyone else will suffer from it. A third thought regarding this is that we're very likely to see a upstream package "shortly"! And this will be moot. |
As I wrote; and tried to tell people multiple times in this issue, I'm not advocating to support this, at all, nor am I seeking support for it (the next guy saying anything in this direction will be hit by an electronic trout¹). I opened this issue solely because I suspected that the underlying fault might surface at some point in stable, (see also the not-so-nice degradation modes found by @aktau ). But yeah, it's all moot if upstream provides both packages. I had (still have) major doubts about the licensing issues; but I'm sure you have more insight into this, so I'm in full agreement to close this issue. Thanks for the all the hard work so far! ¹) If you get this reference, you're old. |
|
|
Wouldn't it be easier to provide both the spl and zfs modules as a single package? I get that it's been normal to split them up, but what does anyone really gain by doing so? |
|
That is (or was) on the TODO for the long run. It's just not something anyone is really interested in doing, the current system "works". |
sorry for offtopic, but I can't find any reference on debian website about testing being as dangerous as you say; that description seems to me to better describe the unstable, not testing. "testing "Packages are installed into the `testing' directory after they have undergone some degree of testing in unstable. They must be in sync on all architectures where they have been built and mustn't have dependencies that make them uninstallable; they also have to have fewer release-critical bugs than the versions currently in testing. This way, we hope that `testing' is always close to being a release candidate." anyway thanks for the long time providing packages and let's hope zfs will finally be accepted by ftp masters. |
Hi,
after upgrading my system's kernel from 4.2.3 to 4.2.5, to ZFS module was no longer loaded (mismatching symbols). Trying to rebuild the modules yielded strange errors:
(Note the missing version number for the spl source directory).
The
spl-dkmsmodule was sucessfully installed, however.Further investigation reveals a version mismatch of the interesting sort:
So
spl-dkmshas hit the official servers with 0.6.5.3 (at least in debian'stesting), but remains at 0.6.5-1 on zfsonlinux’ own repo.Downgrading
spl-dkmsto 0.6.5-1 fixes the issue, and allows one to build/load version 0.6.5.2 ofzfs-dkms.The text was updated successfully, but these errors were encountered: