Bật EPEL và CRB trên Rocky Linux, AlmaLinux

Vì sao dnf không tìm thấy package bạn cần

EPEL và CRB là hai repository không được bật sẵn trên server Rocky Linux hoặc AlmaLinux mới cài. Vì vậy, dnf install htop trên một máy mới sẽ trả về No match for argument: htop rồi Error: Unable to find a match: htop. Không có gì bị hỏng và không có mirror nào ngừng hoạt động. Bản phân phối cơ sở cố ý chỉ cung cấp một tập package nhỏ. CRB đã có sẵn nhưng đang bị tắt. EPEL là một community repository riêng mà bạn phải thêm vào.

Trên Ubuntu, package tương tự nằm trong universe, còn universe được bật trên gần như mọi cloud image nên vấn đề này không xuất hiện. Họ Red Hat phân chia package theo cách khác và mặc định cung cấp ít package hơn. Cách sửa gồm 3 lệnh. Phần còn lại của hướng dẫn này là điều thường không ai nói với bạn trong tuần đầu tiên: các repository đó cam kết cung cấp gì, không cam kết cung cấp gì và cách ngăn một third-party repository âm thầm chiếm quyền ưu tiên trên base system.

Cách kiểm tra các lệnh này. Các container kiểm thử lệnh của chúng tôi chỉ chạy Ubuntu, nên các lệnh dnf bên dưới chưa được thực thi trên máy kiểm thử của chúng tôi. Các lệnh này tuân theo tài liệu Rocky Linux và AlmaLinux. Mỗi bước đều nêu output bạn cần thấy. Vì vậy, hãy kiểm tra từng bước trên server của bạn thay vì dán cả block cùng lúc.

BaseOS, AppStream và CRB là gì?

BaseOS là chính hệ điều hành: kernel, glibc, systemd và userland cốt lõi. Các phiên bản trong đây hiếm khi thay đổi trong vòng đời của major release. Hầu hết bản sửa lỗi, bao gồm cả bản sửa lỗi bảo mật, được backport vào phiên bản bạn đang dùng. Tuy nhiên, một minor release đôi khi rebase một thành phần cốt lõi lên phiên bản upstream mới hơn. Ví dụ, AlmaLinux 9.2 đã cập nhật các gói user-space của SELinux lên phiên bản 3.5. Một số phiên bản trông có vẻ đã cũ nhiều năm trong BaseOS không có nghĩa là gói đó chưa được vá. Đó là phiên bản cũ đã được vá, đúng với mục đích của một enterprise distribution.

AppStream chứa các thành phần bạn chạy trên hệ điều hành: web server, database, language runtime, editor và monitoring agent. Ở version 8, phần lớn AppStream được cung cấp dưới dạng module với các stream thay thế, vì vậy dnf module list có vai trò quan trọng và bạn phải chọn, chẳng hạn, một PHP stream. Version 9 cung cấp phiên bản mặc định của từng ứng dụng dưới dạng plain package. Vì vậy, trên Rocky 9 và Alma 9, một dnf install thông thường sẽ cung cấp phiên bản đó mà không cần enable module trước. Các phiên bản thay thế vẫn được cung cấp dưới dạng module stream. RHEL 9 ghi nhận PHP 8.0 là gói php thông thường, còn PHP 8.1 và 8.2 là các stream php:8.1 và php:8.2. AlmaLinux 9.8 cũng đã bổ sung các stream mới như MariaDB 11.8, PostgreSQL 18 và Ruby 4.0. Nếu cần phiên bản khác với phiên bản mặc định, dnf module list vẫn có vai trò trên version 9.

Extras được enable mặc định và có quy mô rất nhỏ. Nó chủ yếu chứa các release package cho những repository khác. Đây là nơi epel-release được cung cấp. Chi tiết này giải thích tại sao bạn không bao giờ cần tin tưởng một URL ngẫu nhiên để cài EPEL trên Rocky hoặc Alma.

