Compile Error for 6.2.6.14 for 5.18.5 kernel
madmax01 opened this issue · 17 comments
Hi Team,
make -C /usr/src/kernels/uname -r M=pwd
this gives me following Error:
make -C /usr/src/kernels/uname -r M=pwd
make: Entering directory '/usr/src/kernels/5.18.5-1.el8.elrepo.x86_64'
CC [M] /root/kvdo-6.2.6.14/uds/openChapter.o
In file included from /root/kvdo-6.2.6.14/uds/common.h:25,
from /root/kvdo-6.2.6.14/uds/openChapter.h:25,
from /root/kvdo-6.2.6.14/uds/openChapter.c:22:
/root/kvdo-6.2.6.14/uds/stringUtils.h:25:10: fatal error: stdarg.h: No such file or directory
#include <stdarg.h>
^~~~~~~~~~
compilation terminated.
make[2]: *** [scripts/Makefile.build:288: /root/kvdo-6.2.6.14/uds/openChapter.o] Error 1
make[1]: *** [scripts/Makefile.build:550: /root/kvdo-6.2.6.14/uds] Error 2
make: *** [Makefile:1834: /root/kvdo-6.2.6.14] Error 2
make: Leaving directory '/usr/src/kernels/5.18.5-1.el8.elrepo.x86_64'
do i miss something specific here?
thx
Max
Hi @madmax01,
Currently we have a known issue that causes a NULL pointer on the 5.18 kernel. When I get back to the office I intend to include the (hopefully) fix for it to my fork on Tuesday.
In the meantime, the issue you're encountering is addressed on [https://github.com/rhawalsh/kvdo](my fork) already [https://github.com/rhawalsh/kvdo/commit/ebb69f3d7451e6671abcb39da72fd87b4441334f](for this branch).
I also finally got the 6.2.7 branch posted that also builds up to 5.17 kernel.
There are a bunch of changes needed, so I would suggest reviewing the newer commits that are posted there.
Hi @rhawalsh
thx for the Info,
when i do this:
git clone --branch 6.2.6.14-COPR https://github.com/rhawalsh/kvdo.git
then i get this error
make: Entering directory '/usr/src/kernels/5.18.5-1.el8.elrepo.x86_64'
CC [M] /root/kvdo/uds/request.o
In file included from /root/kvdo/uds/request.h:32,
from /root/kvdo/uds/request.c:22:
/root/kvdo/uds/util/funnelQueue.h:80:39: error: ‘CACHE_LINE_BYTES’ undeclared here (not in a function); did you mean ‘MAX_UINSN_BYTES’?
typedef struct attribute((aligned(CACHE_LINE_BYTES))) funnelQueue {
^~~~~~~~~~~~~~~~
MAX_UINSN_BYTES
make[2]: *** [scripts/Makefile.build:288: /root/kvdo/uds/request.o] Error 1
make[1]: *** [scripts/Makefile.build:550: /root/kvdo/uds] Error 2
make: *** [Makefile:1834: /root/kvdo] Error 2
make: Leaving directory '/usr/src/kernels/5.18.5-1.el8.elrepo.x86_64'
when i try to create rpms i get this error
rpmbuild -ba kvdo.spec
- STATUS=0
- '[' 0 -ne 0 ']'
- cd rhawalsh-kvdo-161fbdf
/var/tmp/rpm-tmp.zT4M5N: line 40: cd: rhawalsh-kvdo-161fbdf: No such file or directory
error: Bad exit status from /var/tmp/rpm-tmp.zT4M5N (%prep)
RPM build errors:
Bad exit status from /var/tmp/rpm-tmp.zT4M5N (%prep)
-----------------------
enjoy weekend ;)
rhawalsh-kvdo-161fbdf not sure why it's blaming.... do i need to download all commits manually able to create the rpm?
Hi @madmax01,
I'm still working through the details for 5.18. I have not posted anything that I expect to work on that kernel just yet.
Hi @rhawalsh,
sry fully missunderstood you're message above.. just thought temp you're commit has a fix... ;(
many thx for you're Look ;) Enjoy rest day
Hi @madmax01, just wanted to let you know that I'm still working on this. It's taking longer than I was hoping to get past a couple of issues on our 6.2.7 branch to get it to build on 5.18+. I will post an update when I have something that works.
What is the perspective of solving this issue, I using fedora 36 and module version kmod-kvdo-6.2.7.9-2.fc36.x86_64 and stile not working on kernel 5.19.
Is it planned to migrate to version 8 in next fedora release?
Any status updates? A recent update F36 removed the older kernel that I had working with VDO. Can I use the latest 5.19 kernels? My Fedora hypervisor is now dead as I have more guest vms stored on a VDO volume.
For what it's worth I moved my stuff over to Btrfs as my main interest was in compression and deduplication, both of which Btrfs supports. Compression is supported transparently and deduplication I perform in a cron job using duperemove.
The results I get are very similar to what I got with VDO minus the high memory usage and kernel module woes. Only downside for me is that the deduplication doesn't run transparently in the background.
I have updated the way in which patches are handled against the main github tree so that you can see what is actually changing.
I have updated the dm-vdo COPR project for to work on all current releases of Fedora. The patches can be found on my test-vdo-patches github project.
I apologize for how long it takes for me to get these updates taken care of. I am hoping that this new structure makes it easier to maintain over time. But additionally, I had a particular change that I was uncomfortable with and wanted to run it through some more aggressive tests than just a simple smoke test to ensure I wasn't blowing things up.
Maintaining these builds via COPR and Fedora are a side project of mine, so when things get busy (or I fall behind on other tasks), this takes a back seat. So between my lack of confidence in the change, PTO, and catching up as a result, this fell way behind.
I would suggest that if you would like to follow builds that actually work against the latest Fedora as we use in our nightly testing, that you follow the vdo-devel project, as it is a direct mirror of our development environment. The caveat is that there is no longer a python-based VDO manager there and you'd need to convert any volumes over to using LVM-VDO instead. Of course, this is also the very tip of our development tree as well, so you may want to take some slightly older commits (+1 week, at least) to try and ensure the fewest bugs in the event that we introduce any throughout our development.
@rhawalsh Thank you so much for all that you do. I can imagine it is difficult to keep up with so much and you're doing this in your spare time.
I am looking for something fairly stable and do not need bleeding edge, but I do stay current on Fedora updates (monthly at least). I had originally set this up according to the vdo-devel instructions:
dnf copr enable rhawalsh/dm-vdo
But I can only see the 6.2 packages and cannot see the 8.x versions. Am I doing something wrong?
`[root@endor ~]# dnf repoquery --queryformat '%{name}-%{version}-%{release}-%{arch} : %{reponame}' vdo
Copr repo for dm-vdo owned by rhawalsh 8.8 kB/s | 3.3 kB 00:00
kmod-kvdo-6.2.7.17-3.fc36-src : copr:copr.fedorainfracloud.org:rhawalsh:dm-vdo
kmod-kvdo-6.2.7.17-3.fc36-x86_64 : copr:copr.fedorainfracloud.org:rhawalsh:dm-vdo
vdo-6.2.7.17-3.fc36-src : copr:copr.fedorainfracloud.org:rhawalsh:dm-vdo
vdo-6.2.7.17-3.fc36-x86_64 : copr:copr.fedorainfracloud.org:rhawalsh:dm-vdo
vdo-debuginfo-6.2.7.17-3.fc36-x86_64 : copr:copr.fedorainfracloud.org:rhawalsh:dm-vdo
vdo-debugsource-6.2.7.17-3.fc36-x86_64 : copr:copr.fedorainfracloud.org:rhawalsh:dm-vdo
vdo-support-6.2.7.17-3.fc36-x86_64 : copr:copr.fedorainfracloud.org:rhawalsh:dm-vdo
vdo-support-debuginfo-6.2.7.17-3.fc36-x86_64 : copr:copr.fedorainfracloud.org:rhawalsh:dm-vdo
`
Also, are there instructions for converting to lvmvdo? I'm looking into our RHEL 9 VDO docs and searching the customer portal and haven't found anything yet that clearly explains how to convert. I set this up about a year ago and don't recall how I configured it, but I may have created a VDO device as my PV backing my VG/LV. I can't see it right now due to the module loading, so once I get vdo working in the kernel I should be able to verify.
I found this, but it does not exactly give clear guidance on how to convert. Just a bunch of technical troubleshooting along the way of the process. https://bugzilla.redhat.com/show_bug.cgi?id=1930261
OK, actually after updating to your latest kmod-kvdo-6.2 builds, I think I can now see the volume. I'm going to update the rest of the OS, reboot, and try to mount it to recover files.
I found a few other links that explain using lvconvert to convert to lvmvod. However, since it destroys the data/filesystem and I have to move/restore the data anyway, it may make more sense to simply recreate it from scratch.
https://man7.org/linux/man-pages/man7/lvmvdo.7.html
https://www.reddit.com/r/debian/comments/ua401x/unable_to_convert_home_lvm_logical_volume_to_lvm/
I'll let you know how it works out. #userfeedback 😃
@tabowling There was actually a build error that still crept into the kmod-kvdo-6.2.7.17-3 builds on COPR. I somehow missed a single file that needed updates many times (not sure how, but ...).
If you upgrade to kmod-kvdo-6.2.7.17-4 from my rhawalsh/dm-vdo COPR, it should now work on F35, F36, and FRawhide (#60 (comment))
With regard to conversion on Fedora, it depends on tooling both in the vdo and lvm2 packages, which I think weren't quite available until recently. That's part of why I have ultimately kept (trying to) deliver the 6.2 code.
Of course, I would suggest actually testing the conversion in a test environment before doing it on a production system just to be safe.
@rhawalsh , Thanks for your contributions to vdo and kvdo. I've been happily working with your COPR branches on Ubuntu for a couple of years now.
Recently moved to a new machine, and in the mix I found myself using Ubuntu Kinetic Kudu (Kernel 5.19, I believe).
Anyways, I am seeing the identical error messages as seen in #60 , however, I am struggling to get things working, as I am not on Fedora, and the changes don't have a branch in https://github.com/rhawalsh/kvdo.
If it's not too much trouble, could you help me understand the path for Ubuntu users to benefit from your work specific to 6.2.7.17-4?
-- Will there be a branch for 6.2.7.17-4-COPR at rhawalsh/kvdo when you have spare cycles, or is there a new approach that should be considered?
Thanks again for your contributions!
Hi @jwest75674 ,
I can update the typical repository to have the 6.2.7.17-COPR branch, sure. I will try to get to that tonight. But in the meantime, if you look at this repo, you can see the patches that I'm applying to get the 6.2.7 code working on kernels up to and including 6.1.
Thanks @rhawalsh , That worked perfectly. I'll keep an eye on the test-vdo-patches moving forward!
It probably wouldn't hurt to update the typical repo for anyone else who has been following it for updates though!
Thank again!
Josh