Arch Linux User Repository

yeah I can imagine so, the maintainers of the netatop pkgs dont really test their packages.. now, the error you showed was from the vanilla kernel, and the folder you showed was from the lts kernel? are the modules present from the vanilla as well?

Oh I remember what it was, it wasn't ZFS. I seem to remember tripping over netatop when I would do kernel upgrades in the past. That's why I switched to the DKMS version.

@eggz I know, it struck me as odd too.

% pacman -Qo /usr/lib/modules/5.4.38-1-lts/vmlinuz

/usr/lib/modules/5.4.38-1-lts/vmlinuz is owned by linux-lts 5.4.38-1

I did upgrade the kernel earlier this evening and rebooted. Even after rebooting, reinstalling all of the linux-* packages, and rebuilding, I get the same error.

I am using DKMS because I am currently using ZFS on this system, and had to upgrade to a new release of that package (for what reason escapes me at the moment), and can't, AFAIK, safely downgrade, so I figured why not just throw netatop in DKMS as well. I suppose I could switch to the non-DKMS version.

@hexadecagram missing kernel module tree?? I dont think its the fault of this package. its probably referring /usr/lib/modules/, is your kernel listed there? Did you install your headers and reboot? also why are you using dkms with the vanilla kernel? Cant you use the regular package instead?

When setting pkgver=3.1 (and of course sha256sums=('SKIP' '...') I get a successful build but see:

==> Unable to install module netatop/3.1 for kernel 5.6.10-arch1-1: Missing kernel modules tree.

( FYI Just update "pkgver=3.0" to "pkgver=3.1" and it's all good )

Hmm, your fix did not include the new proc notation fixes... Infact, that github doesnt even have the kernel module? Why is that kernel module not on git? Can't even see the changes there.

Version 3.1 has been released with fixes for kernel>=5.5

Simple if you understood any of that, certainly! Anyway, I can confirm that the amendments to prepare() provided by eggz work perfectly on my system. Thank you!

... OK so firstly,

boottime is a u64, not a u32. This was already in the changelog... C'mon guys... Pay attention...

then, as described in https://lore.kernel.org/linux-fsdevel/20191225172228.GA13378@avx2/ , You have to use proc_ops in newer kernels instead of file_operations

Proof of concept: use this prepare() of the PKGBUILD:

prepare() {
        true
        #patch -d "${srcdir}/${_pkgname}-${pkgver}" -Np1 -i "${srcdir}"/netatop_kernel_5.5.patch
        sed -i 's/timespec/timespec64/g'  $srcdir/$_pkgname-$pkgver/module/netatop.c
        sed -i 's/getboottime/getboottime64/g' $srcdir/$_pkgname-$pkgver/module/netatop.c
        sed -i 's/file_operations/proc_ops/g' $srcdir/$_pkgname-$pkgver/module/netatop.c
        sed -i 's/\.open/\.proc_open/g' $srcdir/$_pkgname-$pkgver/module/netatop.c
        sed -i 's/\.read/\.proc_read/g' $srcdir/$_pkgname-$pkgver/module/netatop.c
        sed -i 's/\.llseek/\.proc_lseek/g' $srcdir/$_pkgname-$pkgver/module/netatop.c
        sed -i 's/\.release/\.proc_release/g' $srcdir/$_pkgname-$pkgver/module/netatop.c
        sed -i '354d' $srcdir/$_pkgname-$pkgver/module/netatop.c
}

It should work then. I do not get why anyone has noticed this yet, also upstream. They could have already spot this minor problems upstream on RC kernels (yes, that is what they are for). Above all, This fix was very simple...