CRB là repository CodeReady Builder, được gọi là PowerTools trên version 8. Nó chứa phần build của distribution: development header, static library, cùng các công cụ test và documentation mà package cần trong thời gian build. Repository này đã có trên mirror nhưng bị disable mặc định. Trên sản phẩm của Red Hat, cùng nội dung đó được gọi là CodeReady Linux Builder. Nó đi kèm subscription, và Red Hat nêu rõ rằng nội dung này không thuộc phạm vi support. Rocky và Alma kế thừa cả nội dung lẫn thiết lập disable mặc định này.

Với những bạn chuyển sang từ Debian hoặc Ubuntu: main gộp các runtime package và -dev header trong cùng một archive, nên không có CRB để enable ở đó. Thành phần gần tương đương với EPEL là universe. Thành phần này do cộng đồng duy trì và không có cam kết support từ vendor.

EPEL là gì và ai đứng sau dự án này

EPEL là viết tắt của Extra Packages for Enterprise Linux. Đây là một dự án của Fedora: các package có trong Fedora được build lại cho bản enterprise hiện tại và do EPEL Special Interest Group duy trì. Nhóm này chủ yếu gồm các tình nguyện viên trong cộng đồng Fedora. Red Hat cung cấp hạ tầng build và mirror, đồng thời một số kỹ sư Red Hat cũng duy trì package trong đó. Quan hệ chỉ dừng ở đó. EPEL không phải là sản phẩm của Red Hat. Không có hợp đồng hỗ trợ và cũng không có SLA (service level agreement) cho package EPEL trên RHEL hoặc bản rebuild.

Một chính sách giúp EPEL an toàn để enable là: package EPEL không được thay thế package của bản phân phối cơ sở. Nếu AppStream cung cấp nginx thì EPEL sẽ không cung cấp package đó. Quy tắc này do những người review package EPEL thực thi, nên chỉ là cam kết của EPEL. Quy tắc này không bảo vệ bạn khỏi bất kỳ repository nào khác mà bạn thêm vào sau đó.

Cam kết về vòng đời của EPEL cũng khác bản phân phối cơ sở. Đây là vấn đề thường phát sinh vào năm thứ ba. Package BaseOS thường giữ nguyên version trong toàn bộ vòng đời 10 năm của bản major release, với các bản sửa lỗi được backport vào package và chỉ thỉnh thoảng có rebase có chủ đích. Maintainer của EPEL chỉ cam kết một khoảng thời gian ngắn hơn nhiều: đề xuất về vòng đời package theo release của EPEL quy định thời gian này là ít nhất một minor release của RHEL hoặc 13 tháng, tùy mốc nào ngắn hơn. Trên thực tế, phần lớn package được duy trì lâu hơn thời hạn này. Một số package bị retire khi maintainer không còn tiếp tục duy trì. Một số package chuyển sang major version mới ngay giữa vòng đời của distro vì EPEL đi theo Fedora. Vì vậy, một lần dnf upgrade thông thường có thể cài cho bạn major version mới của một công cụ EPEL trên máy mà bạn nghĩ là đang ổn định. Package mà bạn phụ thuộc cũng có thể ngừng nhận update mà không có thông báo nào đến được với bạn. Version mới cũng không có hiệu lực trong service đang chạy, nên needs-restarting cho biết process nào vẫn đang dùng binary cũ sau khi transaction hoàn tất.

Còn một hệ quả bạn nên biết trước khi enable EPEL: EPEL không được build cho minor release cũ hơn mà bạn có thể đang giữ trên server. Chính sách EPEL của Fedora build minor version EPEL 10 mới nhất dựa trên CentOS Stream 10, còn các minor version EPEL 10 cũ hơn dựa trên các minor release RHEL 10 cụ thể. EPEL 8 và 9 cũng có định nghĩa target riêng. Nếu bạn giữ server ở một minor release cũ bằng frozen mirror hoặc repository vendor point release, package EPEL có thể yêu cầu base library mới hơn version đang có trên máy. dnf báo lỗi này là thiếu dependency. Lỗi trông giống vấn đề với mirror, nhưng thực chất là vấn đề lệch version.

