You are not logged in.
New user of Arch here, hi there!
I'd like to use ZFS with Arch in a sort of stable way; stable Linux with stable ZoL. The Wiki page is a good starter, but I'm confused with all the installation options offered and it seems the information is not correct.
It would be nice to avoid having to compile all the stuff every time, so precompiled modules would be preferred.
IIUC there are two options for me:
zfs-linux (AUR)
zfs-linux (archzfs repo)
Both provide the same package and the AUR one is listed as pushed by archzfs bot (Last Packager: archzfs-bot), so I think it's the very same thing, no?
The OpenZFS docs also mentions the two options: zfs-linux and the archzfs one. (Or do I already misunderstand it at this point?) And it clearly states;
zfs-linux* packages provides prebuilt modules.
Now, as I do not need the archzfs repository (already available in AUR), I decided to install the zfs-linux package.
To my surprise, it wants to build/compile the modules, it requires kernel headers to be installed, etc.
What am I doing wrong or what do I misunderstand here? And why do people suggest the archzfs repo if they push to AUR already?
Also; how exactly do I prevent from rendering my system into a state without ZFS support with future kernel updates? Will they be held back by pacman or do I need to take care of that myself? It's a bit unclear on the Wiki.
Last edited by gertvdijk (2022-04-25 19:14:14)
Offline
As you've noticed, the AUR "packages" are actually PKGBUILDs so that is not a pre-compiled kernel module but instructions on how to build a module so that a package is the end result, as is stated in https://wiki.archlinux.org/title/Arch_U … itory#FAQs you are advised to read that entire page to understand what the AUR is and isn't.
So if you want a binary package add the repo and install the appropriate module package from there, that's what it's for, it will use the linux-zfs recipe from the AUR for the building process but actually have a binary package. Rendering yourself into a state without zfs support should not happen as the point of the linux-zfs package is to simply ship with a dependency on the latest kernel version actually still compatible with zfs, and preventing an update should you actually attempt to update the kernel without an accompanying linux-zfs release. To be safe, wait a bit every time a new major version comes out, it usually takes a while for ZFS to catch up, e.g. when 5.18 will be released.
Last edited by V1del (2022-04-25 19:30:14)
Offline
Thanks. Still a bit unclear to me though:
So if you want a binary package add the repo and install the appropriate module package from there
Cool. But this is the same package; how do I select the source if multiple repos provide the same package?
I mean, I'm coming off Debian where you have the suite specifier like 'apt install -t buster-backports zfs-dkms'. Will I need something similar to be sure to install the archzfs one instead of AUR one?
Rendering yourself into a state without zfs support should not happen as the point of the linux-zfs package is to simply ship with a dependency on the latest kernel version actually still compatible with zfs, and preventing an update should you actually attempt to update the kernel without an accompanying linux-zfs release.
Got it. I'm fine with that.
To be safe, wait a bit every time a new major version comes out, it usually takes a while for ZFS to catch up, e.g. when 5.18 will be released.
Makes me think... what if I decide to reinstall my system just moments after 5.18 would be in Archs' repo, coming off a clean state without an older kernel+module installed, I would have no way to install ZFS until it's available again? I mean... sounds like a mess... is it really how things work? :confused:
Last edited by gertvdijk (2022-04-25 19:51:55)
Offline
Okay, to answer my own question fully.
It appears that somehow by selecting the package group archzfs-linux I get the zfs-linux and zfs-utils packages from the archzfs repo.
$ sudo pacman -S archzfs-linux
:: There are 2 members in group archzfs-linux:
:: Repository archzfs
1) zfs-linux 2) zfs-utils
Enter a selection (default=all):
resolving dependencies...
looking for conflicting packages...
Packages (2) zfs-linux-2.1.4_5.17.4.arch1.1-1 zfs-utils-2.1.4-2
Total Download Size: 30.26 MiB
Total Installed Size: 41.71 MiB
:: Proceed with installation? [Y/n]
And these are different packages as the AUR packages with the same name, the same publisher and the very same version string. I'm still dizzy but I get it now.
Update: currently experiencing the situation that the Arch kernel is newer than the archzfs kernel module.
$ paru
:: Synchronizing package databases...
core is up to date
extra is up to date
community is up to date
archzfs is up to date
:: Starting full system upgrade...
resolving dependencies...
looking for conflicting packages...
error: failed to prepare transaction (could not satisfy dependencies)
:: installing linux (5.17.5.arch1-1) breaks dependency 'linux=5.17.4.arch1-1' required by zfs-linux
I would have expected the package manager to be able to handle this and upgrade other packages that do not have a breaking dependency.
Last edited by gertvdijk (2022-04-28 20:46:23)
Offline
Again the AUR does not host binary packages but PKGBUILDs which contain make instruction and the like for compiling a given source and creating an actual package out of it you can then install. The archzfs repo is a repository holding the final packages from executing the PKGBUILD instructions so that you do not have to recompile them yourself.
For the question regarding the potentially problematic timeframe, you could if you absolutely needed to get an older kernel from the ALA but generally yes, this can be how things play out if you rely on an out of tree kernel module that's not quite as fast in adapting to new changes. I'm assuming they might be rather quick in general but you can expect at least a few weeks of delay from what I've seen, though no hands on experience
Offline
Mod note: moving to AUR Issues
Sakura:-
Mobo: MSI MAG X570S TORPEDO MAX // Processor: AMD Ryzen 9 5950X @4.9GHz // GFX: AMD Radeon RX 5700 XT // RAM: 32GB (4x 8GB) Corsair DDR4 (@ 3000MHz) // Storage: 1x 3TB HDD, 6x 1TB SSD, 2x 120GB SSD, 1x 275GB M2 SSD
Making lemonade from lemons since 2015.
Offline
I would have expected the package manager to be able to handle this and upgrade other packages that do not have a breaking dependency.
The package manager *is* handling this correctly. Partial upgrades are not supported. Basically, there are no packages which don't have a breaking dependency.
CLI Paste | How To Ask Questions
Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L
Offline
Partial upgrades are not supported. Basically, there are no packages which don't have a breaking dependency.
I probably misunderstood 'partial upgrades' then. To my ears it sounds really odd that packages *unrelated* to those with a breaking dependency cannot be upgraded. E.g. OpenSSL urgent security update cannot be performed because the kernel (unrelated) is held back (ArchZFS in my case).
I thought partial upgrades would only involve the packages with actual broken *dependencies* as suggested by the wording on the wiki talking about library / soname deps. Of course, I totally understand overriding that would be unsupported. https://wiki.archlinux.org/title/System … nsupported
[...] the packages in the repositories that need to be rebuilt against the libraries. For example, if two packages depend on the same library, upgrading only one package might also upgrade the library (as a dependency), which might then break the other package which depends on an older version of the library [...]
Last edited by gertvdijk (2022-05-07 12:59:01)
Offline
It's logically part of the same transaction so it doesn't continue, pacman doesn't know about or differentiate between "important" packages, there's a conflict in the transaction so it errs on the safe side and aborts. For your case you - as the system administrator - can be aware that this is safe and e.g. just ignore the linux package for this case until there's an update to zfs-linux. (the kernel is one of the few packages you can relatively safely keep in a IgnorePkg= definition and manually update once you see a compatibility got released)
Last edited by V1del (2022-05-08 09:25:35)
Offline
For your case you - as the system administrator - can be aware that this is safe and e.g. just ignore the linux package for this case until there's an update to zfs-linux. (the kernel is one of the few packages you can relatively safely keep in a IgnorePkg= definition and manually update once you see a compatibility got released)
Thanks! I consider the command line option '--ignore linux' as the elegant one-time way as override here. (and it works, it holds back the 5.17.6 just now.)
Last edited by gertvdijk (2022-05-11 22:30:12)
Offline