v19.2.3 Squid released
We're happy to announce the third backport release in the Squid series. https://ceph.io/en/news/blog/2025/v19-2-3-squid-released/ Notable Changes --------------- * RGW: PutObjectLockConfiguration can now be used to enable S3 Object Lock on an existing versioning-enabled bucket that was not created with Object Lock enabled. * RADOS: A new command, `ceph osd rm-pg-upmap-primary-all`, has been added that allows users to clear all pg-upmap-primary mappings in the osdmap when desired. Related trackers: - https://tracker.ceph.com/issues/67179 - https://tracker.ceph.com/issues/66867 * RBD: Moving an image that is a member of a group to trash is no longer allowed. `rbd trash mv` command now behaves the same way as `rbd rm` in this scenario. * MGR: MGR's always-on modules/plugins can now be force-disabled. This can be necessary in cases where MGR(s) needs to be prevented from being flooded by the module commands when corresponding Ceph service is down/degraded. * RGW: An authentication bypass vulnerability in STS [CVE-2023-43040] has been fixed. * RGW: S3 policy now enforces ARN-based conditionals. * RGW: Copying an object to itself no longer causes data loss. Potential corruption on ETIMEDOUT (not enabled by default), was also fixed. Getting Ceph ------------ * Git at git://github.com/ceph/ceph.git * Tarball at https://download.ceph.com/tarballs/ceph-19.2.3.tar.gz * Containers at https://quay.io/repository/ceph/ceph * For packages, see https://docs.ceph.com/en/latest/install/get-packages/ * Release git sha1: c92aebb279828e9c3c1f5d24613efca272649e62
I have problems upgrading ceph from https://download.ceph.com/rpm-19.2.3/el9/x86_64/ and have broken dependencies on host running Almalinux 9.6 So: ceph orch upgrade start --ceph_version 19.2.3 works, but a dnf --refresh upgrade on ceph nodes gives broken dependencies ceph-poc1[0]:~# dnf --refresh upgrade isginf Extra Packages for 9 - x86_64 957 kB/s | 3.0 kB 00:00 AlmaLinux 9 - AppStream 12 kB/s | 4.2 kB 00:00 AlmaLinux 9 - BaseOS 10 kB/s | 3.8 kB 00:00 AlmaLinux 9 - CRB 12 kB/s | 4.2 kB 00:00 AlmaLinux 9 - Extras 9.7 kB/s | 3.8 kB 00:00 Ceph packages for x86_64 6.0 kB/s | 1.5 kB 00:00 Ceph noarch packages 5.9 kB/s | 1.5 kB 00:00 Ceph source packages 5.7 kB/s | 1.5 kB 00:00 Elastic repository for 8.x packages 83 kB/s | 1.5 kB 00:00 Extra Packages for Enterprise Linux 9 - x86_64 252 kB/s | 29 kB 00:00 Extra Packages for Enterprise Linux 9 openh264 (From Cisco) - x86_64 11 kB/s | 993 B 00:00 RPM Fusion for EL 9 - Free - Updates 40 kB/s | 8.3 kB 00:00 RPM Fusion for EL 9 - Nonfree - Updates 38 kB/s | 8.4 kB 00:00 SP CLIENT Repository ETHZ 323 kB/s | 3.0 kB 00:00 Error: Problem 1: cannot install the best update candidate for package ceph-common-2:19.2.2-0.el9.x86_64 - nothing provides libcrypto.so.3(OPENSSL_3.4.0)(64bit) needed by ceph-common-2:19.2.3-0.el9.x86_64 from Ceph Problem 2: cannot install the best update candidate for package librgw2-2:19.2.2-0.el9.x86_64 - nothing provides libcrypto.so.3(OPENSSL_3.4.0)(64bit) needed by librgw2-2:19.2.3-0.el9.x86_64 from Ceph Problem 3: package python3-rgw-2:19.2.3-0.el9.x86_64 from Ceph requires librgw2 = 2:19.2.3-0.el9, but none of the providers can be installed - cannot install the best update candidate for package python3-rgw-2:19.2.2-0.el9.x86_64 - nothing provides libcrypto.so.3(OPENSSL_3.4.0)(64bit) needed by librgw2-2:19.2.3-0.el9.x86_64 from Ceph Problem 4: package ceph-base-2:19.2.3-0.el9.x86_64 from Ceph requires librgw2 = 2:19.2.3-0.el9, but none of the providers can be installed - cannot install the best update candidate for package ceph-base-2:19.2.2-0.el9.x86_64 - nothing provides libcrypto.so.3(OPENSSL_3.4.0)(64bit) needed by librgw2-2:19.2.3-0.el9.x86_64 from Ceph Problem 5: package ceph-selinux-2:19.2.3-0.el9.x86_64 from Ceph requires ceph-base = 2:19.2.3-0.el9, but none of the providers can be installed - package ceph-base-2:19.2.3-0.el9.x86_64 from Ceph requires librgw2 = 2:19.2.3-0.el9, but none of the providers can be installed - cannot install the best update candidate for package ceph-selinux-2:19.2.2-0.el9.x86_64 - nothing provides libcrypto.so.3(OPENSSL_3.4.0)(64bit) needed by librgw2-2:19.2.3-0.el9.x86_64 from Ceph Problem 6: package librgw2-2:19.2.2-0.el9.x86_64 from @System requires librados2 = 2:19.2.2-0.el9, but none of the providers can be installed - cannot install both librados2-2:19.2.3-0.el9.x86_64 from Ceph and librados2-2:19.2.2-0.el9.x86_64 from @System - problem with installed package librgw2-2:19.2.2-0.el9.x86_64 - cannot install the best update candidate for package librados2-2:19.2.2-0.el9.x86_64 - nothing provides libcrypto.so.3(OPENSSL_3.4.0)(64bit) needed by librgw2-2:19.2.3-0.el9.x86_64 from Ceph Problem 7: package ceph-common-2:19.2.2-0.el9.x86_64 from @System requires libcephfs2 = 2:19.2.2-0.el9, but none of the providers can be installed - cannot install both libcephfs2-2:19.2.3-0.el9.x86_64 from Ceph and libcephfs2-2:19.2.2-0.el9.x86_64 from @System - problem with installed package ceph-common-2:19.2.2-0.el9.x86_64 - cannot install the best update candidate for package libcephfs2-2:19.2.2-0.el9.x86_64 - nothing provides libcrypto.so.3(OPENSSL_3.4.0)(64bit) needed by ceph-common-2:19.2.3-0.el9.x86_64 from Ceph Problem 8: package ceph-base-2:19.2.2-0.el9.x86_64 from @System requires librbd1 = 2:19.2.2-0.el9, but none of the providers can be installed - problem with installed package ceph-base-2:19.2.2-0.el9.x86_64 - cannot install both librbd1-2:19.2.3-0.el9.x86_64 from Ceph and librbd1-2:19.2.2-0.el9.x86_64 from @System - package ceph-base-2:19.2.3-0.el9.x86_64 from Ceph requires librgw2 = 2:19.2.3-0.el9, but none of the providers can be installed - cannot install the best update candidate for package librbd1-2:19.2.2-0.el9.x86_64 - nothing provides libcrypto.so.3(OPENSSL_3.4.0)(64bit) needed by librgw2-2:19.2.3-0.el9.x86_64 from Ceph Problem 9: package python3-rgw-2:19.2.2-0.el9.x86_64 from @System requires python3-rados = 2:19.2.2-0.el9, but none of the providers can be installed - problem with installed package python3-rgw-2:19.2.2-0.el9.x86_64 - cannot install both python3-rados-2:19.2.3-0.el9.x86_64 from Ceph and python3-rados-2:19.2.2-0.el9.x86_64 from @System - package python3-rgw-2:19.2.3-0.el9.x86_64 from Ceph requires librgw2 = 2:19.2.3-0.el9, but none of the providers can be installed - cannot install the best update candidate for package python3-rados-2:19.2.2-0.el9.x86_64 - nothing provides libcrypto.so.3(OPENSSL_3.4.0)(64bit) needed by librgw2-2:19.2.3-0.el9.x86_64 from Ceph Problem 10: package ceph-selinux-2:19.2.2-0.el9.x86_64 from @System requires ceph-base = 2:19.2.2-0.el9, but none of the providers can be installed - package ceph-base-2:19.2.2-0.el9.x86_64 from @System requires ceph-common = 2:19.2.2-0.el9, but none of the providers can be installed - problem with installed package ceph-selinux-2:19.2.2-0.el9.x86_64 - package ceph-common-2:19.2.2-0.el9.x86_64 from @System requires libradosstriper1 = 2:19.2.2-0.el9, but none of the providers can be installed - package ceph-selinux-2:19.2.3-0.el9.x86_64 from Ceph requires ceph-base = 2:19.2.3-0.el9, but none of the providers can be installed - cannot install both libradosstriper1-2:19.2.3-0.el9.x86_64 from Ceph and libradosstriper1-2:19.2.2-0.el9.x86_64 from @System - package ceph-base-2:19.2.3-0.el9.x86_64 from Ceph requires librgw2 = 2:19.2.3-0.el9, but none of the providers can be installed - cannot install the best update candidate for package libradosstriper1-2:19.2.2-0.el9.x86_64 - nothing provides libcrypto.so.3(OPENSSL_3.4.0)(64bit) needed by librgw2-2:19.2.3-0.el9.x86_64 from Ceph (try to add '--allowerasing' to command line to replace conflicting packages or '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages) Am 28.07.2025 um 16:59 schrieb Yuri Weinstein:
We're happy to announce the third backport release in the Squid series.
https://ceph.io/en/news/blog/2025/v19-2-3-squid-released/
Notable Changes
--------------- * RGW: PutObjectLockConfiguration can now be used to enable S3 Object Lock on an existing versioning-enabled bucket that was not created with Object Lock enabled. * RADOS: A new command, `ceph osd rm-pg-upmap-primary-all`, has been added that allows users to clear all pg-upmap-primary mappings in the osdmap when desired. Related trackers: - https://tracker.ceph.com/issues/67179 - https://tracker.ceph.com/issues/66867 * RBD: Moving an image that is a member of a group to trash is no longer allowed. `rbd trash mv` command now behaves the same way as `rbd rm` in this scenario. * MGR: MGR's always-on modules/plugins can now be force-disabled. This can be necessary in cases where MGR(s) needs to be prevented from being flooded by the module commands when corresponding Ceph service is down/degraded. * RGW: An authentication bypass vulnerability in STS [CVE-2023-43040] has been fixed. * RGW: S3 policy now enforces ARN-based conditionals. * RGW: Copying an object to itself no longer causes data loss. Potential corruption on ETIMEDOUT (not enabled by default), was also fixed.
Getting Ceph ------------ * Git at git://github.com/ceph/ceph.git * Tarball at https://download.ceph.com/tarballs/ceph-19.2.3.tar.gz * Containers at https://quay.io/repository/ceph/ceph * For packages, see https://docs.ceph.com/en/latest/install/get-packages/ * Release git sha1: c92aebb279828e9c3c1f5d24613efca272649e62 _______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io
Hi Moritz, Your issue seems similar to the one reported last Spring with 18.2 7. The problem is that Ceph RPM are built against CentOS rather than RHEL or one of its derivatives. As CentOS is upstream to RHEL, the result is that RPMs sometimes require dependencies not yet released in last RHEL release... Michel Sent from my mobile Le 29 juillet 2025 17:07:30 Moritz Baumann <mo@mo.homeip.net> a écrit :
I have problems upgrading ceph from
https://download.ceph.com/rpm-19.2.3/el9/x86_64/
and have broken dependencies on host running Almalinux 9.6
So:
ceph orch upgrade start --ceph_version 19.2.3
works, but a dnf --refresh upgrade on ceph nodes gives broken dependencies
ceph-poc1[0]:~# dnf --refresh upgrade isginf Extra Packages for 9 - x86_64 957 kB/s | 3.0 kB 00:00 AlmaLinux 9 - AppStream 12 kB/s | 4.2 kB 00:00 AlmaLinux 9 - BaseOS 10 kB/s | 3.8 kB 00:00 AlmaLinux 9 - CRB 12 kB/s | 4.2 kB 00:00 AlmaLinux 9 - Extras 9.7 kB/s | 3.8 kB 00:00 Ceph packages for x86_64 6.0 kB/s | 1.5 kB 00:00 Ceph noarch packages 5.9 kB/s | 1.5 kB 00:00 Ceph source packages 5.7 kB/s | 1.5 kB 00:00 Elastic repository for 8.x packages 83 kB/s | 1.5 kB 00:00 Extra Packages for Enterprise Linux 9 - x86_64 252 kB/s | 29 kB 00:00 Extra Packages for Enterprise Linux 9 openh264 (From Cisco) - x86_64 11 kB/s | 993 B 00:00 RPM Fusion for EL 9 - Free - Updates 40 kB/s | 8.3 kB 00:00 RPM Fusion for EL 9 - Nonfree - Updates 38 kB/s | 8.4 kB 00:00 SP CLIENT Repository ETHZ 323 kB/s | 3.0 kB 00:00 Error: Problem 1: cannot install the best update candidate for package ceph-common-2:19.2.2-0.el9.x86_64 - nothing provides libcrypto.so.3(OPENSSL_3.4.0)(64bit) needed by ceph-common-2:19.2.3-0.el9.x86_64 from Ceph Problem 2: cannot install the best update candidate for package librgw2-2:19.2.2-0.el9.x86_64 - nothing provides libcrypto.so.3(OPENSSL_3.4.0)(64bit) needed by librgw2-2:19.2.3-0.el9.x86_64 from Ceph Problem 3: package python3-rgw-2:19.2.3-0.el9.x86_64 from Ceph requires librgw2 = 2:19.2.3-0.el9, but none of the providers can be installed - cannot install the best update candidate for package python3-rgw-2:19.2.2-0.el9.x86_64 - nothing provides libcrypto.so.3(OPENSSL_3.4.0)(64bit) needed by librgw2-2:19.2.3-0.el9.x86_64 from Ceph Problem 4: package ceph-base-2:19.2.3-0.el9.x86_64 from Ceph requires librgw2 = 2:19.2.3-0.el9, but none of the providers can be installed - cannot install the best update candidate for package ceph-base-2:19.2.2-0.el9.x86_64 - nothing provides libcrypto.so.3(OPENSSL_3.4.0)(64bit) needed by librgw2-2:19.2.3-0.el9.x86_64 from Ceph Problem 5: package ceph-selinux-2:19.2.3-0.el9.x86_64 from Ceph requires ceph-base = 2:19.2.3-0.el9, but none of the providers can be installed - package ceph-base-2:19.2.3-0.el9.x86_64 from Ceph requires librgw2 = 2:19.2.3-0.el9, but none of the providers can be installed - cannot install the best update candidate for package ceph-selinux-2:19.2.2-0.el9.x86_64 - nothing provides libcrypto.so.3(OPENSSL_3.4.0)(64bit) needed by librgw2-2:19.2.3-0.el9.x86_64 from Ceph Problem 6: package librgw2-2:19.2.2-0.el9.x86_64 from @System requires librados2 = 2:19.2.2-0.el9, but none of the providers can be installed - cannot install both librados2-2:19.2.3-0.el9.x86_64 from Ceph and librados2-2:19.2.2-0.el9.x86_64 from @System - problem with installed package librgw2-2:19.2.2-0.el9.x86_64 - cannot install the best update candidate for package librados2-2:19.2.2-0.el9.x86_64 - nothing provides libcrypto.so.3(OPENSSL_3.4.0)(64bit) needed by librgw2-2:19.2.3-0.el9.x86_64 from Ceph Problem 7: package ceph-common-2:19.2.2-0.el9.x86_64 from @System requires libcephfs2 = 2:19.2.2-0.el9, but none of the providers can be installed - cannot install both libcephfs2-2:19.2.3-0.el9.x86_64 from Ceph and libcephfs2-2:19.2.2-0.el9.x86_64 from @System - problem with installed package ceph-common-2:19.2.2-0.el9.x86_64 - cannot install the best update candidate for package libcephfs2-2:19.2.2-0.el9.x86_64 - nothing provides libcrypto.so.3(OPENSSL_3.4.0)(64bit) needed by ceph-common-2:19.2.3-0.el9.x86_64 from Ceph Problem 8: package ceph-base-2:19.2.2-0.el9.x86_64 from @System requires librbd1 = 2:19.2.2-0.el9, but none of the providers can be installed - problem with installed package ceph-base-2:19.2.2-0.el9.x86_64 - cannot install both librbd1-2:19.2.3-0.el9.x86_64 from Ceph and librbd1-2:19.2.2-0.el9.x86_64 from @System - package ceph-base-2:19.2.3-0.el9.x86_64 from Ceph requires librgw2 = 2:19.2.3-0.el9, but none of the providers can be installed - cannot install the best update candidate for package librbd1-2:19.2.2-0.el9.x86_64 - nothing provides libcrypto.so.3(OPENSSL_3.4.0)(64bit) needed by librgw2-2:19.2.3-0.el9.x86_64 from Ceph Problem 9: package python3-rgw-2:19.2.2-0.el9.x86_64 from @System requires python3-rados = 2:19.2.2-0.el9, but none of the providers can be installed - problem with installed package python3-rgw-2:19.2.2-0.el9.x86_64 - cannot install both python3-rados-2:19.2.3-0.el9.x86_64 from Ceph and python3-rados-2:19.2.2-0.el9.x86_64 from @System - package python3-rgw-2:19.2.3-0.el9.x86_64 from Ceph requires librgw2 = 2:19.2.3-0.el9, but none of the providers can be installed - cannot install the best update candidate for package python3-rados-2:19.2.2-0.el9.x86_64 - nothing provides libcrypto.so.3(OPENSSL_3.4.0)(64bit) needed by librgw2-2:19.2.3-0.el9.x86_64 from Ceph Problem 10: package ceph-selinux-2:19.2.2-0.el9.x86_64 from @System requires ceph-base = 2:19.2.2-0.el9, but none of the providers can be installed - package ceph-base-2:19.2.2-0.el9.x86_64 from @System requires ceph-common = 2:19.2.2-0.el9, but none of the providers can be installed - problem with installed package ceph-selinux-2:19.2.2-0.el9.x86_64 - package ceph-common-2:19.2.2-0.el9.x86_64 from @System requires libradosstriper1 = 2:19.2.2-0.el9, but none of the providers can be installed - package ceph-selinux-2:19.2.3-0.el9.x86_64 from Ceph requires ceph-base = 2:19.2.3-0.el9, but none of the providers can be installed - cannot install both libradosstriper1-2:19.2.3-0.el9.x86_64 from Ceph and libradosstriper1-2:19.2.2-0.el9.x86_64 from @System - package ceph-base-2:19.2.3-0.el9.x86_64 from Ceph requires librgw2 = 2:19.2.3-0.el9, but none of the providers can be installed - cannot install the best update candidate for package libradosstriper1-2:19.2.2-0.el9.x86_64 - nothing provides libcrypto.so.3(OPENSSL_3.4.0)(64bit) needed by librgw2-2:19.2.3-0.el9.x86_64 from Ceph (try to add '--allowerasing' to command line to replace conflicting packages or '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)
Am 28.07.2025 um 16:59 schrieb Yuri Weinstein:
We're happy to announce the third backport release in the Squid series.
https://ceph.io/en/news/blog/2025/v19-2-3-squid-released/
Notable Changes
--------------- * RGW: PutObjectLockConfiguration can now be used to enable S3 Object Lock on an existing versioning-enabled bucket that was not created with Object Lock enabled. * RADOS: A new command, `ceph osd rm-pg-upmap-primary-all`, has been added that allows users to clear all pg-upmap-primary mappings in the osdmap when desired. Related trackers: - https://tracker.ceph.com/issues/67179 - https://tracker.ceph.com/issues/66867 * RBD: Moving an image that is a member of a group to trash is no longer allowed. `rbd trash mv` command now behaves the same way as `rbd rm` in this scenario. * MGR: MGR's always-on modules/plugins can now be force-disabled. This can be necessary in cases where MGR(s) needs to be prevented from being flooded by the module commands when corresponding Ceph service is down/degraded. * RGW: An authentication bypass vulnerability in STS [CVE-2023-43040] has been fixed. * RGW: S3 policy now enforces ARN-based conditionals. * RGW: Copying an object to itself no longer causes data loss. Potential corruption on ETIMEDOUT (not enabled by default), was also fixed.
Getting Ceph ------------ * Git at git://github.com/ceph/ceph.git * Tarball at https://download.ceph.com/tarballs/ceph-19.2.3.tar.gz * Containers at https://quay.io/repository/ceph/ceph * For packages, see https://docs.ceph.com/en/latest/install/get-packages/ * Release git sha1: c92aebb279828e9c3c1f5d24613efca272649e62 _______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io
ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io
Hi Michal, I am facing the same issue. Mine is fresh squid 19.2.3 installation on RockyLinux9.6. Rocky Linux is the same as Centos. So, please let me know how to fix it. OS : - Rocky Linux release 9.6 (Blue Onyx) Kernel :- 5.14.0-570.28.1.el9_6.x86_64 I need to install it at the earliest. Thanks, Gagan On Wed, Jul 30, 2025 at 1:02 AM Michel Jouvin <michel.jouvin@ijclab.in2p3.fr> wrote:
Hi Moritz,
Your issue seems similar to the one reported last Spring with 18.2 7. The problem is that Ceph RPM are built against CentOS rather than RHEL or one of its derivatives. As CentOS is upstream to RHEL, the result is that RPMs sometimes require dependencies not yet released in last RHEL release...
Michel Sent from my mobile Le 29 juillet 2025 17:07:30 Moritz Baumann <mo@mo.homeip.net> a écrit :
I have problems upgrading ceph from
https://download.ceph.com/rpm-19.2.3/el9/x86_64/
and have broken dependencies on host running Almalinux 9.6
So:
ceph orch upgrade start --ceph_version 19.2.3
works, but a dnf --refresh upgrade on ceph nodes gives broken dependencies
ceph-poc1[0]:~# dnf --refresh upgrade isginf Extra Packages for 9 - x86_64 957 kB/s | 3.0 kB 00:00 AlmaLinux 9 - AppStream 12 kB/s | 4.2 kB 00:00 AlmaLinux 9 - BaseOS 10 kB/s | 3.8 kB 00:00 AlmaLinux 9 - CRB 12 kB/s | 4.2 kB 00:00 AlmaLinux 9 - Extras 9.7 kB/s | 3.8 kB 00:00 Ceph packages for x86_64 6.0 kB/s | 1.5 kB 00:00 Ceph noarch packages 5.9 kB/s | 1.5 kB 00:00 Ceph source packages 5.7 kB/s | 1.5 kB 00:00 Elastic repository for 8.x packages 83 kB/s | 1.5 kB 00:00 Extra Packages for Enterprise Linux 9 - x86_64 252 kB/s | 29 kB 00:00 Extra Packages for Enterprise Linux 9 openh264 (From Cisco) - x86_64 11 kB/s | 993 B 00:00 RPM Fusion for EL 9 - Free - Updates 40 kB/s | 8.3 kB 00:00 RPM Fusion for EL 9 - Nonfree - Updates 38 kB/s | 8.4 kB 00:00 SP CLIENT Repository ETHZ 323 kB/s | 3.0 kB 00:00 Error: Problem 1: cannot install the best update candidate for package ceph-common-2:19.2.2-0.el9.x86_64 - nothing provides libcrypto.so.3(OPENSSL_3.4.0)(64bit) needed by ceph-common-2:19.2.3-0.el9.x86_64 from Ceph Problem 2: cannot install the best update candidate for package librgw2-2:19.2.2-0.el9.x86_64 - nothing provides libcrypto.so.3(OPENSSL_3.4.0)(64bit) needed by librgw2-2:19.2.3-0.el9.x86_64 from Ceph Problem 3: package python3-rgw-2:19.2.3-0.el9.x86_64 from Ceph requires librgw2 = 2:19.2.3-0.el9, but none of the providers can be installed - cannot install the best update candidate for package python3-rgw-2:19.2.2-0.el9.x86_64 - nothing provides libcrypto.so.3(OPENSSL_3.4.0)(64bit) needed by librgw2-2:19.2.3-0.el9.x86_64 from Ceph Problem 4: package ceph-base-2:19.2.3-0.el9.x86_64 from Ceph requires librgw2 = 2:19.2.3-0.el9, but none of the providers can be installed - cannot install the best update candidate for package ceph-base-2:19.2.2-0.el9.x86_64 - nothing provides libcrypto.so.3(OPENSSL_3.4.0)(64bit) needed by librgw2-2:19.2.3-0.el9.x86_64 from Ceph Problem 5: package ceph-selinux-2:19.2.3-0.el9.x86_64 from Ceph requires ceph-base = 2:19.2.3-0.el9, but none of the providers can be installed - package ceph-base-2:19.2.3-0.el9.x86_64 from Ceph requires librgw2 = 2:19.2.3-0.el9, but none of the providers can be installed - cannot install the best update candidate for package ceph-selinux-2:19.2.2-0.el9.x86_64 - nothing provides libcrypto.so.3(OPENSSL_3.4.0)(64bit) needed by librgw2-2:19.2.3-0.el9.x86_64 from Ceph Problem 6: package librgw2-2:19.2.2-0.el9.x86_64 from @System requires librados2 = 2:19.2.2-0.el9, but none of the providers can be installed - cannot install both librados2-2:19.2.3-0.el9.x86_64 from Ceph and librados2-2:19.2.2-0.el9.x86_64 from @System - problem with installed package librgw2-2:19.2.2-0.el9.x86_64 - cannot install the best update candidate for package librados2-2:19.2.2-0.el9.x86_64 - nothing provides libcrypto.so.3(OPENSSL_3.4.0)(64bit) needed by librgw2-2:19.2.3-0.el9.x86_64 from Ceph Problem 7: package ceph-common-2:19.2.2-0.el9.x86_64 from @System requires libcephfs2 = 2:19.2.2-0.el9, but none of the providers can be installed - cannot install both libcephfs2-2:19.2.3-0.el9.x86_64 from Ceph and libcephfs2-2:19.2.2-0.el9.x86_64 from @System - problem with installed package ceph-common-2:19.2.2-0.el9.x86_64 - cannot install the best update candidate for package libcephfs2-2:19.2.2-0.el9.x86_64 - nothing provides libcrypto.so.3(OPENSSL_3.4.0)(64bit) needed by ceph-common-2:19.2.3-0.el9.x86_64 from Ceph Problem 8: package ceph-base-2:19.2.2-0.el9.x86_64 from @System requires librbd1 = 2:19.2.2-0.el9, but none of the providers can be installed - problem with installed package ceph-base-2:19.2.2-0.el9.x86_64 - cannot install both librbd1-2:19.2.3-0.el9.x86_64 from Ceph and librbd1-2:19.2.2-0.el9.x86_64 from @System - package ceph-base-2:19.2.3-0.el9.x86_64 from Ceph requires librgw2 = 2:19.2.3-0.el9, but none of the providers can be installed - cannot install the best update candidate for package librbd1-2:19.2.2-0.el9.x86_64 - nothing provides libcrypto.so.3(OPENSSL_3.4.0)(64bit) needed by librgw2-2:19.2.3-0.el9.x86_64 from Ceph Problem 9: package python3-rgw-2:19.2.2-0.el9.x86_64 from @System requires python3-rados = 2:19.2.2-0.el9, but none of the providers can be installed - problem with installed package python3-rgw-2:19.2.2-0.el9.x86_64 - cannot install both python3-rados-2:19.2.3-0.el9.x86_64 from Ceph and python3-rados-2:19.2.2-0.el9.x86_64 from @System - package python3-rgw-2:19.2.3-0.el9.x86_64 from Ceph requires librgw2 = 2:19.2.3-0.el9, but none of the providers can be installed - cannot install the best update candidate for package python3-rados-2:19.2.2-0.el9.x86_64 - nothing provides libcrypto.so.3(OPENSSL_3.4.0)(64bit) needed by librgw2-2:19.2.3-0.el9.x86_64 from Ceph Problem 10: package ceph-selinux-2:19.2.2-0.el9.x86_64 from @System requires ceph-base = 2:19.2.2-0.el9, but none of the providers can be installed - package ceph-base-2:19.2.2-0.el9.x86_64 from @System requires ceph-common = 2:19.2.2-0.el9, but none of the providers can be installed - problem with installed package ceph-selinux-2:19.2.2-0.el9.x86_64 - package ceph-common-2:19.2.2-0.el9.x86_64 from @System requires libradosstriper1 = 2:19.2.2-0.el9, but none of the providers can be installed - package ceph-selinux-2:19.2.3-0.el9.x86_64 from Ceph requires ceph-base = 2:19.2.3-0.el9, but none of the providers can be installed - cannot install both libradosstriper1-2:19.2.3-0.el9.x86_64 from Ceph and libradosstriper1-2:19.2.2-0.el9.x86_64 from @System - package ceph-base-2:19.2.3-0.el9.x86_64 from Ceph requires librgw2 = 2:19.2.3-0.el9, but none of the providers can be installed - cannot install the best update candidate for package libradosstriper1-2:19.2.2-0.el9.x86_64 - nothing provides libcrypto.so.3(OPENSSL_3.4.0)(64bit) needed by librgw2-2:19.2.3-0.el9.x86_64 from Ceph (try to add '--allowerasing' to command line to replace conflicting packages or '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)
Am 28.07.2025 um 16:59 schrieb Yuri Weinstein:
We're happy to announce the third backport release in the Squid series.
https://ceph.io/en/news/blog/2025/v19-2-3-squid-released/
Notable Changes
--------------- * RGW: PutObjectLockConfiguration can now be used to enable S3 Object Lock on an existing versioning-enabled bucket that was not created with Object Lock enabled. * RADOS: A new command, `ceph osd rm-pg-upmap-primary-all`, has been added that allows users to clear all pg-upmap-primary mappings in the osdmap when desired. Related trackers: - https://tracker.ceph.com/issues/67179 - https://tracker.ceph.com/issues/66867 * RBD: Moving an image that is a member of a group to trash is no longer allowed. `rbd trash mv` command now behaves the same way as `rbd rm` in this scenario. * MGR: MGR's always-on modules/plugins can now be force-disabled. This can be necessary in cases where MGR(s) needs to be prevented from being flooded by the module commands when corresponding Ceph service is down/degraded. * RGW: An authentication bypass vulnerability in STS [CVE-2023-43040] has been fixed. * RGW: S3 policy now enforces ARN-based conditionals. * RGW: Copying an object to itself no longer causes data loss. Potential corruption on ETIMEDOUT (not enabled by default), was also fixed.
Getting Ceph ------------ * Git at git://github.com/ceph/ceph.git * Tarball at https://download.ceph.com/tarballs/ceph-19.2.3.tar.gz * Containers at https://quay.io/repository/ceph/ceph * For packages, see https://docs.ceph.com/en/latest/install/get-packages/ * Release git sha1: c92aebb279828e9c3c1f5d24613efca272649e62 _______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io
ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io
_______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io
I am facing this issue when I am trying to install ceph-common pkg. cephadm install ceph-common Installing packages ['ceph-common']... Non-zero exit code 1 from yum install -y ceph-common yum: stdout Last metadata expiration check: 0:00:28 ago on Wednesday 30 July 2025 10:09:50 AM. yum: stdout (try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages) yum: stderr Error: yum: stderr Problem: conflicting requests yum: stderr - nothing provides libcrypto.so.3(OPENSSL_3.4.0)(64bit) needed by ceph-common-2:19.2.3-0.el9.x86_64 from Ceph Traceback (most recent call last): File "/usr/lib64/python3.9/runpy.py", line 197, in _run_module_as_main return _run_code(code, main_globals, None, File "/usr/lib64/python3.9/runpy.py", line 87, in _run_code exec(code, run_globals) File "/usr/sbin/cephadm/__main__.py", line 5581, in <module> File "/usr/sbin/cephadm/__main__.py", line 5569, in main File "/usr/sbin/cephadm/__main__.py", line 4588, in command_install File "/usr/sbin/cephadm/cephadmlib/packagers.py", line 458, in install File "/usr/sbin/cephadm/cephadmlib/call_wrappers.py", line 307, in call_throws RuntimeError: Failed command: yum install -y ceph-common: Last metadata expiration check: 0:00:28 ago on Wednesday 30 July 2025 10:09:50 AM. (try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages) libcrypto.so.3 is present on the server. locate libcrypto.so.3 /usr/lib64/libcrypto.so.3 Thanks, Gagan On Wed, Jul 30, 2025 at 9:21 AM gagan tiwari < gagan.tiwari@mathisys-india.com> wrote:
Hi Michal, I am facing the same issue. Mine is fresh squid 19.2.3 installation on RockyLinux9.6. Rocky Linux is the same as Centos. So, please let me know how to fix it.
OS : - Rocky Linux release 9.6 (Blue Onyx)
Kernel :- 5.14.0-570.28.1.el9_6.x86_64
I need to install it at the earliest.
Thanks, Gagan
On Wed, Jul 30, 2025 at 1:02 AM Michel Jouvin < michel.jouvin@ijclab.in2p3.fr> wrote:
Hi Moritz,
Your issue seems similar to the one reported last Spring with 18.2 7. The problem is that Ceph RPM are built against CentOS rather than RHEL or one of its derivatives. As CentOS is upstream to RHEL, the result is that RPMs sometimes require dependencies not yet released in last RHEL release...
Michel Sent from my mobile Le 29 juillet 2025 17:07:30 Moritz Baumann <mo@mo.homeip.net> a écrit :
I have problems upgrading ceph from
https://download.ceph.com/rpm-19.2.3/el9/x86_64/
and have broken dependencies on host running Almalinux 9.6
So:
ceph orch upgrade start --ceph_version 19.2.3
works, but a dnf --refresh upgrade on ceph nodes gives broken dependencies
ceph-poc1[0]:~# dnf --refresh upgrade isginf Extra Packages for 9 - x86_64 957 kB/s | 3.0 kB 00:00 AlmaLinux 9 - AppStream 12 kB/s | 4.2 kB 00:00 AlmaLinux 9 - BaseOS 10 kB/s | 3.8 kB 00:00 AlmaLinux 9 - CRB 12 kB/s | 4.2 kB 00:00 AlmaLinux 9 - Extras 9.7 kB/s | 3.8 kB 00:00 Ceph packages for x86_64 6.0 kB/s | 1.5 kB 00:00 Ceph noarch packages 5.9 kB/s | 1.5 kB 00:00 Ceph source packages 5.7 kB/s | 1.5 kB 00:00 Elastic repository for 8.x packages 83 kB/s | 1.5 kB 00:00 Extra Packages for Enterprise Linux 9 - x86_64 252 kB/s | 29 kB 00:00 Extra Packages for Enterprise Linux 9 openh264 (From Cisco) - x86_64 11 kB/s | 993 B 00:00 RPM Fusion for EL 9 - Free - Updates 40 kB/s | 8.3 kB 00:00 RPM Fusion for EL 9 - Nonfree - Updates 38 kB/s | 8.4 kB 00:00 SP CLIENT Repository ETHZ 323 kB/s | 3.0 kB 00:00 Error: Problem 1: cannot install the best update candidate for package ceph-common-2:19.2.2-0.el9.x86_64 - nothing provides libcrypto.so.3(OPENSSL_3.4.0)(64bit) needed by ceph-common-2:19.2.3-0.el9.x86_64 from Ceph Problem 2: cannot install the best update candidate for package librgw2-2:19.2.2-0.el9.x86_64 - nothing provides libcrypto.so.3(OPENSSL_3.4.0)(64bit) needed by librgw2-2:19.2.3-0.el9.x86_64 from Ceph Problem 3: package python3-rgw-2:19.2.3-0.el9.x86_64 from Ceph requires librgw2 = 2:19.2.3-0.el9, but none of the providers can be installed - cannot install the best update candidate for package python3-rgw-2:19.2.2-0.el9.x86_64 - nothing provides libcrypto.so.3(OPENSSL_3.4.0)(64bit) needed by librgw2-2:19.2.3-0.el9.x86_64 from Ceph Problem 4: package ceph-base-2:19.2.3-0.el9.x86_64 from Ceph requires librgw2 = 2:19.2.3-0.el9, but none of the providers can be installed - cannot install the best update candidate for package ceph-base-2:19.2.2-0.el9.x86_64 - nothing provides libcrypto.so.3(OPENSSL_3.4.0)(64bit) needed by librgw2-2:19.2.3-0.el9.x86_64 from Ceph Problem 5: package ceph-selinux-2:19.2.3-0.el9.x86_64 from Ceph requires ceph-base = 2:19.2.3-0.el9, but none of the providers can be installed - package ceph-base-2:19.2.3-0.el9.x86_64 from Ceph requires librgw2 = 2:19.2.3-0.el9, but none of the providers can be installed - cannot install the best update candidate for package ceph-selinux-2:19.2.2-0.el9.x86_64 - nothing provides libcrypto.so.3(OPENSSL_3.4.0)(64bit) needed by librgw2-2:19.2.3-0.el9.x86_64 from Ceph Problem 6: package librgw2-2:19.2.2-0.el9.x86_64 from @System requires librados2 = 2:19.2.2-0.el9, but none of the providers can be installed - cannot install both librados2-2:19.2.3-0.el9.x86_64 from Ceph and librados2-2:19.2.2-0.el9.x86_64 from @System - problem with installed package librgw2-2:19.2.2-0.el9.x86_64 - cannot install the best update candidate for package librados2-2:19.2.2-0.el9.x86_64 - nothing provides libcrypto.so.3(OPENSSL_3.4.0)(64bit) needed by librgw2-2:19.2.3-0.el9.x86_64 from Ceph Problem 7: package ceph-common-2:19.2.2-0.el9.x86_64 from @System requires libcephfs2 = 2:19.2.2-0.el9, but none of the providers can be installed - cannot install both libcephfs2-2:19.2.3-0.el9.x86_64 from Ceph and libcephfs2-2:19.2.2-0.el9.x86_64 from @System - problem with installed package ceph-common-2:19.2.2-0.el9.x86_64 - cannot install the best update candidate for package libcephfs2-2:19.2.2-0.el9.x86_64 - nothing provides libcrypto.so.3(OPENSSL_3.4.0)(64bit) needed by ceph-common-2:19.2.3-0.el9.x86_64 from Ceph Problem 8: package ceph-base-2:19.2.2-0.el9.x86_64 from @System requires librbd1 = 2:19.2.2-0.el9, but none of the providers can be installed - problem with installed package ceph-base-2:19.2.2-0.el9.x86_64 - cannot install both librbd1-2:19.2.3-0.el9.x86_64 from Ceph and librbd1-2:19.2.2-0.el9.x86_64 from @System - package ceph-base-2:19.2.3-0.el9.x86_64 from Ceph requires librgw2 = 2:19.2.3-0.el9, but none of the providers can be installed - cannot install the best update candidate for package librbd1-2:19.2.2-0.el9.x86_64 - nothing provides libcrypto.so.3(OPENSSL_3.4.0)(64bit) needed by librgw2-2:19.2.3-0.el9.x86_64 from Ceph Problem 9: package python3-rgw-2:19.2.2-0.el9.x86_64 from @System requires python3-rados = 2:19.2.2-0.el9, but none of the providers can be installed - problem with installed package python3-rgw-2:19.2.2-0.el9.x86_64 - cannot install both python3-rados-2:19.2.3-0.el9.x86_64 from Ceph and python3-rados-2:19.2.2-0.el9.x86_64 from @System - package python3-rgw-2:19.2.3-0.el9.x86_64 from Ceph requires librgw2 = 2:19.2.3-0.el9, but none of the providers can be installed - cannot install the best update candidate for package python3-rados-2:19.2.2-0.el9.x86_64 - nothing provides libcrypto.so.3(OPENSSL_3.4.0)(64bit) needed by librgw2-2:19.2.3-0.el9.x86_64 from Ceph Problem 10: package ceph-selinux-2:19.2.2-0.el9.x86_64 from @System requires ceph-base = 2:19.2.2-0.el9, but none of the providers can be installed - package ceph-base-2:19.2.2-0.el9.x86_64 from @System requires ceph-common = 2:19.2.2-0.el9, but none of the providers can be installed - problem with installed package ceph-selinux-2:19.2.2-0.el9.x86_64 - package ceph-common-2:19.2.2-0.el9.x86_64 from @System requires libradosstriper1 = 2:19.2.2-0.el9, but none of the providers can be installed - package ceph-selinux-2:19.2.3-0.el9.x86_64 from Ceph requires ceph-base = 2:19.2.3-0.el9, but none of the providers can be installed - cannot install both libradosstriper1-2:19.2.3-0.el9.x86_64 from Ceph and libradosstriper1-2:19.2.2-0.el9.x86_64 from @System - package ceph-base-2:19.2.3-0.el9.x86_64 from Ceph requires librgw2 = 2:19.2.3-0.el9, but none of the providers can be installed - cannot install the best update candidate for package libradosstriper1-2:19.2.2-0.el9.x86_64 - nothing provides libcrypto.so.3(OPENSSL_3.4.0)(64bit) needed by librgw2-2:19.2.3-0.el9.x86_64 from Ceph (try to add '--allowerasing' to command line to replace conflicting packages or '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)
Am 28.07.2025 um 16:59 schrieb Yuri Weinstein:
We're happy to announce the third backport release in the Squid series.
https://ceph.io/en/news/blog/2025/v19-2-3-squid-released/
Notable Changes
--------------- * RGW: PutObjectLockConfiguration can now be used to enable S3 Object Lock on an existing versioning-enabled bucket that was not created with Object Lock enabled. * RADOS: A new command, `ceph osd rm-pg-upmap-primary-all`, has been added that allows users to clear all pg-upmap-primary mappings in the osdmap when desired. Related trackers: - https://tracker.ceph.com/issues/67179 - https://tracker.ceph.com/issues/66867 * RBD: Moving an image that is a member of a group to trash is no longer allowed. `rbd trash mv` command now behaves the same way as `rbd rm` in this scenario. * MGR: MGR's always-on modules/plugins can now be force-disabled. This can be necessary in cases where MGR(s) needs to be prevented from being flooded by the module commands when corresponding Ceph service is down/degraded. * RGW: An authentication bypass vulnerability in STS [CVE-2023-43040] has been fixed. * RGW: S3 policy now enforces ARN-based conditionals. * RGW: Copying an object to itself no longer causes data loss. Potential corruption on ETIMEDOUT (not enabled by default), was also fixed.
Getting Ceph ------------ * Git at git://github.com/ceph/ceph.git * Tarball at https://download.ceph.com/tarballs/ceph-19.2.3.tar.gz * Containers at https://quay.io/repository/ceph/ceph * For packages, see https://docs.ceph.com/en/latest/install/get-packages/ * Release git sha1: c92aebb279828e9c3c1f5d24613efca272649e62 _______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io
ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io
_______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io
Non CentOS is not exactly the same as RHEL or any derivatives. It is upstream, meaning it contains new things that will be in next RHEL or derivatives release. That's the issue with Ceph RPM packages. I don't know any workaround (except rebuilding from sources) but I am not an expert! Michel Sent from my mobile Le 30 juillet 2025 05:51:33 gagan tiwari <gagan.tiwari@mathisys-india.com> a écrit :
Hi Michal, I am facing the same issue. Mine is fresh squid 19.2.3 installation on RockyLinux9.6. Rocky Linux is the same as Centos. So, please let me know how to fix it.
OS : - Rocky Linux release 9.6 (Blue Onyx)
Kernel :- 5.14.0-570.28.1.el9_6.x86_64
I need to install it at the earliest.
Thanks, Gagan
On Wed, Jul 30, 2025 at 1:02 AM Michel Jouvin <michel.jouvin@ijclab.in2p3.fr> wrote: Hi Moritz,
Your issue seems similar to the one reported last Spring with 18.2 7. The problem is that Ceph RPM are built against CentOS rather than RHEL or one of its derivatives. As CentOS is upstream to RHEL, the result is that RPMs sometimes require dependencies not yet released in last RHEL release...
Michel Sent from my mobile Le 29 juillet 2025 17:07:30 Moritz Baumann <mo@mo.homeip.net> a écrit :
I have problems upgrading ceph from
https://download.ceph.com/rpm-19.2.3/el9/x86_64/
and have broken dependencies on host running Almalinux 9.6
So:
ceph orch upgrade start --ceph_version 19.2.3
works, but a dnf --refresh upgrade on ceph nodes gives broken dependencies
ceph-poc1[0]:~# dnf --refresh upgrade isginf Extra Packages for 9 - x86_64 957 kB/s | 3.0 kB 00:00 AlmaLinux 9 - AppStream 12 kB/s | 4.2 kB 00:00 AlmaLinux 9 - BaseOS 10 kB/s | 3.8 kB 00:00 AlmaLinux 9 - CRB 12 kB/s | 4.2 kB 00:00 AlmaLinux 9 - Extras 9.7 kB/s | 3.8 kB 00:00 Ceph packages for x86_64 6.0 kB/s | 1.5 kB 00:00 Ceph noarch packages 5.9 kB/s | 1.5 kB 00:00 Ceph source packages 5.7 kB/s | 1.5 kB 00:00 Elastic repository for 8.x packages 83 kB/s | 1.5 kB 00:00 Extra Packages for Enterprise Linux 9 - x86_64 252 kB/s | 29 kB 00:00 Extra Packages for Enterprise Linux 9 openh264 (From Cisco) - x86_64 11 kB/s | 993 B 00:00 RPM Fusion for EL 9 - Free - Updates 40 kB/s | 8.3 kB 00:00 RPM Fusion for EL 9 - Nonfree - Updates 38 kB/s | 8.4 kB 00:00 SP CLIENT Repository ETHZ 323 kB/s | 3.0 kB 00:00 Error: Problem 1: cannot install the best update candidate for package ceph-common-2:19.2.2-0.el9.x86_64 - nothing provides libcrypto.so.3(OPENSSL_3.4.0)(64bit) needed by ceph-common-2:19.2.3-0.el9.x86_64 from Ceph Problem 2: cannot install the best update candidate for package librgw2-2:19.2.2-0.el9.x86_64 - nothing provides libcrypto.so.3(OPENSSL_3.4.0)(64bit) needed by librgw2-2:19.2.3-0.el9.x86_64 from Ceph Problem 3: package python3-rgw-2:19.2.3-0.el9.x86_64 from Ceph requires librgw2 = 2:19.2.3-0.el9, but none of the providers can be installed - cannot install the best update candidate for package python3-rgw-2:19.2.2-0.el9.x86_64 - nothing provides libcrypto.so.3(OPENSSL_3.4.0)(64bit) needed by librgw2-2:19.2.3-0.el9.x86_64 from Ceph Problem 4: package ceph-base-2:19.2.3-0.el9.x86_64 from Ceph requires librgw2 = 2:19.2.3-0.el9, but none of the providers can be installed - cannot install the best update candidate for package ceph-base-2:19.2.2-0.el9.x86_64 - nothing provides libcrypto.so.3(OPENSSL_3.4.0)(64bit) needed by librgw2-2:19.2.3-0.el9.x86_64 from Ceph Problem 5: package ceph-selinux-2:19.2.3-0.el9.x86_64 from Ceph requires ceph-base = 2:19.2.3-0.el9, but none of the providers can be installed - package ceph-base-2:19.2.3-0.el9.x86_64 from Ceph requires librgw2 = 2:19.2.3-0.el9, but none of the providers can be installed - cannot install the best update candidate for package ceph-selinux-2:19.2.2-0.el9.x86_64 - nothing provides libcrypto.so.3(OPENSSL_3.4.0)(64bit) needed by librgw2-2:19.2.3-0.el9.x86_64 from Ceph Problem 6: package librgw2-2:19.2.2-0.el9.x86_64 from @System requires librados2 = 2:19.2.2-0.el9, but none of the providers can be installed - cannot install both librados2-2:19.2.3-0.el9.x86_64 from Ceph and librados2-2:19.2.2-0.el9.x86_64 from @System - problem with installed package librgw2-2:19.2.2-0.el9.x86_64 - cannot install the best update candidate for package librados2-2:19.2.2-0.el9.x86_64 - nothing provides libcrypto.so.3(OPENSSL_3.4.0)(64bit) needed by librgw2-2:19.2.3-0.el9.x86_64 from Ceph Problem 7: package ceph-common-2:19.2.2-0.el9.x86_64 from @System requires libcephfs2 = 2:19.2.2-0.el9, but none of the providers can be installed - cannot install both libcephfs2-2:19.2.3-0.el9.x86_64 from Ceph and libcephfs2-2:19.2.2-0.el9.x86_64 from @System - problem with installed package ceph-common-2:19.2.2-0.el9.x86_64 - cannot install the best update candidate for package libcephfs2-2:19.2.2-0.el9.x86_64 - nothing provides libcrypto.so.3(OPENSSL_3.4.0)(64bit) needed by ceph-common-2:19.2.3-0.el9.x86_64 from Ceph Problem 8: package ceph-base-2:19.2.2-0.el9.x86_64 from @System requires librbd1 = 2:19.2.2-0.el9, but none of the providers can be installed - problem with installed package ceph-base-2:19.2.2-0.el9.x86_64 - cannot install both librbd1-2:19.2.3-0.el9.x86_64 from Ceph and librbd1-2:19.2.2-0.el9.x86_64 from @System - package ceph-base-2:19.2.3-0.el9.x86_64 from Ceph requires librgw2 = 2:19.2.3-0.el9, but none of the providers can be installed - cannot install the best update candidate for package librbd1-2:19.2.2-0.el9.x86_64 - nothing provides libcrypto.so.3(OPENSSL_3.4.0)(64bit) needed by librgw2-2:19.2.3-0.el9.x86_64 from Ceph Problem 9: package python3-rgw-2:19.2.2-0.el9.x86_64 from @System requires python3-rados = 2:19.2.2-0.el9, but none of the providers can be installed - problem with installed package python3-rgw-2:19.2.2-0.el9.x86_64 - cannot install both python3-rados-2:19.2.3-0.el9.x86_64 from Ceph and python3-rados-2:19.2.2-0.el9.x86_64 from @System - package python3-rgw-2:19.2.3-0.el9.x86_64 from Ceph requires librgw2 = 2:19.2.3-0.el9, but none of the providers can be installed - cannot install the best update candidate for package python3-rados-2:19.2.2-0.el9.x86_64 - nothing provides libcrypto.so.3(OPENSSL_3.4.0)(64bit) needed by librgw2-2:19.2.3-0.el9.x86_64 from Ceph Problem 10: package ceph-selinux-2:19.2.2-0.el9.x86_64 from @System requires ceph-base = 2:19.2.2-0.el9, but none of the providers can be installed - package ceph-base-2:19.2.2-0.el9.x86_64 from @System requires ceph-common = 2:19.2.2-0.el9, but none of the providers can be installed - problem with installed package ceph-selinux-2:19.2.2-0.el9.x86_64 - package ceph-common-2:19.2.2-0.el9.x86_64 from @System requires libradosstriper1 = 2:19.2.2-0.el9, but none of the providers can be installed - package ceph-selinux-2:19.2.3-0.el9.x86_64 from Ceph requires ceph-base = 2:19.2.3-0.el9, but none of the providers can be installed - cannot install both libradosstriper1-2:19.2.3-0.el9.x86_64 from Ceph and libradosstriper1-2:19.2.2-0.el9.x86_64 from @System - package ceph-base-2:19.2.3-0.el9.x86_64 from Ceph requires librgw2 = 2:19.2.3-0.el9, but none of the providers can be installed - cannot install the best update candidate for package libradosstriper1-2:19.2.2-0.el9.x86_64 - nothing provides libcrypto.so.3(OPENSSL_3.4.0)(64bit) needed by librgw2-2:19.2.3-0.el9.x86_64 from Ceph (try to add '--allowerasing' to command line to replace conflicting packages or '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)
Am 28.07.2025 um 16:59 schrieb Yuri Weinstein:
We're happy to announce the third backport release in the Squid series.
https://ceph.io/en/news/blog/2025/v19-2-3-squid-released/
Notable Changes
--------------- * RGW: PutObjectLockConfiguration can now be used to enable S3 Object Lock on an existing versioning-enabled bucket that was not created with Object Lock enabled. * RADOS: A new command, `ceph osd rm-pg-upmap-primary-all`, has been added that allows users to clear all pg-upmap-primary mappings in the osdmap when desired. Related trackers: - https://tracker.ceph.com/issues/67179 - https://tracker.ceph.com/issues/66867 * RBD: Moving an image that is a member of a group to trash is no longer allowed. `rbd trash mv` command now behaves the same way as `rbd rm` in this scenario. * MGR: MGR's always-on modules/plugins can now be force-disabled. This can be necessary in cases where MGR(s) needs to be prevented from being flooded by the module commands when corresponding Ceph service is down/degraded. * RGW: An authentication bypass vulnerability in STS [CVE-2023-43040] has been fixed. * RGW: S3 policy now enforces ARN-based conditionals. * RGW: Copying an object to itself no longer causes data loss. Potential corruption on ETIMEDOUT (not enabled by default), was also fixed.
Getting Ceph ------------ * Git at git://github.com/ceph/ceph.git * Tarball at https://download.ceph.com/tarballs/ceph-19.2.3.tar.gz * Containers at https://quay.io/repository/ceph/ceph * For packages, see https://docs.ceph.com/en/latest/install/get-packages/ * Release git sha1: c92aebb279828e9c3c1f5d24613efca272649e62 _______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io
ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io
_______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io
And it looks quite difficult to build a new rpm from ceph-19.2.3-0.el9.src.rpm for RHEL9 OS. I just try in a VM in Almalinux 9 and many requirements are not met and some are not available. I've just deployed Squid 19.2.2 on a fresh cluster based on Almalinux 9.6... 😕 rpmbuild --rebuild ceph-19.2.3-0.el9.src.rpm Installing ceph-19.2.3-0.el9.src.rpm warning: ceph-19.2.3-0.el9.src.rpm: Header V4 RSA/SHA256 Signature, key ID 460f3994: NOKEY warning: user jenkins-build does not exist - using root warning: user jenkins-build does not exist - using root warning: extra tokens at the end of %else directive in line 118: %else # not fedora/rhel warning: extra tokens at the end of %else directive in line 121: %else # not x86_64 warning: line 1136: It's not recommended to have unversioned Obsoletes: Obsoletes: ceph-libcephfs error: Failed build dependencies: CUnit-devel is needed by ceph-2:19.2.3-0.el9.x86_64 boost-random is needed by ceph-2:19.2.3-0.el9.x86_64 cryptsetup-devel is needed by ceph-2:19.2.3-0.el9.x86_64 daxctl-devel >= 63 is needed by ceph-2:19.2.3-0.el9.x86_64 expat-devel is needed by ceph-2:19.2.3-0.el9.x86_64 fmt-devel >= 6.2.1 is needed by ceph-2:19.2.3-0.el9.x86_64 fuse-devel is needed by ceph-2:19.2.3-0.el9.x86_64 gperf is needed by ceph-2:19.2.3-0.el9.x86_64 gperftools-devel >= 2.7.90 is needed by ceph-2:19.2.3-0.el9.x86_64 json-devel is needed by ceph-2:19.2.3-0.el9.x86_64 keyutils-libs-devel is needed by ceph-2:19.2.3-0.el9.x86_64 libaio-devel is needed by ceph-2:19.2.3-0.el9.x86_64 libarrow-devel is needed by ceph-2:19.2.3-0.el9.x86_64 libbabeltrace-devel is needed by ceph-2:19.2.3-0.el9.x86_64 libcap-devel is needed by ceph-2:19.2.3-0.el9.x86_64 libcap-ng-devel is needed by ceph-2:19.2.3-0.el9.x86_64 libcurl-devel is needed by ceph-2:19.2.3-0.el9.x86_64 libnbd-devel is needed by ceph-2:19.2.3-0.el9.x86_64 libnl3-devel is needed by ceph-2:19.2.3-0.el9.x86_64 liboath-devel is needed by ceph-2:19.2.3-0.el9.x86_64 libpmem-devel is needed by ceph-2:19.2.3-0.el9.x86_64 libpmemobj-devel >= 1.8 is needed by ceph-2:19.2.3-0.el9.x86_64 librabbitmq-devel is needed by ceph-2:19.2.3-0.el9.x86_64 librdkafka-devel is needed by ceph-2:19.2.3-0.el9.x86_64 lmdb-devel is needed by ceph-2:19.2.3-0.el9.x86_64 lttng-ust-devel is needed by ceph-2:19.2.3-0.el9.x86_64 lua-devel is needed by ceph-2:19.2.3-0.el9.x86_64 lz4-devel >= 1.7 is needed by ceph-2:19.2.3-0.el9.x86_64 nasm is needed by ceph-2:19.2.3-0.el9.x86_64 ndctl-devel >= 63 is needed by ceph-2:19.2.3-0.el9.x86_64 ninja-build is needed by ceph-2:19.2.3-0.el9.x86_64 nss-devel is needed by ceph-2:19.2.3-0.el9.x86_64 openldap-devel is needed by ceph-2:19.2.3-0.el9.x86_64 parquet-libs-devel is needed by ceph-2:19.2.3-0.el9.x86_64 pkgconfig(libudev) is needed by ceph-2:19.2.3-0.el9.x86_64 python3-sphinx is needed by ceph-2:19.2.3-0.el9.x86_64 qatlib-devel is needed by ceph-2:19.2.3-0.el9.x86_64 qatzip-devel is needed by ceph-2:19.2.3-0.el9.x86_64 re2-devel is needed by ceph-2:19.2.3-0.el9.x86_64 selinux-policy-devel is needed by ceph-2:19.2.3-0.el9.x86_64 snappy-devel is needed by ceph-2:19.2.3-0.el9.x86_64 thrift-devel >= 0.13.0 is needed by ceph-2:19.2.3-0.el9.x86_64 utf8proc-devel is needed by ceph-2:19.2.3-0.el9.x86_64 xfsprogs-devel is needed by ceph-2:19.2.3-0.el9.x86_64 xmlstarlet is needed by ceph-2:19.2.3-0.el9.x86_64 yaml-cpp-devel >= 0.6 is needed by ceph-2:19.2.3-0.el9.x86_64 Patrick Le 30/07/2025 à 09:09, Michel Jouvin a écrit :
Non CentOS is not exactly the same as RHEL or any derivatives. It is upstream, meaning it contains new things that will be in next RHEL or derivatives release. That's the issue with Ceph RPM packages. I don't know any workaround (except rebuilding from sources) but I am not an expert!
Michel Sent from my mobile Le 30 juillet 2025 05:51:33 gagan tiwari <gagan.tiwari@mathisys-india.com> a écrit :
Hi Michal, I am facing the same issue. Mine is fresh squid 19.2.3 installation on RockyLinux9.6. Rocky Linux is the same as Centos. So, please let me know how to fix it.
OS : - Rocky Linux release 9.6 (Blue Onyx)
Kernel :- 5.14.0-570.28.1.el9_6.x86_64
I need to install it at the earliest.
Thanks, Gagan
On Wed, Jul 30, 2025 at 1:02 AM Michel Jouvin <michel.jouvin@ijclab.in2p3.fr> wrote: Hi Moritz,
Your issue seems similar to the one reported last Spring with 18.2 7. The problem is that Ceph RPM are built against CentOS rather than RHEL or one of its derivatives. As CentOS is upstream to RHEL, the result is that RPMs sometimes require dependencies not yet released in last RHEL release...
Michel Sent from my mobile Le 29 juillet 2025 17:07:30 Moritz Baumann <mo@mo.homeip.net> a écrit :
I have problems upgrading ceph from
https://download.ceph.com/rpm-19.2.3/el9/x86_64/
and have broken dependencies on host running Almalinux 9.6
So:
ceph orch upgrade start --ceph_version 19.2.3
works, but a dnf --refresh upgrade on ceph nodes gives broken dependencies
ceph-poc1[0]:~# dnf --refresh upgrade isginf Extra Packages for 9 - x86_64 957 kB/s | 3.0 kB 00:00 AlmaLinux 9 - AppStream 12 kB/s | 4.2 kB 00:00 AlmaLinux 9 - BaseOS 10 kB/s | 3.8 kB 00:00 AlmaLinux 9 - CRB 12 kB/s | 4.2 kB 00:00 AlmaLinux 9 - Extras 9.7 kB/s | 3.8 kB 00:00 Ceph packages for x86_64 6.0 kB/s | 1.5 kB 00:00 Ceph noarch packages 5.9 kB/s | 1.5 kB 00:00 Ceph source packages 5.7 kB/s | 1.5 kB 00:00 Elastic repository for 8.x packages 83 kB/s | 1.5 kB 00:00 Extra Packages for Enterprise Linux 9 - x86_64 252 kB/s | 29 kB 00:00 Extra Packages for Enterprise Linux 9 openh264 (From Cisco) - x86_64 11 kB/s | 993 B 00:00 RPM Fusion for EL 9 - Free - Updates 40 kB/s | 8.3 kB 00:00 RPM Fusion for EL 9 - Nonfree - Updates 38 kB/s | 8.4 kB 00:00 SP CLIENT Repository ETHZ 323 kB/s | 3.0 kB 00:00 Error: Problem 1: cannot install the best update candidate for package ceph-common-2:19.2.2-0.el9.x86_64 - nothing provides libcrypto.so.3(OPENSSL_3.4.0)(64bit) needed by ceph-common-2:19.2.3-0.el9.x86_64 from Ceph Problem 2: cannot install the best update candidate for package librgw2-2:19.2.2-0.el9.x86_64 - nothing provides libcrypto.so.3(OPENSSL_3.4.0)(64bit) needed by librgw2-2:19.2.3-0.el9.x86_64 from Ceph Problem 3: package python3-rgw-2:19.2.3-0.el9.x86_64 from Ceph requires librgw2 = 2:19.2.3-0.el9, but none of the providers can be installed - cannot install the best update candidate for package python3-rgw-2:19.2.2-0.el9.x86_64 - nothing provides libcrypto.so.3(OPENSSL_3.4.0)(64bit) needed by librgw2-2:19.2.3-0.el9.x86_64 from Ceph Problem 4: package ceph-base-2:19.2.3-0.el9.x86_64 from Ceph requires librgw2 = 2:19.2.3-0.el9, but none of the providers can be installed - cannot install the best update candidate for package ceph-base-2:19.2.2-0.el9.x86_64 - nothing provides libcrypto.so.3(OPENSSL_3.4.0)(64bit) needed by librgw2-2:19.2.3-0.el9.x86_64 from Ceph Problem 5: package ceph-selinux-2:19.2.3-0.el9.x86_64 from Ceph requires ceph-base = 2:19.2.3-0.el9, but none of the providers can be installed - package ceph-base-2:19.2.3-0.el9.x86_64 from Ceph requires librgw2 = 2:19.2.3-0.el9, but none of the providers can be installed - cannot install the best update candidate for package ceph-selinux-2:19.2.2-0.el9.x86_64 - nothing provides libcrypto.so.3(OPENSSL_3.4.0)(64bit) needed by librgw2-2:19.2.3-0.el9.x86_64 from Ceph Problem 6: package librgw2-2:19.2.2-0.el9.x86_64 from @System requires librados2 = 2:19.2.2-0.el9, but none of the providers can be installed - cannot install both librados2-2:19.2.3-0.el9.x86_64 from Ceph and librados2-2:19.2.2-0.el9.x86_64 from @System - problem with installed package librgw2-2:19.2.2-0.el9.x86_64 - cannot install the best update candidate for package librados2-2:19.2.2-0.el9.x86_64 - nothing provides libcrypto.so.3(OPENSSL_3.4.0)(64bit) needed by librgw2-2:19.2.3-0.el9.x86_64 from Ceph Problem 7: package ceph-common-2:19.2.2-0.el9.x86_64 from @System requires libcephfs2 = 2:19.2.2-0.el9, but none of the providers can be installed - cannot install both libcephfs2-2:19.2.3-0.el9.x86_64 from Ceph and libcephfs2-2:19.2.2-0.el9.x86_64 from @System - problem with installed package ceph-common-2:19.2.2-0.el9.x86_64 - cannot install the best update candidate for package libcephfs2-2:19.2.2-0.el9.x86_64 - nothing provides libcrypto.so.3(OPENSSL_3.4.0)(64bit) needed by ceph-common-2:19.2.3-0.el9.x86_64 from Ceph Problem 8: package ceph-base-2:19.2.2-0.el9.x86_64 from @System requires librbd1 = 2:19.2.2-0.el9, but none of the providers can be installed - problem with installed package ceph-base-2:19.2.2-0.el9.x86_64 - cannot install both librbd1-2:19.2.3-0.el9.x86_64 from Ceph and librbd1-2:19.2.2-0.el9.x86_64 from @System - package ceph-base-2:19.2.3-0.el9.x86_64 from Ceph requires librgw2 = 2:19.2.3-0.el9, but none of the providers can be installed - cannot install the best update candidate for package librbd1-2:19.2.2-0.el9.x86_64 - nothing provides libcrypto.so.3(OPENSSL_3.4.0)(64bit) needed by librgw2-2:19.2.3-0.el9.x86_64 from Ceph Problem 9: package python3-rgw-2:19.2.2-0.el9.x86_64 from @System requires python3-rados = 2:19.2.2-0.el9, but none of the providers can be installed - problem with installed package python3-rgw-2:19.2.2-0.el9.x86_64 - cannot install both python3-rados-2:19.2.3-0.el9.x86_64 from Ceph and python3-rados-2:19.2.2-0.el9.x86_64 from @System - package python3-rgw-2:19.2.3-0.el9.x86_64 from Ceph requires librgw2 = 2:19.2.3-0.el9, but none of the providers can be installed - cannot install the best update candidate for package python3-rados-2:19.2.2-0.el9.x86_64 - nothing provides libcrypto.so.3(OPENSSL_3.4.0)(64bit) needed by librgw2-2:19.2.3-0.el9.x86_64 from Ceph Problem 10: package ceph-selinux-2:19.2.2-0.el9.x86_64 from @System requires ceph-base = 2:19.2.2-0.el9, but none of the providers can be installed - package ceph-base-2:19.2.2-0.el9.x86_64 from @System requires ceph-common = 2:19.2.2-0.el9, but none of the providers can be installed - problem with installed package ceph-selinux-2:19.2.2-0.el9.x86_64 - package ceph-common-2:19.2.2-0.el9.x86_64 from @System requires libradosstriper1 = 2:19.2.2-0.el9, but none of the providers can be installed - package ceph-selinux-2:19.2.3-0.el9.x86_64 from Ceph requires ceph-base = 2:19.2.3-0.el9, but none of the providers can be installed - cannot install both libradosstriper1-2:19.2.3-0.el9.x86_64 from Ceph and libradosstriper1-2:19.2.2-0.el9.x86_64 from @System - package ceph-base-2:19.2.3-0.el9.x86_64 from Ceph requires librgw2 = 2:19.2.3-0.el9, but none of the providers can be installed - cannot install the best update candidate for package libradosstriper1-2:19.2.2-0.el9.x86_64 - nothing provides libcrypto.so.3(OPENSSL_3.4.0)(64bit) needed by librgw2-2:19.2.3-0.el9.x86_64 from Ceph (try to add '--allowerasing' to command line to replace conflicting packages or '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)
Am 28.07.2025 um 16:59 schrieb Yuri Weinstein:
We're happy to announce the third backport release in the Squid series.
https://ceph.io/en/news/blog/2025/v19-2-3-squid-released/
Notable Changes
--------------- * RGW: PutObjectLockConfiguration can now be used to enable S3 Object Lock on an existing versioning-enabled bucket that was not created with Object Lock enabled. * RADOS: A new command, `ceph osd rm-pg-upmap-primary-all`, has been added that allows users to clear all pg-upmap-primary mappings in the osdmap when desired. Related trackers: - https://tracker.ceph.com/issues/67179 - https://tracker.ceph.com/issues/66867 * RBD: Moving an image that is a member of a group to trash is no longer allowed. `rbd trash mv` command now behaves the same way as `rbd rm` in this scenario. * MGR: MGR's always-on modules/plugins can now be force-disabled. This can be necessary in cases where MGR(s) needs to be prevented from being flooded by the module commands when corresponding Ceph service is down/degraded. * RGW: An authentication bypass vulnerability in STS [CVE-2023-43040] has been fixed. * RGW: S3 policy now enforces ARN-based conditionals. * RGW: Copying an object to itself no longer causes data loss. Potential corruption on ETIMEDOUT (not enabled by default), was also fixed.
Getting Ceph ------------ * Git at git://github.com/ceph/ceph.git * Tarball at https://download.ceph.com/tarballs/ceph-19.2.3.tar.gz * Containers at https://quay.io/repository/ceph/ceph * For packages, see https://docs.ceph.com/en/latest/install/get-packages/ * Release git sha1: c92aebb279828e9c3c1f5d24613efca272649e62 _______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io
ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io
_______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io
_______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io
Hi I am currently rebuilding as root with: # mkdir /root/rpms # mock -r alma+epel-9-x86_64 rebuild ceph-19.2.3-0.el9.src.rpm \ --target /root/rpms --define _smp_build_ncpus 4 and so far it seems to compile just fine. Best Mo On 7/30/25 11:10, Patrick Begou wrote:
And it looks quite difficult to build a new rpm from ceph-19.2.3-0.el9.src.rpm for RHEL9 OS. I just try in a VM in Almalinux 9 and many requirements are not met and some are not available.
I've just deployed Squid 19.2.2 on a fresh cluster based on Almalinux 9.6... 😕
rpmbuild --rebuild ceph-19.2.3-0.el9.src.rpm
Installing ceph-19.2.3-0.el9.src.rpm warning: ceph-19.2.3-0.el9.src.rpm: Header V4 RSA/SHA256 Signature, key ID 460f3994: NOKEY warning: user jenkins-build does not exist - using root warning: user jenkins-build does not exist - using root warning: extra tokens at the end of %else directive in line 118: %else # not fedora/rhel
warning: extra tokens at the end of %else directive in line 121: %else # not x86_64
warning: line 1136: It's not recommended to have unversioned Obsoletes: Obsoletes: ceph-libcephfs error: Failed build dependencies: CUnit-devel is needed by ceph-2:19.2.3-0.el9.x86_64 boost-random is needed by ceph-2:19.2.3-0.el9.x86_64 cryptsetup-devel is needed by ceph-2:19.2.3-0.el9.x86_64 daxctl-devel >= 63 is needed by ceph-2:19.2.3-0.el9.x86_64 expat-devel is needed by ceph-2:19.2.3-0.el9.x86_64 fmt-devel >= 6.2.1 is needed by ceph-2:19.2.3-0.el9.x86_64 fuse-devel is needed by ceph-2:19.2.3-0.el9.x86_64 gperf is needed by ceph-2:19.2.3-0.el9.x86_64 gperftools-devel >= 2.7.90 is needed by ceph-2:19.2.3-0.el9.x86_64 json-devel is needed by ceph-2:19.2.3-0.el9.x86_64 keyutils-libs-devel is needed by ceph-2:19.2.3-0.el9.x86_64 libaio-devel is needed by ceph-2:19.2.3-0.el9.x86_64 libarrow-devel is needed by ceph-2:19.2.3-0.el9.x86_64 libbabeltrace-devel is needed by ceph-2:19.2.3-0.el9.x86_64 libcap-devel is needed by ceph-2:19.2.3-0.el9.x86_64 libcap-ng-devel is needed by ceph-2:19.2.3-0.el9.x86_64 libcurl-devel is needed by ceph-2:19.2.3-0.el9.x86_64 libnbd-devel is needed by ceph-2:19.2.3-0.el9.x86_64 libnl3-devel is needed by ceph-2:19.2.3-0.el9.x86_64 liboath-devel is needed by ceph-2:19.2.3-0.el9.x86_64 libpmem-devel is needed by ceph-2:19.2.3-0.el9.x86_64 libpmemobj-devel >= 1.8 is needed by ceph-2:19.2.3-0.el9.x86_64 librabbitmq-devel is needed by ceph-2:19.2.3-0.el9.x86_64 librdkafka-devel is needed by ceph-2:19.2.3-0.el9.x86_64 lmdb-devel is needed by ceph-2:19.2.3-0.el9.x86_64 lttng-ust-devel is needed by ceph-2:19.2.3-0.el9.x86_64 lua-devel is needed by ceph-2:19.2.3-0.el9.x86_64 lz4-devel >= 1.7 is needed by ceph-2:19.2.3-0.el9.x86_64 nasm is needed by ceph-2:19.2.3-0.el9.x86_64 ndctl-devel >= 63 is needed by ceph-2:19.2.3-0.el9.x86_64 ninja-build is needed by ceph-2:19.2.3-0.el9.x86_64 nss-devel is needed by ceph-2:19.2.3-0.el9.x86_64 openldap-devel is needed by ceph-2:19.2.3-0.el9.x86_64 parquet-libs-devel is needed by ceph-2:19.2.3-0.el9.x86_64 pkgconfig(libudev) is needed by ceph-2:19.2.3-0.el9.x86_64 python3-sphinx is needed by ceph-2:19.2.3-0.el9.x86_64 qatlib-devel is needed by ceph-2:19.2.3-0.el9.x86_64 qatzip-devel is needed by ceph-2:19.2.3-0.el9.x86_64 re2-devel is needed by ceph-2:19.2.3-0.el9.x86_64 selinux-policy-devel is needed by ceph-2:19.2.3-0.el9.x86_64 snappy-devel is needed by ceph-2:19.2.3-0.el9.x86_64 thrift-devel >= 0.13.0 is needed by ceph-2:19.2.3-0.el9.x86_64 utf8proc-devel is needed by ceph-2:19.2.3-0.el9.x86_64 xfsprogs-devel is needed by ceph-2:19.2.3-0.el9.x86_64 xmlstarlet is needed by ceph-2:19.2.3-0.el9.x86_64 yaml-cpp-devel >= 0.6 is needed by ceph-2:19.2.3-0.el9.x86_64
Patrick
Le 30/07/2025 à 09:09, Michel Jouvin a écrit :
Non CentOS is not exactly the same as RHEL or any derivatives. It is upstream, meaning it contains new things that will be in next RHEL or derivatives release. That's the issue with Ceph RPM packages. I don't know any workaround (except rebuilding from sources) but I am not an expert!
Michel Sent from my mobile Le 30 juillet 2025 05:51:33 gagan tiwari <gagan.tiwari@mathisys- india.com> a écrit :
Hi Michal, I am facing the same issue. Mine is fresh squid 19.2.3 installation on RockyLinux9.6. Rocky Linux is the same as Centos. So, please let me know how to fix it.
OS : - Rocky Linux release 9.6 (Blue Onyx)
Kernel :- 5.14.0-570.28.1.el9_6.x86_64
I need to install it at the earliest.
Thanks, Gagan
On Wed, Jul 30, 2025 at 1:02 AM Michel Jouvin <michel.jouvin@ijclab.in2p3.fr> wrote: Hi Moritz,
Your issue seems similar to the one reported last Spring with 18.2 7. The problem is that Ceph RPM are built against CentOS rather than RHEL or one of its derivatives. As CentOS is upstream to RHEL, the result is that RPMs sometimes require dependencies not yet released in last RHEL release...
Michel Sent from my mobile Le 29 juillet 2025 17:07:30 Moritz Baumann <mo@mo.homeip.net> a écrit :
I have problems upgrading ceph from
https://download.ceph.com/rpm-19.2.3/el9/x86_64/
and have broken dependencies on host running Almalinux 9.6
So:
ceph orch upgrade start --ceph_version 19.2.3
works, but a dnf --refresh upgrade on ceph nodes gives broken dependencies
ceph-poc1[0]:~# dnf --refresh upgrade isginf Extra Packages for 9 - x86_64 957 kB/s | 3.0 kB 00:00 AlmaLinux 9 - AppStream 12 kB/s | 4.2 kB 00:00 AlmaLinux 9 - BaseOS 10 kB/s | 3.8 kB 00:00 AlmaLinux 9 - CRB 12 kB/s | 4.2 kB 00:00 AlmaLinux 9 - Extras 9.7 kB/s | 3.8 kB 00:00 Ceph packages for x86_64 6.0 kB/s | 1.5 kB 00:00 Ceph noarch packages 5.9 kB/s | 1.5 kB 00:00 Ceph source packages 5.7 kB/s | 1.5 kB 00:00 Elastic repository for 8.x packages 83 kB/s | 1.5 kB 00:00 Extra Packages for Enterprise Linux 9 - x86_64 252 kB/s | 29 kB 00:00 Extra Packages for Enterprise Linux 9 openh264 (From Cisco) - x86_64 11 kB/s | 993 B 00:00 RPM Fusion for EL 9 - Free - Updates 40 kB/s | 8.3 kB 00:00 RPM Fusion for EL 9 - Nonfree - Updates 38 kB/s | 8.4 kB 00:00 SP CLIENT Repository ETHZ 323 kB/s | 3.0 kB 00:00 Error: Problem 1: cannot install the best update candidate for package ceph-common-2:19.2.2-0.el9.x86_64 - nothing provides libcrypto.so.3(OPENSSL_3.4.0)(64bit) needed by ceph-common-2:19.2.3-0.el9.x86_64 from Ceph Problem 2: cannot install the best update candidate for package librgw2-2:19.2.2-0.el9.x86_64 - nothing provides libcrypto.so.3(OPENSSL_3.4.0)(64bit) needed by librgw2-2:19.2.3-0.el9.x86_64 from Ceph Problem 3: package python3-rgw-2:19.2.3-0.el9.x86_64 from Ceph requires librgw2 = 2:19.2.3-0.el9, but none of the providers can be installed - cannot install the best update candidate for package python3-rgw-2:19.2.2-0.el9.x86_64 - nothing provides libcrypto.so.3(OPENSSL_3.4.0)(64bit) needed by librgw2-2:19.2.3-0.el9.x86_64 from Ceph Problem 4: package ceph-base-2:19.2.3-0.el9.x86_64 from Ceph requires librgw2 = 2:19.2.3-0.el9, but none of the providers can be installed - cannot install the best update candidate for package ceph-base-2:19.2.2-0.el9.x86_64 - nothing provides libcrypto.so.3(OPENSSL_3.4.0)(64bit) needed by librgw2-2:19.2.3-0.el9.x86_64 from Ceph Problem 5: package ceph-selinux-2:19.2.3-0.el9.x86_64 from Ceph requires ceph-base = 2:19.2.3-0.el9, but none of the providers can be installed - package ceph-base-2:19.2.3-0.el9.x86_64 from Ceph requires librgw2 = 2:19.2.3-0.el9, but none of the providers can be installed - cannot install the best update candidate for package ceph-selinux-2:19.2.2-0.el9.x86_64 - nothing provides libcrypto.so.3(OPENSSL_3.4.0)(64bit) needed by librgw2-2:19.2.3-0.el9.x86_64 from Ceph Problem 6: package librgw2-2:19.2.2-0.el9.x86_64 from @System requires librados2 = 2:19.2.2-0.el9, but none of the providers can be installed - cannot install both librados2-2:19.2.3-0.el9.x86_64 from Ceph and librados2-2:19.2.2-0.el9.x86_64 from @System - problem with installed package librgw2-2:19.2.2-0.el9.x86_64 - cannot install the best update candidate for package librados2-2:19.2.2-0.el9.x86_64 - nothing provides libcrypto.so.3(OPENSSL_3.4.0)(64bit) needed by librgw2-2:19.2.3-0.el9.x86_64 from Ceph Problem 7: package ceph-common-2:19.2.2-0.el9.x86_64 from @System requires libcephfs2 = 2:19.2.2-0.el9, but none of the providers can be installed - cannot install both libcephfs2-2:19.2.3-0.el9.x86_64 from Ceph and libcephfs2-2:19.2.2-0.el9.x86_64 from @System - problem with installed package ceph-common-2:19.2.2-0.el9.x86_64 - cannot install the best update candidate for package libcephfs2-2:19.2.2-0.el9.x86_64 - nothing provides libcrypto.so.3(OPENSSL_3.4.0)(64bit) needed by ceph-common-2:19.2.3-0.el9.x86_64 from Ceph Problem 8: package ceph-base-2:19.2.2-0.el9.x86_64 from @System requires librbd1 = 2:19.2.2-0.el9, but none of the providers can be installed - problem with installed package ceph-base-2:19.2.2-0.el9.x86_64 - cannot install both librbd1-2:19.2.3-0.el9.x86_64 from Ceph and librbd1-2:19.2.2-0.el9.x86_64 from @System - package ceph-base-2:19.2.3-0.el9.x86_64 from Ceph requires librgw2 = 2:19.2.3-0.el9, but none of the providers can be installed - cannot install the best update candidate for package librbd1-2:19.2.2-0.el9.x86_64 - nothing provides libcrypto.so.3(OPENSSL_3.4.0)(64bit) needed by librgw2-2:19.2.3-0.el9.x86_64 from Ceph Problem 9: package python3-rgw-2:19.2.2-0.el9.x86_64 from @System requires python3-rados = 2:19.2.2-0.el9, but none of the providers can be installed - problem with installed package python3-rgw-2:19.2.2-0.el9.x86_64 - cannot install both python3-rados-2:19.2.3-0.el9.x86_64 from Ceph and python3-rados-2:19.2.2-0.el9.x86_64 from @System - package python3-rgw-2:19.2.3-0.el9.x86_64 from Ceph requires librgw2 = 2:19.2.3-0.el9, but none of the providers can be installed - cannot install the best update candidate for package python3-rados-2:19.2.2-0.el9.x86_64 - nothing provides libcrypto.so.3(OPENSSL_3.4.0)(64bit) needed by librgw2-2:19.2.3-0.el9.x86_64 from Ceph Problem 10: package ceph-selinux-2:19.2.2-0.el9.x86_64 from @System requires ceph-base = 2:19.2.2-0.el9, but none of the providers can be installed - package ceph-base-2:19.2.2-0.el9.x86_64 from @System requires ceph-common = 2:19.2.2-0.el9, but none of the providers can be installed - problem with installed package ceph-selinux-2:19.2.2-0.el9.x86_64 - package ceph-common-2:19.2.2-0.el9.x86_64 from @System requires libradosstriper1 = 2:19.2.2-0.el9, but none of the providers can be installed - package ceph-selinux-2:19.2.3-0.el9.x86_64 from Ceph requires ceph-base = 2:19.2.3-0.el9, but none of the providers can be installed - cannot install both libradosstriper1-2:19.2.3-0.el9.x86_64 from Ceph and libradosstriper1-2:19.2.2-0.el9.x86_64 from @System - package ceph-base-2:19.2.3-0.el9.x86_64 from Ceph requires librgw2 = 2:19.2.3-0.el9, but none of the providers can be installed - cannot install the best update candidate for package libradosstriper1-2:19.2.2-0.el9.x86_64 - nothing provides libcrypto.so.3(OPENSSL_3.4.0)(64bit) needed by librgw2-2:19.2.3-0.el9.x86_64 from Ceph (try to add '--allowerasing' to command line to replace conflicting packages or '--skip-broken' to skip uninstallable packages or '-- nobest' to use not only best candidate packages)
Am 28.07.2025 um 16:59 schrieb Yuri Weinstein:
We're happy to announce the third backport release in the Squid series.
https://ceph.io/en/news/blog/2025/v19-2-3-squid-released/
Notable Changes
--------------- * RGW: PutObjectLockConfiguration can now be used to enable S3 Object Lock on an existing versioning-enabled bucket that was not created with Object Lock enabled. * RADOS: A new command, `ceph osd rm-pg-upmap-primary-all`, has been added that allows users to clear all pg-upmap-primary mappings in the osdmap when desired. Related trackers: - https://tracker.ceph.com/issues/67179 - https://tracker.ceph.com/issues/66867 * RBD: Moving an image that is a member of a group to trash is no longer allowed. `rbd trash mv` command now behaves the same way as `rbd rm` in this scenario. * MGR: MGR's always-on modules/plugins can now be force-disabled. This can be necessary in cases where MGR(s) needs to be prevented from being flooded by the module commands when corresponding Ceph service is down/ degraded. * RGW: An authentication bypass vulnerability in STS [CVE-2023-43040] has been fixed. * RGW: S3 policy now enforces ARN-based conditionals. * RGW: Copying an object to itself no longer causes data loss. Potential corruption on ETIMEDOUT (not enabled by default), was also fixed.
Getting Ceph ------------ * Git at git://github.com/ceph/ceph.git * Tarball at https://download.ceph.com/tarballs/ceph-19.2.3.tar.gz * Containers at https://quay.io/repository/ceph/ceph * For packages, see https://docs.ceph.com/en/latest/install/get- packages/ * Release git sha1: c92aebb279828e9c3c1f5d24613efca272649e62 _______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io
ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io
_______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io
_______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io
_______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io
sorry pasted from a wrong try: This actually works: mock -r alma+epel-9-x86_64 rebuild ceph-19.2.3-0.el9.src.rpm \ --resultdir /root/rpmbuild/SRPMS \ --enable-network
Hi Moritz, I try it but it allocates a large amount of memory (30GB) in /var and it fails because no more space was available. I will have to study the man page of mock to possibly use another storage area, I was still using rpmbuild. I will have to force access to my local private repositories too, as servers do not have internet access. Patrick Le 31/07/2025 à 11:46, Moritz Baumann a écrit :
sorry pasted from a wrong try:
This actually works:
mock -r alma+epel-9-x86_64 rebuild ceph-19.2.3-0.el9.src.rpm \ --resultdir /root/rpmbuild/SRPMS \ --enable-network _______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io
Hi Patrick you do not have to build this on the servers directly. Actually I ran this mock command on my Fedora 42 Laptop since mock builds a proper buildroot (in a sort of chroot or systemd-nspawn thingy) environment in with the specified OS (you can find which options are availabled by looking into /etc/mock/). I think it should also build against rocky+epel9 so I will run this: # mock -r rocky+epel-9-x86_64 rebuild ceph-19.2.3-0.el9.src.rpm --resultdir /root/rpmbuild/RPMS --enable-network and let the people know if it builds without problems (But the build takes several hours). Best Mo Am 31.07.2025 um 15:53 schrieb Patrick Begou:
Hi Moritz,
I try it but it allocates a large amount of memory (30GB) in /var and it fails because no more space was available. I will have to study the man page of mock to possibly use another storage area, I was still using rpmbuild. I will have to force access to my local private repositories too, as servers do not have internet access.
Patrick
Le 31/07/2025 à 11:46, Moritz Baumann a écrit :
sorry pasted from a wrong try:
This actually works:
mock -r alma+epel-9-x86_64 rebuild ceph-19.2.3-0.el9.src.rpm \ --resultdir /root/rpmbuild/SRPMS \ --enable-network _______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io
_______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io
This also builds fine. Am 01.08.2025 um 10:53 schrieb Moritz Baumann:
Hi Patrick
you do not have to build this on the servers directly.
Actually I ran this mock command on my Fedora 42 Laptop since mock builds a proper buildroot (in a sort of chroot or systemd-nspawn thingy) environment in with the specified OS (you can find which options are availabled by looking into /etc/mock/).
I think it should also build against rocky+epel9 so I will run this:
# mock -r rocky+epel-9-x86_64 rebuild ceph-19.2.3-0.el9.src.rpm -- resultdir /root/rpmbuild/RPMS --enable-network
and let the people know if it builds without problems (But the build takes several hours).
Best Mo
Am 31.07.2025 um 15:53 schrieb Patrick Begou:
Hi Moritz,
I try it but it allocates a large amount of memory (30GB) in /var and it fails because no more space was available. I will have to study the man page of mock to possibly use another storage area, I was still using rpmbuild. I will have to force access to my local private repositories too, as servers do not have internet access.
Patrick
Le 31/07/2025 à 11:46, Moritz Baumann a écrit :
sorry pasted from a wrong try:
This actually works:
mock -r alma+epel-9-x86_64 rebuild ceph-19.2.3-0.el9.src.rpm \ --resultdir /root/rpmbuild/SRPMS \ --enable-network _______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io
_______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io
ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io
Hi, On Tue, Jul 29, 2025 at 8:06 AM Moritz Baumann <mo@mo.homeip.net> wrote:
I have problems upgrading ceph from
https://download.ceph.com/rpm-19.2.3/el9/x86_64/
and have broken dependencies on host running Almalinux 9.6
So:
ceph orch upgrade start --ceph_version 19.2.3
works, but a dnf --refresh upgrade on ceph nodes gives broken dependencies
ceph-poc1[0]:~# dnf --refresh upgrade ... Error: Problem 1: cannot install the best update candidate for package ceph-common-2:19.2.2-0.el9.x86_64 - nothing provides libcrypto.so.3(OPENSSL_3.4.0)(64bit) needed by ceph-common-2:19.2.3-0.el9.x86_64 from Ceph
Thanks for sharing this. The upstream build team is aware of this (and the same issue in reef) and actively are working on a path forward. It's unfortunate that Stream broke compatibility this way -- the team is testing the impact if we move to Rocky 9 going forward for reef/squid. One concern is if such a change might similarly break our Stream 9 users -- but... are there any Stream 9 users out there? Cheers, dan -- Dan van der Ster Ceph Executive Council | CTO @ CLYSO Try our Ceph Analyzer -- https://analyzer.clyso.com/ https://clyso.com | dan.vanderster@clyso.com
Hi Dan, I think it would be a good move. Now that CentOS Stream has been repurposed as a RHEL upstream instead of downstream as it was initially, it really makes sense. I would not expect any trouble for CS users as the backward compatibility is maintained in CS as un RHEL The problem that happened with recent Ceph rebuilds is because CS by design introduces things not yet present in RHEL releases and it's derivatives. Best regards, Michel Sent from my mobile Le 31 juillet 2025 18:34:32 Dan van der Ster <dan.vanderster@clyso.com> a écrit :
Hi,
On Tue, Jul 29, 2025 at 8:06 AM Moritz Baumann <mo@mo.homeip.net> wrote:
I have problems upgrading ceph from
https://download.ceph.com/rpm-19.2.3/el9/x86_64/
and have broken dependencies on host running Almalinux 9.6
So:
ceph orch upgrade start --ceph_version 19.2.3
works, but a dnf --refresh upgrade on ceph nodes gives broken dependencies
ceph-poc1[0]:~# dnf --refresh upgrade ... Error: Problem 1: cannot install the best update candidate for package ceph-common-2:19.2.2-0.el9.x86_64 - nothing provides libcrypto.so.3(OPENSSL_3.4.0)(64bit) needed by ceph-common-2:19.2.3-0.el9.x86_64 from Ceph
Thanks for sharing this. The upstream build team is aware of this (and the same issue in reef) and actively are working on a path forward. It's unfortunate that Stream broke compatibility this way -- the team is testing the impact if we move to Rocky 9 going forward for reef/squid.
One concern is if such a change might similarly break our Stream 9 users -- but... are there any Stream 9 users out there?
Cheers, dan
-- Dan van der Ster Ceph Executive Council | CTO @ CLYSO Try our Ceph Analyzer -- https://analyzer.clyso.com/ https://clyso.com | dan.vanderster@clyso.com _______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io
Hi Michel, and what about using Almalinux for your build ? In my mind Almalinux is closest to REHL as Rocky linux kernels are more advanced. Just to maximize the compatibility of the x86_64 rpm. Patrick Le 31/07/2025 à 22:31, Michel Jouvin a écrit :
Hi Dan,
I think it would be a good move. Now that CentOS Stream has been repurposed as a RHEL upstream instead of downstream as it was initially, it really makes sense. I would not expect any trouble for CS users as the backward compatibility is maintained in CS as un RHEL The problem that happened with recent Ceph rebuilds is because CS by design introduces things not yet present in RHEL releases and it's derivatives.
Best regards,
Michel Sent from my mobile Le 31 juillet 2025 18:34:32 Dan van der Ster <dan.vanderster@clyso.com> a écrit :
Hi,
On Tue, Jul 29, 2025 at 8:06 AM Moritz Baumann <mo@mo.homeip.net> wrote:
I have problems upgrading ceph from
https://download.ceph.com/rpm-19.2.3/el9/x86_64/
and have broken dependencies on host running Almalinux 9.6
So:
ceph orch upgrade start --ceph_version 19.2.3
works, but a dnf --refresh upgrade on ceph nodes gives broken dependencies
ceph-poc1[0]:~# dnf --refresh upgrade ... Error: Problem 1: cannot install the best update candidate for package ceph-common-2:19.2.2-0.el9.x86_64 - nothing provides libcrypto.so.3(OPENSSL_3.4.0)(64bit) needed by ceph-common-2:19.2.3-0.el9.x86_64 from Ceph
Thanks for sharing this. The upstream build team is aware of this (and the same issue in reef) and actively are working on a path forward. It's unfortunate that Stream broke compatibility this way -- the team is testing the impact if we move to Rocky 9 going forward for reef/squid.
One concern is if such a change might similarly break our Stream 9 users -- but... are there any Stream 9 users out there?
Cheers, dan
-- Dan van der Ster Ceph Executive Council | CTO @ CLYSO Try our Ceph Analyzer -- https://analyzer.clyso.com/ https://clyso.com | dan.vanderster@clyso.com _______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io
_______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io
Just as another consideration, AlmaLinux is targeting x86_64 v2, while other RHEL clones target v3. So, basing Ceph builds and containers on AlmaLinux will make containerized builds assembled from these RPMs more compatible with ancient hardware still found in labs, and with test clusters running on misconfigured third-party cloud hypervisors. On Fri, Aug 1, 2025 at 3:30 PM Patrick Begou < Patrick.Begou@univ-grenoble-alpes.fr> wrote:
Hi Michel,
and what about using Almalinux for your build ? In my mind Almalinux is closest to REHL as Rocky linux kernels are more advanced. Just to maximize the compatibility of the x86_64 rpm.
Patrick
Le 31/07/2025 à 22:31, Michel Jouvin a écrit :
Hi Dan,
I think it would be a good move. Now that CentOS Stream has been repurposed as a RHEL upstream instead of downstream as it was initially, it really makes sense. I would not expect any trouble for CS users as the backward compatibility is maintained in CS as un RHEL The problem that happened with recent Ceph rebuilds is because CS by design introduces things not yet present in RHEL releases and it's derivatives.
Best regards,
Michel Sent from my mobile Le 31 juillet 2025 18:34:32 Dan van der Ster <dan.vanderster@clyso.com> a écrit :
Hi,
On Tue, Jul 29, 2025 at 8:06 AM Moritz Baumann <mo@mo.homeip.net> wrote:
I have problems upgrading ceph from
https://download.ceph.com/rpm-19.2.3/el9/x86_64/
and have broken dependencies on host running Almalinux 9.6
So:
ceph orch upgrade start --ceph_version 19.2.3
works, but a dnf --refresh upgrade on ceph nodes gives broken dependencies
ceph-poc1[0]:~# dnf --refresh upgrade ... Error: Problem 1: cannot install the best update candidate for package ceph-common-2:19.2.2-0.el9.x86_64 - nothing provides libcrypto.so.3(OPENSSL_3.4.0)(64bit) needed by ceph-common-2:19.2.3-0.el9.x86_64 from Ceph
Thanks for sharing this. The upstream build team is aware of this (and the same issue in reef) and actively are working on a path forward. It's unfortunate that Stream broke compatibility this way -- the team is testing the impact if we move to Rocky 9 going forward for reef/squid.
One concern is if such a change might similarly break our Stream 9 users -- but... are there any Stream 9 users out there?
Cheers, dan
-- Dan van der Ster Ceph Executive Council | CTO @ CLYSO Try our Ceph Analyzer -- https://analyzer.clyso.com/ https://clyso.com | dan.vanderster@clyso.com _______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io
_______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io
_______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io
-- Alexander Patrakov
While it is true that Alma *also* addresses v2 it offers v3 as *default* as well. So I feel better with alma (because it allows me to run alma10 on older hardware if I pick the x86_64_v2 architecture). Am 01.08.2025 um 09:34 schrieb Alexander Patrakov:
Just as another consideration, AlmaLinux is targeting x86_64 v2, while other RHEL clones target v3. So, basing Ceph builds and containers on AlmaLinux will make containerized builds assembled from these RPMs more compatible with ancient hardware still found in labs, and with test clusters running on misconfigured third-party cloud hypervisors.
On Fri, Aug 1, 2025 at 3:30 PM Patrick Begou < Patrick.Begou@univ-grenoble-alpes.fr> wrote:
Hi Michel,
and what about using Almalinux for your build ? In my mind Almalinux is closest to REHL as Rocky linux kernels are more advanced. Just to maximize the compatibility of the x86_64 rpm.
Patrick
Le 31/07/2025 à 22:31, Michel Jouvin a écrit :
Hi Dan,
I think it would be a good move. Now that CentOS Stream has been repurposed as a RHEL upstream instead of downstream as it was initially, it really makes sense. I would not expect any trouble for CS users as the backward compatibility is maintained in CS as un RHEL The problem that happened with recent Ceph rebuilds is because CS by design introduces things not yet present in RHEL releases and it's derivatives.
Best regards,
Michel Sent from my mobile Le 31 juillet 2025 18:34:32 Dan van der Ster <dan.vanderster@clyso.com> a écrit :
Hi,
On Tue, Jul 29, 2025 at 8:06 AM Moritz Baumann <mo@mo.homeip.net> wrote:
I have problems upgrading ceph from
https://download.ceph.com/rpm-19.2.3/el9/x86_64/
and have broken dependencies on host running Almalinux 9.6
So:
ceph orch upgrade start --ceph_version 19.2.3
works, but a dnf --refresh upgrade on ceph nodes gives broken dependencies
ceph-poc1[0]:~# dnf --refresh upgrade ... Error: Problem 1: cannot install the best update candidate for package ceph-common-2:19.2.2-0.el9.x86_64 - nothing provides libcrypto.so.3(OPENSSL_3.4.0)(64bit) needed by ceph-common-2:19.2.3-0.el9.x86_64 from Ceph
Thanks for sharing this. The upstream build team is aware of this (and the same issue in reef) and actively are working on a path forward. It's unfortunate that Stream broke compatibility this way -- the team is testing the impact if we move to Rocky 9 going forward for reef/squid.
One concern is if such a change might similarly break our Stream 9 users -- but... are there any Stream 9 users out there?
Cheers, dan
-- Dan van der Ster Ceph Executive Council | CTO @ CLYSO Try our Ceph Analyzer -- https://analyzer.clyso.com/ https://clyso.com | dan.vanderster@clyso.com _______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io
_______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io
_______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io
Hi I just think it would be great to have under https://download.ceph.com/rpm-19.2.3/ the folders: el8/ el9/ (and this being build on rocky or alma) centos9-stream/ (renamed the el9) And with upcoming RHEL10 support maybe centos10-stream/ el10/ el10_v2/ At least when the mock build *just work*. Of course it would be tremendous effort to thoroughly test all platforms, but just running another mock is just a bit of time and disk space and would make the communities life much easier. Best Mo Am 01.08.2025 um 10:42 schrieb Moritz Baumann:
While it is true that Alma *also* addresses v2 it offers v3 as *default* as well.
So I feel better with alma (because it allows me to run alma10 on older hardware if I pick the x86_64_v2 architecture).
Am 01.08.2025 um 09:34 schrieb Alexander Patrakov:
Just as another consideration, AlmaLinux is targeting x86_64 v2, while other RHEL clones target v3. So, basing Ceph builds and containers on AlmaLinux will make containerized builds assembled from these RPMs more compatible with ancient hardware still found in labs, and with test clusters running on misconfigured third-party cloud hypervisors.
On Fri, Aug 1, 2025 at 3:30 PM Patrick Begou < Patrick.Begou@univ-grenoble-alpes.fr> wrote:
Hi Michel,
and what about using Almalinux for your build ? In my mind Almalinux is closest to REHL as Rocky linux kernels are more advanced. Just to maximize the compatibility of the x86_64 rpm.
Patrick
Le 31/07/2025 à 22:31, Michel Jouvin a écrit :
Hi Dan,
I think it would be a good move. Now that CentOS Stream has been repurposed as a RHEL upstream instead of downstream as it was initially, it really makes sense. I would not expect any trouble for CS users as the backward compatibility is maintained in CS as un RHEL The problem that happened with recent Ceph rebuilds is because CS by design introduces things not yet present in RHEL releases and it's derivatives.
Best regards,
Michel Sent from my mobile Le 31 juillet 2025 18:34:32 Dan van der Ster <dan.vanderster@clyso.com> a écrit :
Hi,
On Tue, Jul 29, 2025 at 8:06 AM Moritz Baumann <mo@mo.homeip.net> wrote:
I have problems upgrading ceph from
https://download.ceph.com/rpm-19.2.3/el9/x86_64/
and have broken dependencies on host running Almalinux 9.6
So:
ceph orch upgrade start --ceph_version 19.2.3
works, but a dnf --refresh upgrade on ceph nodes gives broken dependencies
ceph-poc1[0]:~# dnf --refresh upgrade ... Error: Problem 1: cannot install the best update candidate for package ceph-common-2:19.2.2-0.el9.x86_64 - nothing provides libcrypto.so.3(OPENSSL_3.4.0)(64bit) needed by ceph-common-2:19.2.3-0.el9.x86_64 from Ceph
Thanks for sharing this. The upstream build team is aware of this (and the same issue in reef) and actively are working on a path forward. It's unfortunate that Stream broke compatibility this way -- the team is testing the impact if we move to Rocky 9 going forward for reef/squid.
One concern is if such a change might similarly break our Stream 9 users -- but... are there any Stream 9 users out there?
Cheers, dan
-- Dan van der Ster Ceph Executive Council | CTO @ CLYSO Try our Ceph Analyzer -- https://analyzer.clyso.com/ https://clyso.com | dan.vanderster@clyso.com _______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io
_______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io
_______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io
_______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io
I fully agree with Alma as the choice for a multitude of reasons. Even Arista uses AlmaLinux for their EOS-based products. The fact it's run by a 501(c) non-profit unlike Rocky is a pretty good reason to go that route, as we've already dealt with one major headache related to a for-profit changing direction. Cheers, David On Fri, Aug 1, 2025, at 02:34, Alexander Patrakov wrote:
Just as another consideration, AlmaLinux is targeting x86_64 v2, while other RHEL clones target v3. So, basing Ceph builds and containers on AlmaLinux will make containerized builds assembled from these RPMs more compatible with ancient hardware still found in labs, and with test clusters running on misconfigured third-party cloud hypervisors.
On Fri, Aug 1, 2025 at 3:30 PM Patrick Begou < Patrick.Begou@univ-grenoble-alpes.fr> wrote:
Hi Michel,
and what about using Almalinux for your build ? In my mind Almalinux is closest to REHL as Rocky linux kernels are more advanced. Just to maximize the compatibility of the x86_64 rpm.
Patrick
Le 31/07/2025 à 22:31, Michel Jouvin a écrit :
Hi Dan,
I think it would be a good move. Now that CentOS Stream has been repurposed as a RHEL upstream instead of downstream as it was initially, it really makes sense. I would not expect any trouble for CS users as the backward compatibility is maintained in CS as un RHEL The problem that happened with recent Ceph rebuilds is because CS by design introduces things not yet present in RHEL releases and it's derivatives.
Best regards,
Michel Sent from my mobile Le 31 juillet 2025 18:34:32 Dan van der Ster <dan.vanderster@clyso.com> a écrit :
Hi,
On Tue, Jul 29, 2025 at 8:06 AM Moritz Baumann <mo@mo.homeip.net> wrote:
I have problems upgrading ceph from
https://download.ceph.com/rpm-19.2.3/el9/x86_64/
and have broken dependencies on host running Almalinux 9.6
So:
ceph orch upgrade start --ceph_version 19.2.3
works, but a dnf --refresh upgrade on ceph nodes gives broken dependencies
ceph-poc1[0]:~# dnf --refresh upgrade ... Error: Problem 1: cannot install the best update candidate for package ceph-common-2:19.2.2-0.el9.x86_64 - nothing provides libcrypto.so.3(OPENSSL_3.4.0)(64bit) needed by ceph-common-2:19.2.3-0.el9.x86_64 from Ceph
Thanks for sharing this. The upstream build team is aware of this (and the same issue in reef) and actively are working on a path forward. It's unfortunate that Stream broke compatibility this way -- the team is testing the impact if we move to Rocky 9 going forward for reef/squid.
One concern is if such a change might similarly break our Stream 9 users -- but... are there any Stream 9 users out there?
Cheers, dan
-- Dan van der Ster Ceph Executive Council | CTO @ CLYSO Try our Ceph Analyzer -- https://analyzer.clyso.com/ https://clyso.com | dan.vanderster@clyso.com _______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io
_______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io
_______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io
-- Alexander Patrakov _______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io
On 31/07/2025 17:32, Dan van der Ster wrote:
One concern is if such a change might similarly break our Stream 9 users -- but... are there any Stream 9 users out there?
There certainly are Stream 9 users out there. We originally started (back in Nautilus days) using Debian, but eventually abandoned it when we found that dysfunctional Debian packages were being published, and were told they weren't even tested at all before release. And, fair enough, the OS compatibility matrix we were pointed to showed Debian as category C. We made the decision to migrate all Ceph clusters to Centos 9, as this was Category A. It was a non-trivial task, especially as we didn't have Centos of any version on the estate. But, with a couple of minor exceptions, it has been very reliable since (now on Squid). For those of us not using cephadm (here is not the place to go into all the reasons why) it is important that we have reasonably stable distribution support. The current situation where there is one rpm-based and one deb-based distribution in the top tier seems quite reasonable. But please, please.... do not consider dropping a Category A distribution without very good reason.
Cheers, dan
-- Dan van der Ster Ceph Executive Council | CTO @ CLYSO Try our Ceph Analyzer -- https://analyzer.clyso.com/ https://clyso.com | dan.vanderster@clyso.com _______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io
Hi, 2025年7月29日(火) 0:00 Yuri Weinstein <yweinste@redhat.com>:
We're happy to announce the third backport release in the Squid series.
I discovered the following regression in this release: squid: s3 DeleteBucketLifecycle does not delete lifecycle config https://tracker.ceph.com/issues/71544 As a user of bucket lifecycle, I would like to know if there is a possibility of releasing a hotfix or if there is any workaround available. Thanks, Satoru
Notable Changes
--------------- * RGW: PutObjectLockConfiguration can now be used to enable S3 Object Lock on an existing versioning-enabled bucket that was not created with Object Lock enabled. * RADOS: A new command, `ceph osd rm-pg-upmap-primary-all`, has been added that allows users to clear all pg-upmap-primary mappings in the osdmap when desired. Related trackers: - https://tracker.ceph.com/issues/67179 - https://tracker.ceph.com/issues/66867 * RBD: Moving an image that is a member of a group to trash is no longer allowed. `rbd trash mv` command now behaves the same way as `rbd rm` in this scenario. * MGR: MGR's always-on modules/plugins can now be force-disabled. This can be necessary in cases where MGR(s) needs to be prevented from being flooded by the module commands when corresponding Ceph service is down/degraded. * RGW: An authentication bypass vulnerability in STS [CVE-2023-43040] has been fixed. * RGW: S3 policy now enforces ARN-based conditionals. * RGW: Copying an object to itself no longer causes data loss. Potential corruption on ETIMEDOUT (not enabled by default), was also fixed.
Getting Ceph ------------ * Git at git://github.com/ceph/ceph.git * Tarball at https://download.ceph.com/tarballs/ceph-19.2.3.tar.gz * Containers at https://quay.io/repository/ceph/ceph * For packages, see https://docs.ceph.com/en/latest/install/get-packages/ * Release git sha1: c92aebb279828e9c3c1f5d24613efca272649e62 _______________________________________________ ceph-users mailing list -- ceph-users@ceph.io To unsubscribe send an email to ceph-users-leave@ceph.io
participants (11)
-
Alexander Patrakov
-
Chris Palmer
-
Dan van der Ster
-
David Orman
-
gagan tiwari
-
Konstantin Shalygin
-
Michel Jouvin
-
Moritz Baumann
-
Patrick Begou
-
Satoru Takeuchi
-
Yuri Weinstein