Bật CRB và cài EPEL trên Rocky hoặc Alma

sudo dnf install -y dnf-plugins-core
sudo dnf config-manager --set-enabled crb
sudo dnf install -y epel-release
sudo dnf makecache
dnf repolist --enabled

dnf repolist --enabled hiện phải liệt kê baseos, appstream, extras, crb và epel. Bạn cũng có thể thấy một mục epel-cisco-openh264 nhỏ do epel-release thêm vào. Nếu crb không có trong danh sách đó, bước bật repository chưa có hiệu lực. Phần tiếp theo giải thích lý do.

Trên Rocky 8 và Alma 8, repository này vẫn có tên là PowerTools, nên lệnh ở giữa sẽ trở thành sudo dnf config-manager --set-enabled powertools. Repository id phân biệt chữ hoa chữ thường. Tài liệu CentOS 8 cũ viết là PowerTools với chữ hoa, nên sẽ không khớp. Trên AlmaLinux 10, repository CRB được bật mặc định từ 10.0 trở đi (thay đổi vào tháng 9 năm 2025), nên bạn chỉ cần thực hiện bước epel-release.

epel-release đến từ extras, vốn đã được bật, nên không cần xác minh URL hay tự import key. Gói này ghi /etc/yum.repos.d/epel.repo và cài signing key của EPEL vào /etc/pki/rpm-gpg/. Xác nhận gpgcheck=1 trong file đó và bỏ qua mọi hướng dẫn yêu cầu dùng --nogpgcheck để xử lý lỗi chữ ký. Kiểm tra chữ ký thất bại nghĩa là gói không đúng như nội dung nó khai báo hoặc đồng hồ hệ thống của bạn bị sai.

Trên Rocky, epel-release cũng cài một helper nhỏ tại /usr/bin/crb, nên sudo crb enable và crb status thực hiện cùng công việc mà không cần plugin. Kiểm tra hệ thống có helper này bằng command -v crb trước khi dùng, vì nó không có trên mọi nhánh của mọi bản rebuild.

Để xác nhận EPEL có thể truy cập được thay vì chỉ được liệt kê, hãy yêu cầu repository này tìm một gói chỉ có EPEL cung cấp:

dnf repoquery --repo=epel htop

Lệnh đó in ra tên gói, phiên bản và kiến trúc. Không có đầu ra nghĩa là repository đã được bật nhưng không trả về dữ liệu. Đây thường là vấn đề mirror hoặc metadata, không phải vấn đề cấu hình, nên tiếp theo hãy thử sudo dnf clean all && sudo dnf makecache.

Vì sao dnf báo không có lệnh: config-manager

Đây là lỗi đầu tiên nhiều người gặp phải. Lỗi này thường xảy ra trên đúng các image mà nhà cung cấp VPS cấp sẵn.

No such command: config-manager. Please use /usr/bin/dnf --help
It could be a DNF plugin command, try: "dnf install 'dnf-command(config-manager)'"

config-manager là một plugin, không phải subcommand tích hợp sẵn của dnf. Plugin này nằm trong dnf-plugins-core. Bản cài server đầy đủ thường cài gói đó, còn các minimal image, cloud image và container image thì không. Gợi ý của chính dnf hoạt động vì package này khai báo virtual capability đó:

sudo dnf install -y 'dnf-command(config-manager)'

Hãy đặt nó trong dấu ngoặc kép. Dấu ngoặc đơn là cú pháp của shell, nên nếu không đặt trong dấu ngoặc kép, lệnh sẽ lỗi cú pháp thay vì báo lỗi từ dnf.

Nếu không thể cài plugin vì repository cần dùng đang bị disable, hãy sửa file trực tiếp. Tìm file chứa section đó, mở file và đặt enabled=1 bên dưới [crb]:

grep -rl crb /etc/yum.repos.d/

