Fedora 21 Repository

[maci0]

Hi, I think it is time to create a Fedora 21 repository so people who are testing the alpha/beta releases can use ZoL as well. Other 3rd party repos like rpmfusion already have F21 repositories.

[behlendorf]

Yes, probably true.

[maci0]

Actually I think we should create the new repos as soon as fedora branches for the next releases. That way we can get more testers earlier.

[behlendorf]

It looks like the beta is scheduled to be released Tuesday Oct 28. Once the beta's out I will setup the new repository and added a Fedora 21 builder to the buildbot.

@maci0 you might also find the following useful. At ftp://ftp.zfsonlinux.org/repo/ I do maintain a copy of the EPEL and Fedora repositories which can be browsed. The zfs.repo yum configuration references S3 since it's more scalable but this additional mirror does exist.

[hubick]

Hi. Are Fedora 21 RPM's available anywhere yet? I assume they will be a 0.6.4 snapshot for kernel 3.17 compatibility? Much Thanks!

[behlendorf]

@hubick The repository hasn't been set up yet but you can manually build packages using the latest master source for FC21.

[pantsman0]

@behlendorf Is this the official word until 0.6.4-stable is out? kernel 3.17 support would be required for the packages to build

[qualar2]

I moved away from Gentoo last weekend because I was bored of having to trouble shoot all the compiler problems, I though Fedora 21 would be a nice polished change. And now I find I have to compile my own ZFS! I managed to get spl built but zfs was complaining that a libuuid-devel (guessing it's name as I'm at work) can't be installed on my x86_64 as it was pulling in a i686 version.

Any chance someone could spend 5 mins publishing their FC21 version of zfs.rpm before my head is flattened by this brick wall?

Thanks in advance.

Paul

[dswartz]

"I thought Fedora 21 would be a nice polished change"

Just curious. Do you do standup comedy?

[qualar2]

Get this far:-

./configure

