Installing ZFS through the Command Line

Hello all. I am very new to Rockstor. Utilized ZFS via FreeNAS for a long time. I like the look and feel of Rockstor 3.9.0 but would like to have the ability to use ZFS until the BTRFS RAID5/6 stability becomes solid. That being said, I went ahead and gave these directions a shot:

I tried both the dkms and kabi methods. Both ended up giving me the same errors listed below:
"The ZFS modules are not loaded; Try running ‘/sbin/modprobe zfs’"
When trying to do that I get:
“modprobe: FATAL: Module zfs not found.”

So the interesting things is that I can find the module buried here:

I followed through all of the trouble-shooting I could for about 3 hours… At this point Im done beating my head against a wall and wanted to reach out to see if anyone has had any experience with this or similar things. Im guessing because Im new to this OS that Im missing something.

Thank you!

I guess the main question here is can it be done with the current build? ie install ZFS post or pre-build? If not, what are the technical barriers stopping one from doing so. Again, new to the structure of this OS so I might just be painfully unaware of something simple here…

Taking a deeper looks into the repositories that Rockstor is calling from, does the following have anything to do with this issue?..
ZFS™ (Zettabyte File System) is a combined file system and logical volume manager designed by Sun Microsystems.

Fedora releases don’t ship proper ZFS support included to kernel because its license CDDL (Common Development and Distribution License), instead it’s available as a FUSE (Filesystem in Userspace) module (pacakge name zfs-fuse).

@Devin_Kusek Hello and welcome to the Rockstor community.

Glad you like what we are doing. To address the issue of ZFS on linux and consequently Rockstor I’d like first to provide a little context:

You have already hit on the dubious licence under which ZFS is distributed and there is still much contention as to the legitimacy of distributing ZFS capabilities within a linux distribution. The CDDL is not known to be a good fit with GPL projects. Sorry but not a strong point for me so hopefully others can fill in more.

The taks of intergrating ZFS within Rockstor’s UI is not quite as straight forward as it at first may seem, this is due to btrfs being a generation on from ZFS by having block pointer re-write capability, something that is generally acknowledged by the ZFS developers as a feature that will never exist in that FS. It is something that the original ZFS developers had originally planned to add but it is now no longer possible to retro fit. The up-shoot is of course that ZFS is now considered maturity (within it’s current capabilities) and btrfs, especially in the raid 5/6 area is not. Of course btrfs is much younger as well. But nevertheless this capability lends an extraordinary flexibility to btrfs that is pretty much un-matched by any other existing COW file system. Rockstor directly benefits from this flexibility and it’s user interface is consequently ‘allowed’ to be flexibly by the same token. Introducing the same capabilities as we currently have whilst supporting ZFS is in some/most cases extremely non trivial whilst in others is actually impossible (ie raid level change). ZFS and btrfs are different organisms; although both share the rare COW nature.

I’m personally not interested in working on ZFS in Rockstor integration as I am of the opinion that we would always be playing catch up. Especially given that ZFS, even with the recent (note recent here) openZFS initiative, is not native to linux but to BSD (at least now). The ZFS on linux / openZFS project is having to integrate BSD ‘look-a-like’ systems within the linux kernel in order to ‘bolt-on’ ZFS capability to linux. Virtually every other fs in linux works differently and are integrated in a different way to how ZFS works with the linux kernel. This is a very significant component of the ‘hail ZFS on linux’ speak on the internet that is some how forgotten. I have only ever heard this mentioned by the Suse folk. So even though the on-disk-format and layers used to access it will be shared the ‘custom’ way it works with the linux kernel will be linux only. Hence the always playing catch up component. I personally think that ZFS will always belong more to FeeeBSD than to linux and I prefer to be working towards where the puck is going than where it has been.

Please excuse the potential rant nature of the above but also be aware that our very own Rockstor lead @suman had initially considered Rockstor to be based on ZFS and has been a ZFS contributor but ultimately went with btrfs. This had lead to an enormously flexible base upon which we can simply enact capabilities and ui components that non technical users simply expect (‘oh I’ve changed my mind re raid level’ or ‘Ill just add another disk to my array’). Also from the very ground up Rockstor is designed around btrfs’s capabilities. The vast majority of it’s functions would have to be re-written and or blocked / or otherwise explained differently in every interface were we to entertain ZFS as a ‘native’ storage format within Rockstor.

Obviously seemingly nothing in software is regarded as impossible (though this does rather deny the unsolvable arena of problems entirely) but I am strongly of the opinion that what Rockstor has achieved thus far is very much down to a focus on supporting a single FS as native. But it is also a recognised weakness as the world also contains partitions (Rockstor favours whole disk) and other file systems and by way of acknowledging this I have myself put quite a considerable amount of time into extending our disk, and in the future hopefully our filesystem, capabilities. However that does not include supporting ZFS as a btrfs counterpart within Rockstor. I also think that were we to introduce ZFS as a btrfs counterpart (which it is not) that it would severely complicate Rockstor’s interface and essentially ruin it’s advantage over every other NAS UI I have seen. We gain a lot from our btrfs focus and avoid the ‘everything and the kitchen sink’ approach that renders pretty much all other NAS UI’s as overly complex. I am particularly take by the apparent simplicity we are able to present by our focus and given human resources are always limited there are of course concerns of what is achievable. I would say that such an introduction would put us at least several years behind and would possibly loose us some key contributors.

