Debian package creation failing since commit 46ba1e59d3ae7e374c7a98f15f4bef21ee3fcded

[mmehnert]

make[5]: Entering directory `/tmp/zfs-build-root-lSraFvTB/BUILD/zfs-0.6.2/cmd/zpool'
  CC       zpool_iter.o
  CC       zpool_main.o
  CC       zpool_util.o
  CC       zpool_vdev.o
  CCLD     zpool
../../lib/libzfs/.libs/libzfs.so: undefined reference to `lzc_rollback'
collect2: error: ld returned 1 exit status
make[5]: *** [zpool] Error 1

46ba1e59d3ae7e374c7a98f15f4bef21ee3fcded is the first bad commit commit 46ba1e59d3ae7e374c7a98f15f4bef21ee3fcded Author: Matthew Ahrens mahrens@delphix.com Date: Wed Aug 14 11:42:31 2013 -0800

Illumos #3996

3996 want a libzfs_core API to rollback to latest snapshot

[behlendorf]

@mmehnert Try building clean, it looks like the new library just wasn't built.

make distclean
sh autogen.sh
./configure
make -s

[mmehnert]

I tried distclean before. "make" actually works. The error only occurs with "make deb".

[akorn]

I think I have a workaround/fix for this.

Get the zfs-linux source using apt-get source zfs-linux; copy the debian subdir from it to the git working copy; apply the Debian patches (one of the two doesn't apply cleanly and needs to be applied manually); then patch the debian/ directory as follows:

diff -ru zfs-linux-0.6.2/debian/libzfs1-udeb.install zfs/debian/libzfs1-udeb.install
--- zfs-linux-0.6.2/debian/libzfs1-udeb.install 2013-10-15 13:55:19.000000000 +0200
+++ zfs/debian/libzfs1-udeb.install     2013-11-08 22:27:15.480968745 +0100
@@ -1 +1,2 @@
 lib/libzfs/.libs/libzfs.so.*[0-9]      lib
+lib/libzfs_core/.libs/libzfs_core.so.*[0-9]    lib
diff -ru zfs-linux-0.6.2/debian/libzfs1.install zfs/debian/libzfs1.install
--- zfs-linux-0.6.2/debian/libzfs1.install      2013-10-15 13:55:19.000000000 +0200
+++ zfs/debian/libzfs1.install  2013-11-08 22:27:14.848987577 +0100
@@ -1 +1,2 @@
 lib/libzfs.so.*
+lib/libzfs_core.so.*
diff -ru zfs-linux-0.6.2/debian/rules zfs/debian/rules
--- zfs-linux-0.6.2/debian/rules        2013-10-15 13:55:20.000000000 +0200
+++ zfs/debian/rules    2013-11-08 22:27:58.443686588 +0100
@@ -144,6 +144,7 @@
 ifeq ($(BUILD_UDEB), true)
    dh_makeshlibs -plibnvpair$(SHLIB_MAJOR) --add-udeb=libnvpair$(SHLIB_MAJOR)-udeb
    dh_makeshlibs -plibuutil$(SHLIB_MAJOR) --add-udeb=libuutil$(SHLIB_MAJOR)-udeb
+   dh_makeshlibs -plibzfs_core$(SHLIB_MAJOR) --add-udeb=libzfs_core$(SHLIB_MAJOR)-udeb
    dh_makeshlibs -plibzfs$(SHLIB_MAJOR) --add-udeb=libzfs$(SHLIB_MAJOR)-udeb
    dh_makeshlibs -plibzpool$(SHLIB_MAJOR) --add-udeb=libzpool$(SHLIB_MAJOR)-udeb
    dh_makeshlibs -pzfsutils --add-udeb=zfsutils-udeb
@@ -154,6 +155,7 @@
 ifeq ($(BUILD_UDEB), true)
    dh_strip -plibnvpair$(SHLIB_MAJOR)-udeb
    dh_strip -plibuutil$(SHLIB_MAJOR)-udeb
+   dh_strip -plibzfs_core$(SHLIB_MAJOR)-udeb
    dh_strip -plibzfs$(SHLIB_MAJOR)-udeb
    dh_strip -plibzpool$(SHLIB_MAJOR)-udeb
    dh_strip -pzfsutils-udeb

This will cause the new libzfs_core to be shipped as part of the libzfs1 package.

dpkg-buildpackage works; I don't yet know if the resulting packages work.

It's a workaround in that it doesn't fix "make deb", but it allows you to build .debs.

[spadegit]

Good evening from Cologne, Germany. Long time leecher and home user, so I got mainly building problems.

Linux spade-ng 3.12-0.slh.1-aptosid-amd64 #1 SMP PREEMPT Mon Nov 4 00:42:11 UTC 2013 x86_64 GNU/Linux

First @behlendorf and the whole zfsonlinux team: Your are true heroes. To be able to play with the mighty Z on my home desktop might not be important but it's great nonetheless.

Could one of You elaborate who's bug this actually is? Of course I would not like to make a fuss about some Kernel Module not compiling for the still quite hot 3.12, but I would love to dig around to get me up and running again.

I am not familiar with the Debian Patch approach but if in Your opinion the Debian Project will get around this bug I will happily run 3.11 until then. If it should be a current zfsonlinux bug I will continue my leeching/reading and wait for the new releases just as happily.

So please treat this just as curiosity instead of troubles.

Many thanks again and kind regards

Martin

make[5]: Entering directory `/tmp/zfs-build-sam-KtemBgsu/BUILD/zfs-0.6.2/cmd/zpool'
  CC       zpool_iter.o
  CC       zpool_main.o
  CC       zpool_util.o
  CC       zpool_vdev.o
  CCLD     zpool
../../lib/libzfs/.libs/libzfs.so: undefined reference to `lzc_rollback'
collect2: error: ld returned 1 exit status

[behlendorf]

Yes, a new library was added and it looks like it just needs to be added to the Debian packaging. If you don't need 3.12 support immediately I'd suggest waiting for 0.6.3 to be tagged which will include support.

[spadegit]

Will do.

Thanks for the info.

Regards,

Martin

[FransUrbo]

I'm not sure why I'm tagged as responsible for this, but either way - I can't reproduce this. I'm running kernel 3.12.0 and very latest of ZoL (spl and zfs). I have absolutly nothing regarding spl or zfs actually installed on my temporary build environment, only the git clones (I do have a '/usr/src/spl-0.6.2' link pointing to the spl directory, and then a link to my kernel build tree in there):

(CHROOT)# pwd
/usr/src
(CHROOT)# ll spl-0.6.2
lrwxrwxrwx 1 root src 10 Nov 10 09:22 spl-0.6.2 -> spl-crypto/
(CHROOT)# ll spl-0.6.2/3.12.0+*
lrwxrwxrwx 1 root src 1 Nov 10 06:33 spl-0.6.2/3.12.0+scst+tf.1 -> ./
lrwxrwxrwx 1 root src 1 Nov 10 06:33 spl-0.6.2/3.12.0+tf.1 -> ./
(CHROOT)# ./autogen.sh && ./configure .....
[...]
checking kernel source directory... /usr/src/linux-3.12.0+scst+tf.1
checking kernel build directory... /usr/src/linux-3.12.0+scst+tf.1
checking kernel source version... 3.12.0+scst+tf.1
checking kernel file name for module symbols... Module.symvers
checking spl source directory... /usr/src/spl-crypto
checking spl build directory... /usr/src/spl-crypto/3.12.0+scst+tf.1
checking spl source version... 0.6.2-1.20131110_crypto
(CHROOT)# make deb
[...]
checking kernel source directory... /lib/modules/3.12.0+scst+tf.1/source
checking kernel build directory... /lib/modules/3.12.0+scst+tf.1/build
checking kernel source version... 3.12.0+scst+tf.1
checking kernel file name for module symbols... Module.symvers
checking spl source directory... /usr/src/spl-0.6.2
checking spl build directory... /usr/src/spl-0.6.2/3.12.0+scst+tf.1
checking spl source version... 0.6.2-1.20131110_crypto

[Yes, I'm using zfsrogues crypt spl and zfs, but the link, for normal people, would then just be to 'spl' instead of 'spl-crypto']

I do have the linux image created with 'make-kpkg' in that directory installed in this chroot, hence it finds the source and build in the /lib/modules directory...

@mmehnert and @spadegit Have you tried this on either a clean clone of spl/zfs or done a './autogen.sh && ./configure ' before the make? I do this after every pull or cherry-pick (no matter how small the merge is/was), just to be absolutly sure things like this don't happen.

[spadegit]

Hi @FransUrbo

thank You for Your feedback. I surly want not to cause any headaches for Your and Your fellow developers. I possible hijacked this thread in a wrong fashion.

May I elaborate my procedure for compiling the modules as Debian packages.

I usually stay with the release (major or latest git version) that compiles for me e.g. the brand new kernels that I get from the Debian Sid Distribution aptosid.

I just

• extract the spl and zfs sources into empty directories
• run autogen.sh
• run ./configure --mandir=/usr/local/share/man
• make deb

First for spl with installing the created deb packages and then zfs.

I do not compile that many packages, so that it is me creating an error in the process or having a broken build system is absolutely possible (if not even certain). Also, the Sid distro I run does not run amok pushing new packages but (of course) there are often hickups or inconsistencies - the side effect of a bleeding edge rolling distro. My box pulled some interesting packages today (automake, binutils, libc6) so I will give it a new try today.

If Your inbox gets filled by me posting in this thread, I will stop immediately. Shame on me for not checking github processes and responsibilities. :(

I am thankful nonetheless for @behlendorf's answer. Makes me feel in charge again :).

Have a nice rest-weekend.

Regards, Martin

P.S. English is not my mother tongue, so please do accept my appreciation and don't take my clumsy words literally.

[spadegit]

To whom it may concern:

Building the zfs Debian packages failed with the same error again. (Sources downloaded as zip files today)

make[5]: Entering directory `/tmp/zfs-build-sam-5yox1v18/BUILD/zfs-0.6.2/cmd/zpool'
  CC       zpool_iter.o
  CC       zpool_main.o
  CC       zpool_util.o
  CC       zpool_vdev.o
  CCLD     zpool
../../lib/libzfs/.libs/libzfs.so: undefined reference to `lzc_rollback'
collect2: error: ld returned 1 exit status

configure for spl and zfs return no error (exit 0 in both config.log files).

As @mmehnert experienced I can also run make w/o parameters successfully.

I humbly suggest to ignore this for know, at least until a larger amount of users is actually affected.

Regards,

Martin

[FransUrbo]

extract the spl and zfs sources into empty directories @spadegit You say 'extracted'... So you're not using a 'git clone' directory? What exactly is it you're using and where did you get it from?

@mmehnert (who had the exact same problem as you, @spadegit) said in his initial post that the first bad commit was #46ba1e5. The 'problem' is that the ONLY change since then (regarding packaging), is a tightening of the requirements of zfs visa vi the module (commit #28967367)... And that is NOT a problem here.

[spadegit]

@FransUrbo

I downloaded yesterday from https://github.com/zfsonlinux/zfs/archive/master.zip and https://github.com/zfsonlinux/spl/archive/master.zip. I assumed that would be as pulling the last git release.

I don't follow the development in commits so I am not able to put my finger on a particular one.

[FransUrbo]

I just downloaded those two zips and built all the relevant debs without any problem and still can't reproduce this issue.

[spadegit]

What can I say...

@FransUrbo Can I run some commands and tests that might interest You? If not I stand by my suggestion in my last post.

Maybe mmehnerts fixes will let me build the packages on my system again.

Up into my next week of nine-til-five.

Regards,

Martin

[behlendorf]

@spadegit @mmehnert fix in #1878 should resolve your build issue, although it shouldn't be strictly needed. Are you passing any additional custom build options in your environment?

[mmehnert]

None that I'm aware of. :-(

./autogen.sh
./configure
make deb

[FransUrbo]

Does a normal 'make' between the configure and the 'make deb' make any differents? I doubt it should, but you never know...

As in:

./autogen.sh
./configure
make
make deb

[mmehnert]

No. As I said somewhere in between, the normal make runs fine. But make deb then fails with the error in the initial report.

[FransUrbo]

Yes, I saw that. But the question was that if the FOUR commands in a row makes any difference. In each output, you have indicated THREE commands....

I haven't looked at the package building in quite a while, but if I remember correctly, it copies the current source tree to a temp directory (via a tarball) and then tries to build it. So it MIGHT (doubtful, but test it anyway) make a difference to first do a make before doing the make deb...

[mmehnert]

Yes. I tried "make" and then "make deb" before. It did result in the same error.

[FransUrbo]

Ok, thanx. Just wanted to be absolutly sure... Still have no idea why you get this problem, and I don't...

[spadegit]

Hi all, hi @behlendorf ,

to answer Your question: I give configure a path for the man pages as a parameter but that's it. Since I ran into trouble I ran the following compile procedures w/o any parameters - I know my limits :).

Since FransUrbo can compile successfully I am even more curious but really nothing more. I read a little in mmehnerts fixes and in conclusion did not see any obvious problems with the main code, but what do I know...

Regards and many thanks for all Your efforts.

Martin

[spadegit]

Feedback to @behlendorf and @mmehnert :

I can build deb packages successfully again, now for kernel 3.12.

Thank You very much for Your time and efforts.

Regards,

Martin