Đó chính xác là nội dung config-manager ghi vào, nên sửa thủ công không làm mất cấu hình nào. dnf repolist --enabled xác nhận kết quả.

Một số package EPEL sẽ không cài được nếu chưa bật CRB

Lỗi phổ biến thứ hai không nhắc đến CRB. Một package EPEL liên kết với thư viện chỉ có trong CRB sẽ thất bại khi phân giải dependency. Thông báo lỗi sẽ nêu tên thư viện và package cần thư viện đó:

Error:
 Problem: conflicting requests
  - nothing provides libexample.so.0()(64bit) needed by examplepkg-1.4-2.el9.x86_64 from epel

Nguyên nhân là CRB đang bị tắt, nên dnf không thể thấy repository duy nhất cung cấp thư viện đó. Kiểm tra lần lượt hai điều sau:

dnf repolist --enabled
dnf --enablerepo=crb repoquery --whatprovides 'libexample.so.0()(64bit)'

Nếu lệnh thứ hai hiển thị tên một package nhưng lệnh cài đặt thông thường vẫn thất bại, CRB đang bị tắt. Loại lỗi này đủ phổ biến để AlmaLinux bật CRB theo mặc định từ version 10 nhằm ngăn lỗi xảy ra. --enablerepo=crb cũng dùng được như một flag một lần cho một lệnh cài đặt riêng, nhưng hãy để CRB luôn được bật nếu bạn sử dụng EPEL, vì bản cập nhật EPEL tiếp theo có thể kéo theo dependency mới từ CRB mà không cảnh báo trước.

Gói này đến từ repository nào?

Sau vài tuần bật bốn repository, câu hỏi hữu ích không còn là đang cài gì mà là gói đó đến từ đâu.

dnf repolist --all
dnf info htop
dnf repoquery --installed --qf '%{from_repo} %{name}' | sort | uniq -c | sort -rn
dnf repository-packages epel list installed

dnf info trên một package đã cài sẽ in ra một dòng From repo. dnf list installed hiển thị cùng thông tin trong cột thứ ba, có thêm @ ở phía trước. Vì vậy, @epel nghĩa là package được cài từ EPEL, còn @System nghĩa là dnf không biết package đến từ đâu. Trường hợp này thường xảy ra khi ai đó chạy rpm -i trên một file đã tải xuống. Dòng repoquery hiển thị số lượng package theo từng repository. Đây là cách nhanh nhất để phát hiện một server được thừa hưởng có 40 package từ một repository mà bạn chưa từng nghe đến. Lệnh cuối cùng liệt kê chính xác những gì một repository đã cung cấp cho bạn. Bạn cần inventory này trước khi quyết định gỡ repository đó.

Thói quen tương đương bên apt là apt-cache policy <package>. Bạn nên mở bảng tương đương lệnh dnf và apt trong tab thứ hai trong tháng đầu tiên. Các khái niệm tương ứng rõ ràng dù các flag không giống nhau.

Làm thế nào để ngăn repo bên thứ ba thay thế package của hệ thống?

EPEL cam kết không làm việc này. Không có repo nào khác cam kết như vậy. Repo của vendor cho database, agent hoặc language runtime có thể cung cấp bản build riêng của một library mà BaseOS cũng cung cấp, và dnf sẽ cài bản đó vì quy tắc mặc định của dnf rất đơn giản: phiên bản cao nhất sẽ thắng, bất kể đến từ repo nào.

Hai cơ chế kiểm soát xử lý phần lớn vấn đề này. Cả hai đều nằm trong file repo tại /etc/yum.repos.d/.

priority= quyết định repo nào thắng khi có nhiều repo cùng cung cấp một package name. Số thấp hơn sẽ thắng và giá trị mặc định là 99, nên hãy đặt số thấp cho các repo hệ thống và số cao cho mọi repo bên thứ ba. Khi đó dnf sẽ chọn package hệ thống ngay cả khi phiên bản từ bên thứ ba mới hơn. Các bản dnf hiện đại tự xử lý việc này, nên package riêng yum-plugin-priorities từ thời CentOS 7 không còn là một phần của giải pháp.

