[LU-2391] warning messages for missing symbols when lustre-modules::osd_zfs.ko installed on a system without zfs-modules installed

• Type: Bug
• Resolution: Fixed
• Priority: Blocker
• Fix Version/s: Lustre 2.4.0
• Affects Version/s: Lustre 2.4.0
• Labels: LB
• Severity: 3
• Assignee: Bruno Faccini (Inactive)
• Reporter: Andreas Dilger

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.

Issue Links

• is duplicated by: LU-2993 Missing symbol warnings when installing OSD packages
• is duplicated by: LU-2507 Configure and test ZFS using dkms
• is related to: LU-1032 Add dkms support for kernel modules

Comments

[Peter Jones]

So, can this ticket be marked as resolved if any remaining work is being tracked under other tickets?

[Bruno Faccini (Inactive)]

Hello Yang,
This just means that you need to install lustre-modules with one of both the OSD RPMs, I can remove the lustre-osd dependency for lustre-modules and this will work but as no sense in a functional point of view!

[Yang Sheng]

hi, Bruno, Looks like the commit http://review.whamcloud.com/4869 has some defeat:

the osd-zfs & osd-ldiskfs both require lustre-modules. but lustre-modules also require lustre-osd. Please fix it.

[Bruno Faccini (Inactive)]

I am puzzled with the results for the last patch/build auto-tests. Seems that initialization test is (now/recently ?) run separately from others. And as you expected it failed when others have been successful in a separate session! This caused me to 1st think that some of TT-1009 related changes may have been already applied, and to miss the initialization failures.

How can this happen ? With help of a magic "rpm i lustre*" or something else ?

What I can only confirm again is that during manual install of the build :

_ lustre-modules RPM complains about missing "lustre-osd" dependency
_ lustre-modules + lustre-osd-[ldiskfs,zfs] respectively complains about missing "lustre-ldiskfs" or "zfs-modules" dependency.
_ lustre-modules + lustre-osd-[ldiskfs,zfs] + lustre-ldiskfs/zfs-modules is ok.
_ Tests run ok after lustre-modules + lustre-osd-ldiskfs + lustre-ldiskfs install, I did not test for zfs already.

[Bruno Faccini (Inactive)]

Andreas, this is TT-1009 task !! Thus, I can only add/confirm that, after I manually xfered the Malloo build full RPM set, I verified "locally+manually" that the lustre-modules RPM installed without any msgs regarding external+unsatisfied reference, then each of the OSD RPMs installation with either LDISKFS or ZFS separate/required RPM was successful and again without any message, finally I was able to bring up Lustre and run the test-suite.

But I will double-check and verify each RPM content ... And the full test logs !!

[Andreas Dilger]

Maybe I'm missing something, but how did http://review.whamcloud.com/4869 pass testing if extra work is still needed for handling lustre-osd-ldiskfs and lustre-osd-zfs RPM dependencies? I took the fact that the patch testing had passed as a sign that everything is well?

[Bruno Faccini (Inactive)]

These new OSD RPMs require specifc attention from our testing tools. Separate installation, external symbols resolution, ... Andreas already created TT-1009 to address the need.

[Bruno Faccini (Inactive)]

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.

[Bruno Faccini (Inactive)]

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.

[Bruno Faccini (Inactive)]

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.

[Bruno Faccini (Inactive)]

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.