The real question would be, what kernel version is in RedHat 8.4 and does it fail today? If it is working, then are the changes in the codebase passed downstream or are they trapped in the RedHat proprietary code?
#VEEAM SUPPORT CODE#
This would be an awfully weird way of doing things - isn't the RedHat-only code their (limited) protected IP? I would not think that the fixes Veeam has been pushing and providing would qualify. However, if RedHat chose to incorporate the fixes only in their commercial code, it would be missed by Rocky Linux, since it would not be part of the code base passed down. In theory, code made part of the mainline build feeding into RedHat commercial release should appear in Rocky. Rocky Linux incorporating these changes remains downstream from RedHat on an ongoing basis. CentOS Steam is another matter, but it being upstream of RedHat would seem to offer no solution if the point of entry for the code fix is with RedHat. With CentOS 8 dying at the end of the year, there will be little need/impetus to address this issue for that distro. It may be the case that the fix code is being rolled into only the RedHat commercial version If this is done, then it would flow automatically into the downstream releases. Longer term, this does point to a CentOS issue and that it may be necessary for Veeam to work with the upstream maintainers to ensure it not only gets into the RedHat distro, but also into the codebase that the RedHat specific version is built from. Overall, this has been a positive experience for me, appearing to prove out how well Veeam with work with Rocky on the basis of this edge case where it actually broke! Rocky Linux has proven to be bug for bug compatible and exhibits exactly the same problem and exactly the same solution. Downgrade of at least the kernel restores functionality. So my experience has shown that CentOS 8.4 falls into this same problem and the kernel version that comes with it (at least today) does not have the necessary fixes to work with Veeam. The alternative is to downgrade across the board to 8.3, which also worked. This mixture was my preferred approach for Rocky Linux since it only went GA with 8.4. For both CentOS and Rocky Linux, I was able to leave the systems overall at the 8.4 version but downgrade the kernel back to kernel-4.18.0-240.22.1. This was the first kernel version of RedHat derivatives that broke volume snapshots with the incorporation of the 5.8 kernel enhancements. In both CentOS and Rocky Linux, 8.4 went out with kernel 4.18.0-305.3.1. In this case, the fault was bug-for-bug compatible with CentOS. I was able to confirm that the problem I was having was not with Rocky Linux, but rather with the newer kernel. lpbdeve| > |-tr:in virtual lpbdevenumlib::blkid::IBlkidProbe::Ptr lpbdevenumlib::accessor::CRealBlkidAccessor::ProbeDevice(const astr&) const at /mnt/Sources/LpbDevEnumLib/lpbdevenumlib/accessor/impl/RealBlkidAccessor.cpp:38 lpbdeve| > |-tr:CRealBlkidAccessor: Failed to probe device. lpbdeve| ERR |Failed to create DeviceInfoEx for device. I imagine the Veeam code needs a liberal sprinkling with “ || rocky” through the codebase. I also filed Veeam Support - Case # 04874548įWIW, here is the first sign of trouble in the Job log. Is there a timeframe for Rocky Linux support in Veam? (Disappointing but not entirely surprising).
However, once i defined the backup job, it fell over on execution.
#VEEAM SUPPORT INSTALL#
That worked just fine and I was able to install Veeam and get it started. I built up a Rocky Linux 8.4 system today using the GA code base that is now available.