includepkgs= là tùy chọn lọc mạnh hơn. excludepkgs= chặn các package được nêu tên khỏi một repo, nên bạn phải dự đoán repo đó có thể cung cấp những package nào. includepkgs= đảo ngược cơ chế này: repo chỉ được phép cung cấp các package name này và không được cung cấp gì khác. Với repo của vendor chỉ nên cung cấp agent của chính vendor, bạn chỉ cần một dòng cấu hình.

[vendor-tools]
name=Vendor tools for EL9
baseurl=https://packages.example.com/el9/x86_64/
enabled=1
gpgcheck=1
gpgkey=https://packages.example.com/RPM-GPG-KEY-vendor
priority=90
includepkgs=vendor-agent,vendor-agent-plugins

Trên version 8 còn một setting cần biết. Một package từ repo bên thứ ba có thể bị ẩn khi một AppStream module cung cấp cùng package name. module_hotfixes=1 trong section của repo đó yêu cầu dnf ngừng lọc package này. Nếu một package chắc chắn có trong repo của vendor nhưng bị báo là không tồn tại hoặc không cài được trên máy chạy version 8, đây thường là nguyên nhân: modular filtering khiến package vô hình với phần lớn lệnh dnf thay vì báo conflict. Version 9 có ít module hơn nhưng vẫn cung cấp module stream, nên cơ chế lọc tương tự vẫn có thể áp dụng khi package của vendor trùng package name với một module.

Để ghim một package vào một version cụ thể, hãy cài python3-dnf-plugin-versionlock rồi dùng sudo dnf versionlock add <package>. Cách này tương đương với apt-mark hold. Lưu ý một điểm ngược với Debian: trong apt, Pin-Priority cao hơn sẽ thắng; trong dnf, priority thấp hơn sẽ thắng.

Vì sao trộn các repository gần với RHEL khiến server không thể nâng cấp

Rocky, Alma, CentOS Stream, Oracle Linux và RHEL đủ tương đồng để package của bản này có thể cài trên bản kia, nhưng cũng đủ khác biệt để kết quả không còn là một hệ thống mà bất kỳ bên nào có thể hỗ trợ. Lý do chúng tương đồng đến mức đó, và vì sao Stream hiện nằm trước RHEL thay vì song song với RHEL, được giải thích trong câu chuyện Red Hat Linux tách thành Fedora và RHEL, cùng những gì xảy ra với CentOS.

Cơ chế nằm ở số phiên bản. CentOS Stream 9 đi trước RHEL 9, và Red Hat mô tả code của Stream là nền tảng trở thành bản minor release tiếp theo của RHEL. Nếu trỏ một máy Rocky 9 vào repository của Stream, dù chỉ một lần hoặc chỉ để cài một package, bạn sẽ có các package với phiên bản cao hơn phiên bản Rocky đang cung cấp. Bản Rocky minor release sau đó có thể bắt kịp, nhưng không có gì đảm bảo nó cung cấp package đó ở phiên bản bằng hoặc cao hơn phiên bản bạn đang có. Cho đến khi điều đó xảy ra, dnf upgrade sẽ không xử lý package này. Máy lúc đó chạy một tổ hợp mà không ai kiểm thử, và có thể âm thầm duy trì trạng thái đó trong nhiều năm trong khi bạn vẫn nghĩ nó đã được cập nhật bản vá.

Dấu hiệu là dnf upgrade không báo có gì cần thực hiện, trong khi sudo dnf distro-sync đề xuất downgrade một danh sách dài package. distro-sync là công cụ sửa lỗi: nó buộc mọi package đã cài khớp với những gì các repository đang bật thực sự cung cấp, bao gồm cả downgrade. Trước tiên, hãy disable repository không cùng bản phân phối. Sau đó chạy công cụ và đọc danh sách được đề xuất trước khi chấp nhận. Việc sửa lỗi sẽ thất bại nếu RPM phiên bản cũ không còn trên mirror. Khi đó, dựng lại server từ image sạch sẽ nhanh và an toàn hơn việc cố xử lý dependency solver.