.... checking for uuid/uuid.h... no configure: error: in `/usr/src/zfs/zfs': configure: error: *\ uuid/uuid.h missing, libuuid-devel package required

yum install libuuid-devel

Loaded plugins: langpacks Resolving Dependencies --> Running transaction check ---> Package libuuid-devel.x86_64 0:2.25.2-1.fc21 will be installed --> Processing Dependency: libuuid = 2.25.2-1.fc21 for package: libuuid-devel-2.25.2-1.fc21.x86_64 --> Running transaction check ---> Package libuuid.i686 0:2.25.2-1.fc21 will be installed --> Processing Dependency: libc.so.6(GLIBC_2.4) for package: libuuid-2.25.2-1.fc21.i686 --> Processing Dependency: ld-linux.so.2(GLIBC_2.3) for package: libuuid-2.25.2-1.fc21.i686 --> Processing Dependency: ld-linux.so.2 for package: libuuid-2.25.2-1.fc21.i686 --> Running transaction check ---> Package glibc.i686 0:2.20-5.fc21 will be installed --> Processing Dependency: libfreebl3.so(NSSRAWHASH_3.12.3) for package: glibc-2.20-5.fc21.i686 --> Processing Dependency: libfreebl3.so for package: glibc-2.20-5.fc21.i686 --> Running transaction check ---> Package nss-softokn-freebl.i686 0:3.17.2-1.fc21 will be installed --> Finished Dependency Resolution Error: Multilib version problems found. This often means that the root cause is something else and multilib version checking is just pointing out that there is a problem. Eg.:

     1. You have an upgrade for libuuid which is missing some
        dependency that another package requires. Yum is trying to
        solve this by installing an older version of libuuid of the
        different architecture. If you exclude the bad architecture
        yum will tell you what the root cause is (which package
        requires what). You can try redoing the upgrade with
        --exclude libuuid.otherarch ... this should give you an error
        message showing the root cause of the problem.

     2. You have multiple architectures of libuuid installed, but
        yum can only see an upgrade for one of those architectures.
        If you don't want/need both architectures anymore then you
        can remove the one with the missing update and everything
        will work.

     3. You have duplicate versions of libuuid installed already.
        You can use "yum check" to get yum show these errors.

   ...you can also use --setopt=protected_multilib=false to remove
   this checking, however this is almost never the correct thing to
   do as something else is very likely to go wrong (often causing
   much more problems).

yum install --exclude libuuid.i686 libuuid-devel

Loaded plugins: langpacks Resolving Dependencies --> Running transaction check ---> Package libuuid-devel.x86_64 0:2.25.2-1.fc21 will be installed --> Processing Dependency: libuuid = 2.25.2-1.fc21 for package: libuuid-devel-2.25.2-1.fc21.x86_64 --> Finished Dependency Resolution Error: Package: libuuid-devel-2.25.2-1.fc21.x86_64 (fedora) Requires: libuuid = 2.25.2-1.fc21 Installed: libuuid-2.25.2-2.fc21.x86_64 (@updates-testing) libuuid = 2.25.2-2.fc21 Available: libuuid-2.25.2-1.fc21.x86_64 (fedora) libuuid = 2.25.2-1.fc21 You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest Protected multilib versions: libuuid-2.25.2-1.fc21.i686 != libuuid-2.25.2-2.fc21.x86_64

As I said, I'm new to Fedora so perhaps I've done something stupid.

Paul

[pantsman0]

@qualar2 There is a for building your own generic RPMs for fedora here. I followed the GIT guide and the only issues I encountered were missing deps. This was resolved by:

# yum install automake autoconf rpm-build libtool

From the transcript above, it appears the issue is due to dependency issues when you enabled the fedora-testing repo. I would suggest disabling this repo and installing libuuid-2.25.2-1.fc21.x86_64(@anaconda) and libuuid-devel-2.25.2-1.fc21.x86_64(@fedora). That should resolve your dependency issue and make the 64bit uuid lib and headers available for compilation

[qualar2]

Thanks @pantsman0, I also worked out those missing deps.

From your pointers, I did a "yum distro-sync'" (and I needed to "yum erase firewalld-filesystem-0.3.13-1.fc21.noarch" to get that to work), and then with a simple "yum install ibuuid-devel" I was able to build the package.

Now I'm stuck at installing it, with:-

yum localinstall libuutil1-0.6.3-159_gc944be5.fc21.x86_64.rpm libnvpair1-0.6.3-159_gc944be5.fc21.x86_64.rpm libzpool2-0.6.3-159_gc944be5.fc21.x86_64.rpm zfs-0.6.3-159_gc944be5.fc21.x86_64.rpm libzfs2-0.6.3-159_gc944be5.fc21.x86_64.rpm zfs-dkms-0.6.3-159_gc944be5.fc21.noarch.rpm zfs-dracut-0.6.3-159_gc944be5.fc21.x86_64.rpm

it hangs on the DKMS package:-

ps -Hft pts/0

UID PID PPID C STIME TTY TIME CMD pas 2637 2634 0 Dec07 pts/0 00:00:00 -bash root 16067 2637 0 Dec08 pts/0 00:00:00 /bin/su - root 16075 16067 0 Dec08 pts/0 00:00:00 -bash root 9705 16075 1 09:58 pts/0 00:00:01 /usr/bin/python /bin/yum localinstall libuutil1-0.6.3-159_gc944be5.fc21.x86_64.rpm libnvpair1-0.6.3-159_gc944be5.fc21.x86_64.rpm libzpool2-0.6.3-159_gc944be5.fc21.x86_64.rpm zfs-0.6.3-159_gc944be5.fc root 9706 9705 0 09:58 pts/0 00:00:00 /bin/sh /var/tmp/rpm-tmp.XiqVZ4 1 root 9707 9706 0 09:58 pts/0 00:00:00 /bin/sh /usr/lib/dkms/common.postinst zfs 0.6.3 root 9913 9707 0 09:58 pts/0 00:00:00 /bin/bash /sbin/dkms build -m zfs -v 0.6.3 -k 3.17.4-302.fc21.x86_64 root 9951 9913 0 09:58 pts/0 00:00:00 /bin/bash /sbin/dkms build -m zfs -v 0.6.3 -k 3.17.4-302.fc21.x86_64 root 10038 9951 0 09:58 pts/0 00:00:00 /bin/sh /var/lib/dkms/zfs/0.6.3/build/configure --prefix=/usr --with-config=kernel --with-linux=/lib/modules/3.17.4-302.fc21.x86_64/build --with-linux-obj=/lib/modules/3.17.4-302.fc21.x86_6 root 11003 10038 0 10:00 pts/0 00:00:00 sleep 1

It's caught in a "sleep 1" loop. Is this a pointer?-

cat /var/lib/dkms/zfs/0.6.3/build/make.log

DKMS make.log for zfs-0.6.3 for kernel 3.17.4-302.fc21.x86_64 (x86_64) Sat 13 Dec 10:15:18 GMT 2014 make: *\ No targets specified and no makefile found. Stop.

Sigh, but I'll be happy when I get ZFS working

Paul

[qualar2]

Eventually the loop finishes, but I can't start ZFS, there is no zfs.ko on my system and when I build one by hand it fails to load because of missing symbols, probably from spl.ko which won't load because it's in the wrong format.

Please, please, please, can someone just post thier working RPMs to zfsonlinux.org?

Paul

[behlendorf]

Any chance someone could spend 5 mins publishing their FC21 version of zfs.rpm before my head is flattened by this brick wall?

If it were only 5 minutes of work I'd have done it already. That said, we do need a FC21 repository I'm overdue setting one up so I'll see what can be done. Perhaps tomorrow.

[qualar2]

That's great news, cheers @behlendorf

Pauk

[qualar2]

Yay, perhaps something was updated in the tool chain but I've now got kernel modules loaded and my zraid is online, I'm happy. I'll post the RPM's in a mo

PS: I've just started 2 weeks off for xmas so I had some time to concentrate on this

Paul

[qualar2]

Compiled for kernel 3.17.6-300.fc21.x86_64

As github won't let me post RPMs i've added an .PNG extention, rename the files once downloaded

Paul

[behlendorf]

A new stable point release, 0.6.3-1.2, for EPEL / Fedora has been tagged. It includes backports of several patches to allow building with kernels up through Linux 3.18. It also includes several important bug fixes. For the full changelog see the following links.

https://github.com/zfsonlinux/zfs/commits/zfs-0.6.3-1.2 https://github.com/zfsonlinux/spl/commits/spl-0.6.3-1.2

This allowed be to setup a new Fedora 21 zfs repository for v0.6.3-1.2 and zfs-testing repository to track master. The official documentation has been updated accordingly. Enjoy!

[qualar2]

Thanks @behlendorf, although I used my own ZFS/SPL for a bit with success, after my kernal hung I had to power cycle my host and afterwards it was hanging on the boot process trying to mount my ZFS filesystems and giving me intermittent kernel errors. So, I removed my version and installed yours but now i get:-

-bash-4.3# zpool status pool: dpool state: UNAVAIL status: The pool cannot be accessed on this system because it uses the following feature(s) not supported on this system: com.delphix:hole_birth com.delphix:embedded_data

Was your ZFS source up-to-date?

Paul

[qualar2]

Back from my holidays and I've still not got this working, according to http://open-zfs.org/wiki/Features hole_birth is not supported on ZFSonLinux so how did the feature ever get enabled? (I've only had Gentoo and Fedora talking to the drives).

The documentation says features cannot be disable once enabled, is there a work around as I've probably not used these features?

Paul

[qualar2]

Ah, I see references to hole_birth in my git checked out version of ZFS, so I'm going to install that version and hope the kernel doesn't crash (not panicing though)

[behlendorf]

@qualar2 Those features (and more) have been added to the master branch and will be part of 0.6.4. The intention was to update the OpenZFS docs once that release is tagged. You must have run zpool upgrade while running the master branch and enabled them. My suggestion would be to run the zfs-testing repository which supports this features until the stable tag is released.

[ozialien]

Been using ZFS on Fedora without any problems up to 20 but 21 is a problem child. After a while the systems disk I/O across the board siezes up and zfs pools are stuck. No dmesg no specific I/O failure message etc... Wondered if anybody had experienced this.

[qualar2]

Yes @ozialien , every few days (3-5) I come to a hung system in the morning. I also find the garbage collector isn't freeing up space. If I "zfs umount -a" and re-mount them every night, then both problems go away.

[behlendorf]

Those issues are very likely due to kernel side changes which have been addressed in master. Once 0.6.4 rolls out to the repositories those issues should be addressed. Alternately you could roll back your kernel.