dm-vdo
Build fails with kernel 5.14.0-503.14.1.el9_5.x86_64
The following errors are returned:
CC [M] /home/mtrojnar/src/kvdo/vdo/logger.o
/home/mtrojnar/src/kvdo/vdo/io-factory.c: In function ‘get_block_device_from_name’:
/home/mtrojnar/src/kvdo/vdo/io-factory.c:90:33: error: implicit declaration of function ‘blkdev_get_by_dev’; did you mean ‘blkdev_get_no_open’? [-Werror=implicit-function-declaration]
90 | factory->bdev = blkdev_get_by_dev(device, BLK_FMODE, NULL, &hops);
| ^~~~~~~~~~~~~~~~~
| blkdev_get_no_open
/home/mtrojnar/src/kvdo/vdo/io-factory.c:90:31: error: assignment to ‘struct block_device *’ from ‘int’ makes pointer from integer without a cast [-Werror=int-conversion]
90 | factory->bdev = blkdev_get_by_dev(device, BLK_FMODE, NULL, &hops);
| ^
CC [M] /home/mtrojnar/src/kvdo/vdo/logical-zone.o
/home/mtrojnar/src/kvdo/vdo/io-factory.c:122:33: error: implicit declaration of function ‘blkdev_get_by_path’; did you mean ‘blkdev_get_no_open’? [-Werror=implicit-function-declaration]
122 | factory->bdev = blkdev_get_by_path(name, BLK_FMODE, NULL, &hops);
| ^~~~~~~~~~~~~~~~~~
| blkdev_get_no_open
/home/mtrojnar/src/kvdo/vdo/io-factory.c:122:31: error: assignment to ‘struct block_device *’ from ‘int’ makes pointer from integer without a cast [-Werror=int-conversion]
122 | factory->bdev = blkdev_get_by_path(name, BLK_FMODE, NULL, &hops);
| ^
/home/mtrojnar/src/kvdo/vdo/io-factory.c: In function ‘replace_uds_storage’:
/home/mtrojnar/src/kvdo/vdo/io-factory.c:197:9: error: implicit declaration of function ‘blkdev_put’; did you mean ‘bdev_fput’? [-Werror=implicit-function-declaration]
197 | blkdev_put(factory->bdev, NULL);
| ^~~~~~~~~~
| bdev_fput
CC [M] /home/mtrojnar/src/kvdo/vdo/memory-alloc.o
Is this using the most recent release version (8.2.5.2)? From the version number, it looks like you're using an OracleLinux kernel, is that correct?
If you look in io-factory.c, you can see we do attempt to support a range of kernel versions, but we do so by relying on RHEL_RELEASE_VERSION and RHEL_RELEASE_EXTRA. If your kernel, say, doesn't define RHEL_RELEASE_EXTRA, the code could pick the wrong branch.
You could define RHEL_RELEASE_EXTRA=503 in your build, or you could edit io-factory.c to only include the branch you want (which is probably the one where all VDO_USE_ALTERNATE* symbols are undefined). The blkdev interface has been changing a lot lately and it's a bit tricky to try to keep it in sync.
Your RHEL_RELEASE_EXTRA=503 workaround worked fine. Thank very much for your help.
I updated my Rocky Linux to release 9.5 today, and built the module against the latest kernel-devel package distributed with the operating system. I don't use any fancy non-standard kernel on that machine.
$ cat /etc/system-release
Rocky Linux release 9.5 (Blue Onyx)
$ dnf list installed kernel*
Installed Packages
kernel.x86_64 5.14.0-427.40.1.el9_4 @baseos
kernel.x86_64 5.14.0-427.42.1.el9_4 @baseos
kernel.x86_64 5.14.0-503.14.1.el9_5 @baseos
kernel-core.x86_64 5.14.0-427.40.1.el9_4 @baseos
kernel-core.x86_64 5.14.0-427.42.1.el9_4 @baseos
kernel-core.x86_64 5.14.0-503.14.1.el9_5 @baseos
kernel-devel.x86_64 5.14.0-427.40.1.el9_4 @appstream
kernel-devel.x86_64 5.14.0-427.42.1.el9_4 @appstream
kernel-devel.x86_64 5.14.0-503.14.1.el9_5 @appstream
kernel-devel-matched.x86_64 5.14.0-503.14.1.el9_5 @appstream
kernel-headers.x86_64 5.14.0-503.14.1.el9_5 @appstream
kernel-modules.x86_64 5.14.0-427.40.1.el9_4 @baseos
kernel-modules.x86_64 5.14.0-427.42.1.el9_4 @baseos
kernel-modules.x86_64 5.14.0-503.14.1.el9_5 @baseos
kernel-modules-core.x86_64 5.14.0-427.40.1.el9_4 @baseos
kernel-modules-core.x86_64 5.14.0-427.42.1.el9_4 @baseos
kernel-modules-core.x86_64 5.14.0-503.14.1.el9_5 @baseos
kernel-modules-extra.x86_64 5.14.0-427.40.1.el9_4 @baseos
kernel-modules-extra.x86_64 5.14.0-427.42.1.el9_4 @baseos
kernel-modules-extra.x86_64 5.14.0-503.14.1.el9_5 @baseos
kernel-srpm-macros.noarch 1.0-13.el9 @appstream
kernel-tools.x86_64 5.14.0-503.14.1.el9_5 @baseos
kernel-tools-libs.x86_64 5.14.0-503.14.1.el9_5 @baseos
$ dnf provides /usr/src/kernels/5.14.0-503.14.1.el9_5.x86_64/
Last metadata expiration check: 2:35:47 ago on Fri Nov 22 16:24:15 2024.
kernel-devel-5.14.0-503.14.1.el9_5.x86_64 : Development package for building kernel modules to match the kernel
Repo : @System
Matched from:
Other : /usr/src/kernels/5.14.0-503.14.1.el9_5.x86_64/
kernel-devel-5.14.0-503.14.1.el9_5.x86_64 : Development package for building kernel modules to match the kernel
Repo : appstream
Matched from:
Other : /usr/src/kernels/5.14.0-503.14.1.el9_5.x86_64/
Also, it worked fine with the previous kernel.
Thanks for the extra information. I'm glad it is working for you.
I'm a bit surprised that RHEL_RELEASE_EXTRA isn't propagated to the Rocky kernel, but we'll keep it in mind in the future and try not to rely on it. It isn't usually necesssary, and I think our older releases don't use it, so they didn't see this issue. I don't think it's worth doing a new release just for this, but I'll be sure to get this addressed for future releases.
Rocky Linux is supposed to be built from open source RHEL SRPMs without any modifications, isn't it?
Please let me know if there is anything else I can help with.
As an update, I tracked down the RHEL_RELEASE_EXTRA parameter. It was something we added for internal builds but in retrospect we should not have included it in a released version.
There is a new release (8.2.5.10) available which removes all references to RHEL_RELEASE_EXTRA and should work without extra modifications.