Uploaded image for project: 'Lustre'
  1. Lustre
  2. LU-2391

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

Details

    • Bug
    • Resolution: Fixed
    • Blocker
    • Lustre 2.4.0
    • 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

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

            Landed for 2.4

            pjones Peter Jones added a comment - Landed for 2.4

            I agree with Bruno, the circular dependency between lustre-modules and lustre-osd is not a defect. It just means they need to be installed simultaneously to satisfy the dependencies, i.e. rpm -i lustre-modules osd-zfs

            prakash Prakash Surya (Inactive) added a comment - I agree with Bruno, the circular dependency between lustre-modules and lustre-osd is not a defect. It just means they need to be installed simultaneously to satisfy the dependencies, i.e. rpm -i lustre-modules osd-zfs
            pjones Peter Jones added a comment -

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

            pjones Peter Jones added a comment - So, can this ticket be marked as resolved if any remaining work is being tracked under other tickets?

            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!

            bfaccini Bruno Faccini (Inactive) added a comment - 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!
            ys Yang Sheng added a comment -

            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.

            ys Yang Sheng added a comment - 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.
            bfaccini Bruno Faccini (Inactive) added a comment - - edited

            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.

            bfaccini Bruno Faccini (Inactive) added a comment - - edited 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.
            bfaccini Bruno Faccini (Inactive) added a comment - - edited

            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 !!

            bfaccini Bruno Faccini (Inactive) added a comment - - edited 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 !!

            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?

            adilger Andreas Dilger added a comment - 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?
            bfaccini Bruno Faccini (Inactive) added a comment - - edited

            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.

            bfaccini Bruno Faccini (Inactive) added a comment - - edited 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.

            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.

            bfaccini Bruno Faccini (Inactive) added a comment - 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.

            People

              bfaccini Bruno Faccini (Inactive)
              adilger Andreas Dilger
              Votes:
              0 Vote for this issue
              Watchers:
              10 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: