Details
-
Bug
-
Resolution: Fixed
-
Blocker
-
Lustre 2.4.0
-
3
-
5667
Description
On Nov 8, 2012, at 5:54 AM, Prem Sethna Kancherla wrote on lustre-discuss:
While installing lustre 2.3 on Centos 6.3, I am getting a continuous warning messages regarding "osd_zfs.ko" .
How can these warning messages to be removed while installing? They come while installing lustre-modules RPM. Messages are like:
WARNING: /lib/modules/2.6.32-279.5.1.el6_lustre.gb16fe80.x86_64/updates/kernel/fs/lustre/osd_zfs.ko needs unknown symbol zap_cursor_serialize
WARNING: /lib/modules/2.6.32-279.5.1.el6_lustre.gb16fe80.x86_64/updates/kernel/fs/lustre/osd_zfs.ko needs unknown symbol zap_remove
:
:
I think three options exist:
- suppress the warnings from osd_zfs.ko during installation, but this will only work for the lustre-modules RPM, and not for any other module depmod runs from other RPMs or by the user
- delete the osd_zfs.ko module at install time (preferably before depmod is run to produce these error messages). This will prevent the user from using ZFS if it is later installed (probably not a huge chance of problems for users)
- split the osd_zfs.ko module into a separate RPM. This might also avoid licensing issues that users are concerned about due to CDDL.
Attachments
Issue Links
Activity
Oops, just found that I forgot to comment on patch #6 which seems to work according to my previous comments and expectations.
BTW, patch #7 is out to comply to Prakash last comments.
Humm, patch #5 causes Lustre-Client builds failures because the osd-ldiskfs.ko module has not been built but there is an attempt to construct the lustre-osd-ldiskfs sub-package anyway, so I think I need to definitely avoid building OSDs sub-packages during a Client build ...
And lustre-osd-zfs sub-package is not attempted within the even successful Lustre-Server builds including ZFS/SPL packages, so I think I need to revert and construct the lustre-osd-zfs sub-package by default during Lustre-Server builds ...
Seems that actually the only way to detect+fix this (for both Manual/Make and lbuild kinds of builds) is the ugly/is_client way, sorry ... When patches from LU-1199 will land I will align accordingly.
Let see what happen with patch #6.
Submitted patch #5 with more of the "flavor" requested by Chris, if I fully understood !!...
BTW, if it does the trick I may only need to compact my post/preun/postun steps for the modules/osd-ldiskfs/osd-zfs sub-packages as SPEC-file macros if possible and not too tricky, to access to Prakash wishes.
So what should we decide here, to hold-on until
LU-1199patches are out or finish here and use it as an intermediate solution untilLU-1199is done and then to comply ??
I would prefer to put a hold on this bug until LU-1199 is further along. I'm happy to do this work in LU-1199 actually. It will be much easier to accomplish with the new framework.
The obvious short term fix for Intel's users is to just disable zfs support in the "official" binary builds that Intel puts on its distribution page. Folks that are advanced enough to try Lustre over ZFS this early in the process (before full support appears in a major release) are likely advanced enough to check out the source and build lustre themselves.
Its sure that the inheritance is something I have to deal with, but I don't agree with you that using autoconf conditionals breaks rebuilds from src.rpm, it simply and still (I mean as before, since what is failing is auto-remove of the dist tar-ball during "make rpms"!!) can only re-do/build the same build+options ("rpmbuild -bb/bs/ba" works) it comes from, but do we have to expect more from a src.rpm and is this why you feel it is broken ??
Yes, exactly. That is why I feel it is broken. I absolutely expect more from a src.rpm.
We should be able to have a single set of src.rpm files. If you need to build several versions of the same src.rpm file to cover all of the possible options, you are doing it wrong.
Granted, Lustre has been doing it wrong for ten years, but I'm desperately trying to address that in LU-1199. Your patch touches many lines with those autoconf conditionals. I am going to have to remove them all in the very near future to do it "right", and very likely introduce more complicated patch conflicts for me.
Take a look at the direction I am going in patch 3421. Look at how we handled the conditional build of lustre_tests and zfs in the lustre.spec.in. That is where I believe we should be going with the build system. Note that "is_client" is gone. We would just need to add an "ldiskfs" conditional that works like the zfs one and you would be set with what you need to do the osd-zfs and osd-ldiskfs packages.
That patch is not yet ready for everyone to use, but it is already working in LLNL's build farm. That (or very similar) is how we currently rewrite the broken upstream rpm that won't build for us at all.
> I am not going to approve anything that uses autoconf conditionals in the spec file. This digs us a > bigger technical debt hole in the build system.
> Source rpms should be rebuildable. There is no way you can rebuild the source rpm and change the
> selection of ldiskfs or zfs if you do it this way.
I don't think the autoconf variables will prevent the SRPM from being re-buildable in anyway. What it will do, at least in the current form of revision 4, is prevent the user from enabling/disabling different OSDs at rebuild time (i.e. you must specify at configure time and then are locked into that configuration). As Bruno brought up, this can also be done using RPM SPEC macros combined with rpmbuild --define WITH_VAR. If we use the SPEC variables, I think that'll address Chris's concerns, but there will still be conflicting work between this and LU-1199.
Guys, just reviewing all what has beeing done/said, let me have a new try/patch #5 soon ...
Chris,
For better visibility, I decided to answer here to your last comments in patch #4 about the use of autoconf conditionals breaking re-builds from src.rpm and LU-1199 patches linkage/conflicts :
> I am not going to approve anything that uses autoconf conditionals in the spec file. This digs us a > bigger technical debt hole in the build system.
> Source rpms should be rebuildable. There is no way you can rebuild the source rpm and change the
> selection of ldiskfs or zfs if you do it this way.
> Honestly, you are probably better waiting a month or two on this work until more LU-1199 work is
> complete. Right now you are having to content with 10 years of cruft in the build system.
Its sure that the inheritance is something I have to deal with, but I don't agree with you that using autoconf conditionals breaks rebuilds from src.rpm, it simply and still (I mean as before, since what is failing is auto-remove of the dist tar-ball during "make rpms"!!) can only re-do/build the same build+options ("rpmbuild -bb/bs/ba" works) it comes from, but do we have to expect more from a src.rpm and is this why you feel it is broken ??
On the other hand, my understanding on the real issue there is that using autoconf conditionals is in direct conflict with LU-1199 changes.
Thus, in addition with inheritance, as you suggest, seems I have also to deal and anticipate with LU-1199 modifications ...
So what should we decide here, to hold-on until LU-1199 patches are out or finish here and use it as an intermediate solution until LU-1199 is done and then to comply ??
Thank's already and in advance for your help and comments.
Humm patch #4 failed due to again :
error: Installed (but unpackaged) file(s) found:
/lib/modules/2.6.32-279.5.1.el6_lustre.g8e452a9.x86_64/updates/kernel/fs/lustre/osd_ldiskfs.ko
/lib/modules/2.6.32-279.5.1.el6_lustre.g8e452a9.x86_64/updates/kernel/fs/lustre/osd_zfs.ko
this occurs because with Maloo/Jenkins builds, and according to full/raw Console scan,[LDISKFS,ZFS]_ENABLED_TRUE are not set but with modules built !!... Thus seems that SPEC-file must again handle Manual+Jenkins/Maloo (lbuild?) builds differences...
So, will try to also fill modules_excludes on a per [LDISKFS,ZFS]_ENABLED_TRUE basis or remove the unwanted modules and see if it fixes.
But the good new is that installing 2 RPMs providing the same pseudo-package works at least locally on my build testing platform ...
Ok, great, I retract my argument for using Suggests/Recommends/whatever in that case. Using the same Provides in both the osd-ldiskfs and osd-zfs packages will be fine. Later we can worry about trying to split the core lustre package into lustre-client and lustre-server packages, but we don't need to do that in this ticket, and this won't conflict with that effort.
Due to rebase required (no more "build/autoMakefile.am.toplevel" file, now directly inlined within "autoMakefile.am"), causing Maloo/Hudson builds failures, patch #9 submitted including latest changes.