Các phần còn sót lại của ELevate là một biến thể phổ biến khác của vấn đề này. ELevate là công cụ migration của AlmaLinux, xây dựng trên Leapp, dùng để nâng một máy CentOS 7 lên bản mới hơn hoặc chuyển đổi giữa các bản rebuild. Một lần migration thực hiện vội có thể để lại file repository EL7 trong /etc/yum.repos.d/ và các package EL7 vẫn còn được cài. Tìm chúng bằng rpm -qa | grep el7. Mỗi package như vậy là một package mà không repository nào đang bật có thể cập nhật. Lần chạy Leapp sau đó sẽ báo chúng là các package không thể ánh xạ, trở thành blocker cho quá trình upgrade và buộc bạn phải xử lý thủ công. Hãy dọn chúng khi server vẫn đang ổn định, không phải vào ngày bạn cần thực hiện major upgrade tiếp theo.

Một vendor repository ghi đè package AppStream là phiên bản nhẹ hơn của cùng vấn đề, và dòng includepkgs ở trên là cách xử lý. Công cụ container thường gặp trường hợp này nhất, vì containerd.io từ repository riêng của Docker xung đột với runc từ AppStream, nên phải loại bỏ một trong hai. Hãy quyết định một lần, ghi lại exclusion và thực hiện theo thứ tự đã được kiểm chứng: hướng dẫn cài Docker trên Rocky Linux nêu rõ cần gỡ các package của bản phân phối nào trước.

Bảng đối chiếu apt sang dnf cho repository