Development is always a tricky game especially in the open as much work has to be put into preparing for the future while also serving current users. I think that Rockstor makes for a good (and improving) balance and as we see the btrfs dev folks marching steadily onward my hope is that Rockstor will in turn keep step with making these otherwise esoteric and exotic capabilities available in a super user friendly and accessible way.

To address your initial difficulties, (rather than those to come) re ZFS integration within Rockstor, it may help to appreciate that Rockstor is essentially CentOS 7.3 (1611) based (although the installer is still 7.2 (1511) based) and on top of this we run a much much newer kernel lifted straight from the elrepo ml (main line) kernel repository. I think that is the difficulty you are facing here as your reference from the text you used indicates the default kernel version of 3.10 rather than our current version of 4.10.

From you post I was not able to assess if your current unfamiliarity was with the linux OS in general or with Rockstor in particular :[quote=“Devin_Kusek, post:1, topic:3162”]
Im guessing because Im new to this OS that Im missing something.

If you could provide more context it should help with our (forum members) ability to help guide your efforts at an appropriate level. If you are prepared to suffer an inevitable Rockstor UI breakage then there is no reason at all that you can’t use Rockstor as the basis for you experiments, as long as you understand that it may well be more complicated than just using a standard server class linux distribution due to the specific customisation elements involved in Rockstor the distribution (though these are predominantly confined to btrfs related systemd scripts and mount behaviour). But the UI is very much tailored and written with btrfs in mind and ZFS is not by any means a drop in replacement, each has core capabilities that the other does not. Ie ZFS has zvols (a zfs backed block device) where as btrfs has no counterpart (currently anyway).

Don’t by any means be put off by my rather wordy and opinionated post in response to your very legitimate and welcome input, and all contributions have always been welcome. There are many members on this forum who are far more knowledgeable than me (probably most of them :slight_smile:), however I do have a passing familiarity with Rockstor’s current workings and am busy hopefully making them a little bit more capable each day. Prior to my involvement with Rockstor I also used FreeNAS in multiple locations over a number of years. It is pertinent I think that they seems to have recently suffered some growing pains with their corral effort: such technology change elements within a project can be very time consuming and potentially very disruptive.

Hope that helps and lets also hope we get some more contributors to this thread.

This is exactly what I needed to here. We would like to migrate over to Linux as that provides a huge boost to available hardware that we have the option to use in future developments just to give some context…

But yes, the recent events with ZFS, more appropriately, with the FreeNAS Project has been discouraging.

Interestingly enough, I was able to install ZFS on Linux Lite (dont know how familiar you are with that) with a few strokes on the command line. Would you know or have any insight on why that was so easy while i am hitting so many blocks with Rockstor? Again, this might be a terminology thing that I am just unaware of as far as what the underlying OS supports or the repo’s they draw from. And feel free to cut me off and tell me this is an inappropriate conversation for this forum or thread.

I do love the simplicity of the Rockstor OS which is why we want to integrate that, but at this time, it needs to have ZFS support. I also understand the straight mess it would cause to integrate that into the GUI, another thing we would need. So thank you for all of this Phillip!

The question remains. Outside of licensing disagreements, if one was to pursue installing a command line version of zfs, is it possible with the current Rockstor OS? Even better, has anyone been able to do it?

@Devin_Kusek Sorry I thought I had answered this more clearly than I obviously have, apologies for my miscommunication.


Rockstor (essentially a UI on top of CentOS 7.x) is currently very much designed around btrfs and virtually nothing will work with ZFS user interface wise. The underlying Linux should be fine though (as long as you account for our much newer kernel), but as I said before you are probably much better off using a generic linux server distro in which case. I would recommend Ubuntu server as I’m pretty sure they now include ZFS as an out of the box filesystem option upon install: if you use a new enough version anyway. However they have no free counterpart to Fedora server’s great Cockpit web interface. But they do offer a subscriptions based management UI; not sure how compatible something like Webmin is on Ubuntu server. Also Open Media Vault (another linux NAS disto), being of the ‘everything and the kitchen sink’ variant, also has a ZFS plugin / module though you may have to first enable some other elements / add-ons first, ie the newer kernel etc. Best ask on their forum for the details as I’m not very familiar any more and when I was, there was no openZFS project.

If you could re-read my last reply I would appreciate constructive criticism on how I missed the mark communication wise.

Hope that helps.

No marks missed whatsoever sir. I am just hardheaded when it comes to challenges and I did not see the words “impossible” or phrases like “it can’t be done.” I was not trying to be difficult with you. When I see something as difficult or very hard, that just means it hasnt been done and it is therefore on me to research and find out how to make it possible or why its impossible at this time. I understand the difficulties in working it into the UI. My goal was more on a command/root level as to provide an avenue for migrations/compatibility… that sort of thing. But please understand, your advice and guidance has given me more than enough to go forward with in my pursuit. One of those avenues may very well be with another OS as you gave a few example. Again, I appreciate the advice. Thank you for your time in responding so promptly.

In case you didn’t get it working…

The main difference is you have to use DKMS not “kABI-tracking kmod” and install kernel-ml-headers (4.10) not kernel-headers (3.10).