Just a heads up - the DKMS modules for adding ZFS to the new kernel are not ready yet. Downgraded and on hold for now here…
That is why I use the zfs repo. The kernel won’t get upgraded unless zfs is available because of the way dependencies work.
Since I run zfs on root, my system won’t even boot without zfs support.
Eli needs to merge my PR.
Funny - I thought I was using the zfs repo…
I guess you mean using the kernels from there? My copy of the repo only supplies utils and dkms. I guess I just hit the double-zero this spin! Not a big problem, of course, as this is the first time they’ve been out of sync - and I only have the data drive pool on ZFS. I guess I’ll have to work harder now…
There should be specific packages for each kernel like
zfs-linux-lts that you can install instead of the dkms modules.
I guess I’ll try that on this build first. Removal of dkms starts it, I guess, then install the relevant kernel. Is AKM a good way to do that? I’ve only tried using -lts versions, and -zen versions so far…
Anyway - off to the battle!
My though has been to split strategies on different builds - some DKMS with hold, some with custom kernels (and hold) and some with custom kernels, hopefully updating in auto mode (if doable). That way there SHOULD be at least one working at all times
They aren’t kernels. They work with the existing arch kernels. If you are running
linux-lts, just install
If you are custom kernels you will have to use the dkms modules or build your own zfs modules for those kernels.
I wouldn’t be switching to -lts anytime soon - but when I swittch in another - will the standard hooks figure out to regenerate initcpio? @manuel amended AKM to include archzfs kernels, so I want to try it that way on at least 1 build…
I feel like we aren’t communicating here. There are no special kernels in this case. There are zfs packages for each of the standard Arch kernels. linux, linux-lts, linux-hardened, linux-zen, etc.
Yup - I have the list. Just didn’t know how the hooks work - and if they know/recognize them as standard Arch kernels. I gather there is no problem, so I’ll try that.
It is not that I can’t communicate - I’m just getting old! Thanks again.
I am just confused because you keep mentioning akm which doesn’t seem applicable here since you are not installing or removing kernels.
Further, what do you mean, “recognize them as standard arch kernels”? The package
zfs-linux isn’t a kernel. It is something you install alongside the normal
Wow - we really haven’t been communicating! AFAIK, this:
archzfs zfs-linux-zen 2.0.4_5.11.16.zen1.1-1 archzfs zfs-linux-zen-headers 2.0.4_5.11.16.zen1.1-1
is a replacement kernel and headers, found in the [archzfs] repo, that means I don’t need to use dkms to have zfs working. If not so, then I guess I’d better stick with what’s been working - even if it occasionally isn’t sync’d up with the newest kernel releases.
You are half right?
Those are not kernels, they are the zfs modules. They don’t replace the kernels, they replace the dkms modules.
Here is what one of those packages looks like:
pacman -Si zfs-linux Repository : archzfs Name : zfs-linux Version : 2.0.4_5.11.16.arch1.1-1 Description : Kernel modules for the Zettabyte File System. Architecture : x86_64 URL : https://zfsonlinux.org/ Licenses : CDDL Groups : archzfs-linux Provides : zfs spl Depends On : kmod zfs-utils=2.0.4 linux=5.11.16.arch1-1 Optional Deps : None Conflicts With : zfs-dkms zfs-dkms-git zfs-dkms-rc spl-dkms spl-dkms-git zfs-linux-git zfs-linux-rc spl-linux Replaces : spl-linux Download Size : 13.02 MiB Installed Size : 13.01 MiB Packager : Unknown Packager Build Date : Thu 22 Apr 2021 10:04:37 PM CDT Validated By : MD5 Sum SHA-256 Sum Signature
You can see it requires a specific kernel version. That ensures that your kernel won’t be updated before the zfs module is available.
There is a also a repo which holds matched versions of the kernels which makes things even smoother.
I’d better get them out of AKM then - I was ‘sure’ they were actual pre-built kernels with the correct modules… having the matching header files convinced me further! So - just install the package, and the -headers package - alongside the correct matching kernel, and the rest is automatic? Presumably I’d have to leave the standard kernel on ignore until the version of the modules matches up to the standard version? How do I track it, if so? Sorry to be so ignorant… I wasn’t back in the day when Amiga was the advanced system! (including a Unix addon at the time).
Here is what I do in
[archzfs] Server = http://archzfs.com/$repo/x86_64 [zfs-linux] Server = http://kernels.archzfs.com/$repo/ [zfs-linux-lts] Server = http://kernels.archzfs.com/$repo/
Those should be at the top of your repo lists since you want them to override the Arch repos in this case.
zfs-linux-lts repos contain copies of the kernels with matched version numbers so you don’t have to worry about holding kernels back manually. There is a repo for each kernel so you could also add
zfs-linux-zen for example.
Keep in mind, even though it is a separate repo, those are still just normal Arch kernels in there so they don’t require any special handling. It is basically an archive of the kernel with the correct version number.
Thanks for the pointer - so basically I add in another repo or 2 with ‘override’ kernels (by position of repo in list) - thus preventing the core versions from updating too far in advance of module availability. Can I dump the ‘standard’ kernel ignore, then? Or is it still a good idea (as it seems to me) to prevent the over-updating?
Adding in the -zen to see what happens!
I don’t have Timeshift - but at worst I have Shifttime (archive access script) instead…
You must remove the ignore. Since the kernels are the same, they will never get updated if you don’t.
Same - and same name too? Haven’t added the new repo yet - so I haven’t -Sl listed them yet! OK - will do…