• /etc/apt/sources.list.d/*.sources trở thành /etc/yum.repos.d/*.repo, trong đó một file có thể chứa nhiều [sections], mỗi cái có id riêng.
• add-apt-repository universe trở thành dnf install epel-release, nhưng universe vẫn nằm trong archive riêng của Ubuntu, còn EPEL là một project độc lập.
• apt update không có thành phần tương đương cần ghi nhớ. dnf tự refresh metadata theo lịch của nó, còn dnf makecache buộc refresh ngay.
• apt-cache policy <pkg> trở thành dnf info <pkg>, thêm dnf list --showduplicates <pkg> để xem mọi version hiện có.
• apt-mark hold trở thành dnf versionlock add, lấy từ python3-dnf-plugin-versionlock.
• Pinning trong /etc/apt/preferences.d/ trở thành priority= trong phần repository, nhưng các con số chạy theo thứ tự ngược lại.
• dpkg -S /path/to/file trở thành rpm -qf /path/to/file.

Automatic updates được chuyển đổi ở mức ý tưởng thay vì cú pháp, vì ở đây không có unattended-upgrades. Timer, file cấu hình và việc có nên reboot hay không được trình bày trong dnf-automatic trên Rocky và Alma.

Giữ danh sách repository ngắn

Bật CRB, cài đặt epel-release, rồi ghi lại bạn đã làm gì và vì sao. Bạn có thể ghi trong hệ thống quản lý cấu hình hoặc trong một file văn bản đơn giản trên server. Ghi chú đó có giá trị hơn bạn nghĩ khi server đã chạy được ba năm và đang do người khác quản lý.

Hãy tìm kiếm trước khi thêm repository. Chạy dnf search, sau đó chạy dnf info, rồi mới cân nhắc thêm repository mới. Một phần đáng kể các gói mà người dùng bật EPEL để cài vốn đã có trong AppStream. Monitoring hệ thống là ví dụ rõ nhất: Performance Co-Pilot có trong các repository mặc định và không cần bất kỳ repository bên thứ ba nào. Mỗi repository bổ sung là một bên khác có thể cung cấp package cho bạn vào bất kỳ thứ Ba nào. Mỗi repository cũng khiến lần major upgrade tiếp theo khó hơn.

Nếu bạn vẫn đang chọn giữa hai distribution, cách bố trí này giống nhau trên cả hai, và epel-release hoạt động giống hệt nhau. Khác biệt thực sự nằm ở nơi khác: so sánh Rocky Linux và AlmaLinux trình bày triết lý rebuild, vì AlmaLinux hiện nhắm đến khả năng tương thích ABI (application binary interface) thay vì rebuild từng dòng giống hệt bản gốc.

FAQ

Làm thế nào để bật EPEL trên Rocky Linux 9 hoặc AlmaLinux 9?

Chạy sudo dnf install -y dnf-plugins-core, sau đó sudo dnf config-manager --set-enabled crb, rồi sudo dnf install -y epel-release. Xác nhận bằng dnf repolist --enabled; lệnh này phải liệt kê baseos, appstream, extras, crb và epel. Bật CRB trước khi cài các gói EPEL, vì nhiều gói trong số đó phụ thuộc vào các thư viện chỉ có trong CRB. Trên phiên bản 8, repository id là powertools thay vì crb.

Bật EPEL trên server production có an toàn không?

EPEL được sử dụng rộng rãi và tuân theo chính sách không bao giờ thay thế gói từ bản phân phối cơ sở. Vì vậy, bật EPEL không thay đổi nội dung mà BaseOS hoặc AppStream cung cấp. Điểm cần lưu ý là hỗ trợ: EPEL là một dự án Fedora do cộng đồng tình nguyện duy trì và không có service level agreement. Đề xuất về vòng đời gói của EPEL yêu cầu maintainer cam kết duy trì một gói trong thời gian tối thiểu bằng một bản phát hành phụ của RHEL hoặc 13 tháng. Duy trì inventory bằng dnf repository-packages epel list installed, và dùng dnf versionlock cho mọi gói EPEL mà một service hướng đến khách hàng phụ thuộc vào.

Vì sao dnf báo no such command: config-manager?

Vì config-manager là một dnf plugin, không phải lệnh tích hợp sẵn, còn các image tối giản hoặc container được cung cấp mà không có dnf-plugins-core. Thông báo này cũng nêu cách khắc phục: sudo dnf install -y 'dnf-command(config-manager)'. Cần đặt lệnh trong dấu ngoặc kép để shell không đọc các dấu ngoặc đơn. Nếu hiện chưa thể cài thêm gì, chạy grep -rl crb /etc/yum.repos.d/, mở file mà lệnh chỉ ra, rồi tự đặt enabled=1 trong section [crb].

CRB và PowerTools khác nhau như thế nào?

Đây là cùng một repository nhưng có hai tên. Phiên bản 8 gọi repository này là PowerTools với id powertools. Phiên bản 9 trở lên gọi là CRB với id crb. Sản phẩm tương ứng của Red Hat gọi nội dung này là CodeReady Linux Builder. Repository này chứa development header, static library và công cụ phục vụ build. Trên Rocky và AlmaLinux 9, repository này bị tắt theo mặc định. AlmaLinux 10 bật repository này theo mặc định từ 10.0, vì vậy hãy kiểm tra dnf repolist --enabled trước khi chạy lệnh enable trên hệ thống đó.

Làm thế nào để gỡ EPEL mà không làm hỏng hệ thống?

Trước tiên tạo inventory bằng dnf repository-packages epel list installed, vì chỉ gỡ gói epel-release không gỡ các gói đã cài từ EPEL. Các gói đó vẫn nằm trên disk, mất nguồn cập nhật và không còn nhận security fix, nhưng không có lỗi nào thông báo cho bạn. Kiểm tra từng gói, gỡ hoặc thay thế những gói không còn cần thiết, rồi mới chạy sudo dnf remove epel-release. Nếu một gói từ EPEL không thay thế gói nào khác và chắc chắn phải được gỡ, sudo dnf repository-packages epel remove sẽ xóa toàn bộ tập gói trong một transaction. Hãy đọc kỹ danh sách được đề xuất trước khi xác nhận.