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

WARNING: kernel missing dev_set_rdonly patch for testing

    XMLWordPrintable

Details

    • Bug
    • Resolution: Duplicate
    • Minor
    • None
    • None
    • None
    • 3
    • 15701

    Description

      This is a build failure found preparing SGI Lustre 2.4.1 :

      checking for /usr/src/kernel-source/2.6.32-358.18.1.el6sgi241a15.rhel6.x86_64.lustre/include/linux/migrate.h... yes
      checking if address_space_operations.migratepage has 4 args... no
      checking if super_operations use dentry as parameter... no
      checking if inode_operations use umode_t as parameter... no
      checking if touch_atime use one argument... no
      checking if have d_make_root... no
      checking if kmap_atomic has only 1 argument... no
      checking if have clear_inode... yes
      checking if encode_fh have parent inode as parameter... no
      checking if kernel has generic_file_llseek_size with 5 args... no
      checking if i_dentry/d_alias uses hlist... no
      checking if dentry_open uses struct path as first argument... no
      checking if iop has atomic_open... no
      checking if Linux was built with symbol dev_set_rdonly exported... no
      configure: WARNING: kernel missing dev_set_rdonly patch for testing

      This is the test:
      grep -q -E '[[:space:]]dev_set_rdonly[[:space:]]' $LINUX/$SYMVERFILE 2>/dev/null

      And we do have the symbol:

      schamp@ltest-admin:/home/lwork/schamp/stout7-sgilustre-2.4.1/bldroot.rhel64/boot $ gunzip -c symvers-2.6.32-358.18.1.el6sgi241a15.rhel6.x86_64.lustre.gz | grep '[[:space:]]dev_set_rdonly[[:space:]]'
      0x6e7378b8 dev_set_rdonly vmlinux EXPORT_SYMBOL

      I bet it screws up the symvers:
      checking name of module symbol version file... Module.symvers

      --with-linux=/usr/src/kernel-source/2.6.32-358.18.1.el6sgi241a15.rhel6.x86_64.lustre/
      so it looks at
      /usr/src/kernel-source/2.6.32-358.18.1.el6sgi241a15.rhel6.x86_64.lustre/Module.symvers

      Which doesn't exist, because the symver is in the object directory, not
      the source directory - a problem which doesn't show up in the Intel build
      process because it uses the same directory for both, even though vendors package them separately.

      This is likely a problem not only for SGI's internal build process, but for anyone who builds server packages against installed kernel packages instead of the intermediate kernel build objects.

      Patch coming right up.

      Attachments

        Issue Links

          Activity

            People

              wc-triage WC Triage
              schamp Stephen Champion
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: