Thursday, 29 October 2026

Red Hat Enterprise Linux (RHEL) 8 and 9 Interview Question and Answer 2026

Q1: Can you explain the support lifecycle phases for RHEL 8 and RHEL 9, including their specific End of Full Support and End of Maintenance Support dates?
Answer: Red Hat follows a strict 10-year lifecycle policy for major releases, split into a 5-year Full Support Phase and a 5-year Maintenance Support Phase, followed by an optional Extended Life Cycle Support (ELS/ELCP) phase. [1, 2]
RHEL VersionGeneral Availability (GA)End of Full SupportEnd of Maintenance Support (EOSL)Extended Support Phase (ELS/ELCP)
RHEL 8May 7, 2019May 31, 2024 (Ended)May 31, 2029Up to May 31, 2033
RHEL 9May 18, 2022May 31, 2027May 31, 2032Up to May 31, 2036
  • Full Support Phase: Red Hat provides critical/important security fixes (RHSAs), urgent bug fixes (RHBAs), and new software/hardware feature enablement.
  • Maintenance Support Phase: Feature enhancements cease. Red Hat only provides critical and important security patches and select urgent bug fixes. [1]
Q2: What are the main operational risks of running a RHEL system past its Maintenance Support (EOSL) date, and how do you remediate them?
Answer: Running an OS past its EOSL date poses three major risks:
  1. Security Vulnerabilities: No new public CVE patches are developed, leaving the infrastructure exposed to exploits.
  2. Compliance Failures: Systems violate regulatory frameworks like PCI DSS, HIPAA, and SOC 2, which explicitly mandate vendor-supported, patched operating systems.
  3. Lack of Vendor Support: Technical support tickets will not be processed by Red Hat Global Support Services. [1]
Remediation Options:
  • Perform an in-place upgrade using Red Hat's official utility (Leapp).
  • Purchase a Red Hat Extended Life Cycle Support (ELS) subscription to extend security patching.
  • Migrate workloads to equivalent enterprise distributions (e.g., Rocky Linux or AlmaLinux). [1, 2]
Part 2: Ansible Automation for Maintenance & Upgrades
Q3: How do you automate the analysis and preparation of an in-place upgrade from RHEL 8 to RHEL 9 across an enterprise environment using Ansible?
Answer: The upgrade is automated by orchestrating the leapp-upgrade tool. The process must be split into a pre-upgrade assessment check, error resolution, and execution. Below is a structured, production-ready Ansible playbook designed to perform the pre-upgrade phase safely:
yaml
---
- name: Pre-Upgrade Assessment from RHEL 8 to RHEL 9
  hosts: rhel8_servers
  become: true
  vars:
    required_packages:
      - leapp-upgrade-el8toel9
      - cockpit-leapp

  tasks:
    - name: Ensure the system is registered with Red Hat Subscription Manager
      org.privileged.rhsm_repository:
        name: rhel-8-for-x86_64-baseos-rpms
        state: enabled

    - name: Update all system packages to the latest minor version
      ansible.builtin.dnf:
        name: "*"
        state: latest
        update_cache: true

    - name: Install Leapp upgrade utility packages
      ansible.builtin.dnf:
        name: "{{ required_packages }}"
        state: present

    - name: Execute Leapp pre-upgrade analysis report
      ansible.builtin.command: leapp preupgrade
      register: leapp_preupgrade_result
      ignore_errors: true
      changed_when: false

    - name: Fetch the Leapp preupgrade report for centralized review
      ansible.builtin.fetch:
        src: /var/log/leapp/leapp-report.txt
        dest: "/var/log/ansible/leapp_reports/{{ inventory_hostname }}-report.txt"
        flat: true

    - name: Check for inhibitors in the report text
      ansible.builtin.lineinfile:
        path: /var/log/leapp/leapp-report.txt
        regexp: '^Risk Factor: High'
        state: absent
      check_mode: true
      register: inhibitor_check

    - name: Fail playbook if upgrade inhibitors are discovered
      ansible.builtin.fail:
        msg: "Upgrade inhibitors found on {{ inventory_hostname }}. Review the fetched report."
      when: inhibitor_check.found > 0
Use code with caution.
Part 3: Troubleshooting RHEL 8 & 9 (Expert Level)
Q4: How do you troubleshoot and fix a RHEL 8/9 server that fails to boot into the OS due to a corrupted GRUB2 bootloader configuration or missing initramfs?
Answer: You must boot the server using a RHEL Installation ISO into Rescue Mode to re-install GRUB2 and regenerate the initial ramdisk.
Step-by-Step Recovery Workflow:
  1. Attach and boot from the official RHEL 8 or RHEL 9 installation media.
  2. Select Troubleshooting -> Rescue a Red Hat Enterprise Linux system.
  3. Choose option 1 (Continue) to mount the existing broken installation under /mnt/sysroot.
  4. Drop into the shell and execute the following commands to pivot root and fix the boot configs:
bash
# Change root to the mounted target system environment
chroot /mnt/sysroot

# For Legacy BIOS systems: Re-install the bootloader binaries
grub2-install /dev/sda

# For modern UEFI-based systems: Reinstall the GRUB2 packages to restore standard files
dnf reinstall grub2-efi shim-x64 -y

# Regenerate the main GRUB2 configuration file
# For RHEL 9 (and updated RHEL 8), the configuration file is universally located at:
grub2-mkconfig -o /boot/grub2/grub.cfg

# If the initramfs/initrd file is missing or corrupted, regenerate it for the current kernel:
dracut --force --verbose

# Force an SELinux relabeling on the next boot (crucial when recovery changes files)
touch /.autorelabel

# Exit chroot and restart the server safely
exit
reboot
Use code with caution.
Q5: A critical web application on RHEL 9 is throwing "Permission Denied" errors when attempting to read files from a secondary local disk partition, even though chmod 777 has been applied. How do you troubleshoot and solve this?
Answer: This symptom indicates an SELinux policy enforcement blockage rather than standard POSIX file permissions.
Step-by-Step Troubleshooting Strategy:
  1. Verify SELinux Status: Run getenforce to confirm if it is in Enforcing mode.
  2. Audit the Logs: Inspect the audit log for denial records (AVC). Use ausearch to isolate the dynamic block:
    bash
    ausearch -m AVC -ts recent
    Use code with caution.
    If it returns entries like denied { read } ... scontext=system_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:user_home_t:s0, the context type is wrong.
  3. Identify the Target Context: The web service (httpd_t) requires files tagged with the httpd_sys_content_t context type.
  4. Remediation Steps: Fix the persistent SELinux context configuration on the secondary mount point path (e.g., /data/www):
    bash
    # Define the persistent context rule in the SELinux policy database
semanage fcontext -a -t httpd_sys_content_t "/data/www(/.*)?"

# Apply the context rules immediately to the target directory and its contents
restorecon -R -v /data/www
    Use code with caution.
  5. Validate that the application reads the file properly without leaving SELinux disabled.
Part 4: Advanced Maintenance Tasks
Q6: How do you configure a persistent, custom kernel parameter runtime control in RHEL 8/9, and how do you cleanly apply it without rebooting?
Answer: RHEL 8 and 9 manage kernel behaviors via sysctl drops located inside /etc/sysctl.d/.
Step-by-Step Implementation:
  1. Create a dedicated configuration file for the distinct architecture subsystem:
    bash
    sudo vi /etc/sysctl.d/99-custom-networking.conf
    Use code with caution.
  2. Add the target tuning parameters (e.g., maximizing network socket buffer space):
    ini
    net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
    Use code with caution.
  3. Load the specific new configuration drop directly into the kernel memory space instantly:
    bash
    sudo sysctl --system
    Use code with caution.
  4. Verify that the parameters have taken dynamic effect:
    bash
    sysctl net.core.rmem_max
Interviewer Question: "Can you explain the major lifecycle differences between RHEL 8 and RHEL 9? When do they hit their final End of Service Life (EOSL) dates, and what happens to a production system after those milestones?"
Your Best Answer:
RHEL 8 was released in May 2019, and its Maintenance Support phase ends on May 31, 2029. RHEL 9 was released in May 2022, and its Maintenance Support phase runs until May 31, 2032. Both versions follow Red Hat's standard 10-year lifecycle, divided into 5 years of Full Support and 5 years of Maintenance Support. [1, 2, 3]
Once a version reaches its final EOSL date (the end of regular maintenance support), Red Hat stops providing standard bug fixes, feature enhancements, and critical security advisories (RHSAs). To protect production environments beyond EOSL, companies must either migrate to a newer version (like RHEL 10, released in May 2025) or purchase an Extended Life Cycle Support (ELS) add-on from Red Hat to receive critical security patches. [1, 2, 3, 4]
Module 2: Managing and Killing Unresponsive Sessions
Interviewer Question: "A user has left a runaway script running in an SSH session that is spiking CPU usage. Walk me through how you identify their session, isolate the specific processes, and completely kill the connection and its child processes."
Step 1: Identify the User and the Terminal Session
First, locate the active user and determine which pseudo-terminal device (pts) their session is using.
bash
w
Use code with caution.
  • Why: The w command shows who is logged in, their source IP address, and their current terminal (e.g., pts/2).
Step 2: Track the Process IDs (PIDs) Tied to that Terminal
Use the process status command to list everything running under that specific terminal window.
bash
ps -ft pts/2
Use code with caution.
  • Why: This limits the scope to just that user's active session processes, helping you pinpoint the exact process ID (PID) causing the bottleneck.
Step 3: Terminate Safely vs. Forcefully
Always start by asking the application to clean up after itself before forcefully pulling the plug.
  • Graceful Termination (SIGTERM - Signal 15): Gives the process a chance to save state and release system resources.
    bash
    sudo kill -15 <PID>
    Use code with caution.
  • Forceful Kill (SIGKILL - Signal 9): Instantly forces the kernel to destroy the process. Use this if the process is completely frozen.
    bash
    sudo kill -9 <PID>
    Use code with caution.
Step 4: Kill the Entire SSH Session At Once
If the shell itself is frozen, kill the parent SSH daemon process managing that specific connection.
bash
sudo pkill -9 -t pts/2
Use code with caution.
  • Why: pkill -t instantly logs out the user and cleans up all processes attached to that terminal.
Module 3: Advanced SSH Troubleshooting
Interviewer Question: "A remote application server cannot connect via SSH to a newly provisioned RHEL 9 instance. Walk me through a logical, step-by-step troubleshooting workflow to resolve this connection issue."
   [ Client ] ---------> [ Firewall (firewalld) ] ---------> [ SSH Daemon (sshd) ]
(ssh -vvv target)        (firewall-cmd --list-all)          (systemctl status sshd)
Step 1: Client-Side Debugging
Always run the SSH connection string with verbose flags to see exactly where the handshake fails.
bash
ssh -vvv user@server_ip
Use code with caution.
  • What to look for: If it hangs at Connecting to server_ip port 22, it is likely a network or firewall blockage. If it says Permission denied (publickey), the issue lies in credentials, keys, or server-side configuration.
Step 2: Check Daemon Status (Server Side)
Access the server console out-of-band and make sure the SSH daemon is actually listening.
bash
sudo systemctl status sshd
Use code with caution.
  • Fix if stopped: sudo systemctl enable --now sshd
Step 3: Check Firewall Rules
RHEL 9 utilizes nftables underneath firewalld. Verify if port 22 is permitted. [1]
bash
sudo firewall-cmd --list-all
Use code with caution.
  • Fix if blocked: Allow the default service and reload the firewall.
    bash
    sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --reload
    Use code with caution.
Step 4: Verify Crypto-Policy Differences (RHEL 8 vs. RHEL 9)
Crucial Interview Insight: RHEL 9 deprecates legacy algorithms like SHA-1 hashes and older RSA keys by default. If your legacy clients fail to connect, you must identify it in the secure log:
bash
sudo tail -n 50 /var/log/secure
Use code with caution.
  • Fix: If you must temporarily allow older clients to connect while they upgrade their keys, lower the system crypto-policy:
    bash
    sudo update-crypto-policies --set DEFAULT:SHA1
    Use code with caution.
Module 4: Crucial Linux System Maintenance Tasks
Interviewer Question: "Can you give me the explicit commands for verifying storage health, applying safe package updates, and reading system logs on modern RHEL systems?"
Task A: Storage Analysis & Filesystem Checks
Before any maintenance window, check your storage boundaries:
bash
df -h
Use code with caution.
  • Why: Displays disk space usage in human-readable formats. If a partition hits 100%, services will crash upon restart. [1]
If a file system is corrupted, unmount it and run a check:
bash
sudo umount /dev/mapper/vg00-lv_data
sudo xfs_repair /dev/mapper/vg00-lv_data
Use code with caution.
  • Note: RHEL 8 and 9 use XFS as the default file system. Use xfs_repair rather than fsck.
Task B: Enterprise Package Management via DNF
Modern RHEL systems use dnf for updates. To patch security issues without breaking major components:
bash
sudo dnf check-update
sudo dnf upgrade --security -y
Use code with caution.
Task C: Navigating Systemd Logs
RHEL 8 and 9 lean heavily on the persistent journal daemon. Replace traditional flat file scanning with modern log analysis:
bash
# View boot logs from the current boot cycle
sudo journalctl -b 0

# Follow real-time logs for a specific service (e.g., sshd)
sudo journalctl -u sshd -f
Q1: What are the exact EOSL milestones for RHEL 8 and RHEL 9? How does the lifecycle model differ from RHEL 7?
Answer:
Red Hat simplified its lifecycle model starting with RHEL 8, moving from four phases down to three primary phases: Full Support, Maintenance Support, and Extended Life Phase. [1]
  • RHEL 8: General Availability (GA) was May 2019. Full Support ended on May 31, 2024. It is currently in the Maintenance Support phase, which runs until May 31, 2029. Extended Life Cycle Support (ELS) runs until May 31, 2032.
  • RHEL 9: GA was May 2022. Full Support ends on May 31, 2027. Maintenance Support runs until May 31, 2032. ELS is available until May 31, 2035. [1, 2]
Architectural Difference: In RHEL 7, major updates were irregular. Starting with RHEL 8 and 9, Red Hat introduced a predictable 3-year major release cadence (RHEL 8 in 2019, RHEL 9 in 2022, RHEL 10 in 2025) and a 6-month minor release cadence (e.g., .1, .2). [1, 2, 3]
Q2: What limitations or risks are introduced when a RHEL system transitions from Full Support to Maintenance Support?
Answer:
During Full Support, Red Hat provides critical/important security errata (RHSAs), urgent/selected high bug fixes (RHBAs), and hardware enablement/software enhancements.
During Maintenance Support (where RHEL 8 currently resides), hardware enablement and software enhancements cease. Red Hat only releases critical and selected important security patches and urgent business-blocking bug fixes. If your enterprise requires new software capabilities or support for newly released CPU architectures, you must upgrade to a major version still in Full Support (like RHEL 9 or RHEL 10). [1]
Part 2: User and Group Maintenance
These questions test your command over secure access management and corporate identity architectures.
Q3: How do you provision a new service user account with a specific UID, non-standard home directory, and no login shell ability? Provide the explicit syntax.
Answer:
bash
# Create the user with custom specifications
useradd -u 1500 -d /app/srv_home -s /sbin/nologin -c "Application Service Account" srv_prod

# Verify the creation using getent or by parsing the configuration files
getent passwd srv_prod
# Output format: srv_prod:x:1500:1500:Application Service Account:/app/srv_home:/sbin/nologin
Use code with caution.
  • -u 1500: Explicitly binds the unique User ID.
  • -d /app/srv_home: Creates the custom home path.
  • -s /sbin/nologin: Blocks interactive terminal access for security hardening. [1]
Q4: A group needs shared collaborative access to /data/finance. Any file created inside must be owned by the finance group, and new files must inherit group read/write rights automatically. How do you implement this?
Answer:
This requires implementing the SGID (Set Group ID) bit along with configuring system umask or Access Control Lists (ACLs).
bash
# 1. Create the group and append target users
groupadd finance
usermod -aG finance user_alpha

# 2. Establish ownership and enforce SGID on the directory
chown -R :finance /data/finance
chmod 2770 /data/finance

# 3. Apply default POSIX ACLs to ensure new files inherit permissions automatically
setfacl -d -m g:finance:rwx /data/finance
setfacl -m g:finance:rwx /data/finance

# 4. Verify directory bits and effective permissions
ls -ld /data/finance
# The output must reflect permissions: drwxrws---. (Note the 's' indicating SGID)
getfacl /data/finance
Use code with caution.
Part 3: Connection & Networking Maintenance
RHEL 8 and 9 fully deprecated older networking scripts in favor of native NetworkManager. These questions test modern network configurations.
Q5: How do you configure a static IPv4 address, default gateway, and DNS server on a interface named ens192 using pure NetworkManager CLI (nmcli)?
Answer:
bash
# 1. Define the static parameters on the connection profile
nmcli connection modify ens192 ipv4.addresses "192.168.10.50/24"
nmcli connection modify ens192 ipv4.gateway "192.168.10.1"
nmcli connection modify ens192 ipv4.dns "8.8.8.8,1.1.1.1"
nmcli connection modify ens192 ipv4.method manual

# 2. Bring the interface up to apply configuration changes live
nmcli connection up ens192

# 3. Confirm configuration state
ip route show
nmcli device show ens192
Use code with caution.
Q6: An application server cannot establish a connection to an external database server on port 5432. Walk through your step-by-step troubleshooting protocol.
Answer:
  1. Verify local outbound routing and link layer state:
    bash
    ip route get 203.0.113.50
ping -c 3 203.0.113.50
    Use code with caution.
  2. Test socket level transport connectivity: Use nc (netcat) or telnet to check if the port is accessible.
    bash
    nc -zv 203.0.113.50 5432
    Use code with caution.
  3. Audit the local firewall rules (Firewalld): Check if outgoing traffic is blocked or if return traffic is rejected.
    bash
    firewall-cmd --list-all
    Use code with caution.
  4. Analyze active network sockets locally: If testing inbound issues, ensure the app is listening correctly.
    bash
    ss -tulpn | grep 5432
    Use code with caution.
  5. Examine SELinux policy denials: SELinux frequently blocks non-standard port connections.
    bash
    sealert -a /var/log/audit/audit.log
# Or quickly check for policy breaches:
getsebool -a | grep httpd_can_network_connect_db
    Use code with caution.
Part 4: General Troubleshooting & Maintenance Tasks
Enterprise operations require strong skills in resource diagnostics and log analysis.
Q7: The root filesystem (/) is reported at 100% utilization. A disk usage check (du) does not account for the missing storage space. How do you resolve this?
Answer:
This indicates deleted files that are still held open by active running processes. The space cannot be reclaimed by the filesystem kernel until the process releases the file descriptor. [1]
  • Step 1: Identify open unlinked files:
    bash
    lsof +L1
# Or alternatively:
lsof | grep deleted
    Use code with caution.
  • Step 2: Free space without killing the production process: Locate the Process ID (PID) and file descriptor (FD) from the command above, then truncate the file:
    bash
    echo > /proc/[PID]/fd/[FD]
    Use code with caution.
  • Step 3: Gracefully restart the daemon if truncation isn't viable:
    bash
    systemctl restart <service_name>
    Use code with caution.
Q8: A critical system service fails on boot. How do you locate the exact root cause using modern systemd journal logging?
Answer:
  • Step 1: Get the aggregate health checklist of all failed systemd units:
    bash
    systemctl --failed
    Use code with caution.
  • Step 2: Pull targeted execution logs for the specific failed daemon (e.g., nginx):
    bash
    journalctl -u nginx.service -n 50 --no-pager
    Use code with caution.
  • Step 3: Isolate logs strictly generated during the current boot cycle to bypass historical clutter:
    bash
    journalctl -b 0 -u nginx.service -p err
    Use code with caution.
    • -b 0: Current boot cycle logs.
    • -p err: Filters for Error priority level messages and worse. [1]
Advanced Troubleshooting Matrix
Use this table to quickly review diagnostic commands during your interview prep:
Operational IssuePrimary Tool / CommandDesired Interview Insight
High Storage I/O Latencyiostat -xz 1 5Look at %util and await columns to isolate failing hardware or excessive writes.
Memory Leak / OOM Killerdmesg -T | grep -i oomValidates if the kernel out-of-memory engine terminated application processes.
Intermittent Packet Lossmtr -c 20 <destination_ip>Combines ping and traceroute capabilities to pinpoint which hop drops packets.
Process Stallingstrace -p <PID>Tracks real-time system calls to identify exactly where a thread is blocking.
Q1: Can you explain the support lifecycle differences between RHEL 8 and RHEL 9, including their exact EOSL (End of Support Life) timelines?
Answer:
Red Hat utilizes a strict 10-year lifecycle for major Enterprise Linux releases, broken down into a Full Support Phase (5 years) and a Maintenance Support Phase (5 years). [1, 2]
  • RHEL 8: Released in May 2019. Its Full Support Phase ended on May 31, 2024. It is currently in the Maintenance Support Phase, which formally concludes on May 31, 2029.
  • RHEL 9: Released in May 2022. Its Full Support Phase ends on May 31, 2027. It will then enter Maintenance Support until May 31, 2032. [1, 2, 3]
Interview Takeaway: During Maintenance Support, systems only receive critical/important security fixes (RHSAs) and select urgent bug fixes (RHBAs). Hardware enablement and software feature additions stop entirely. [1]
Q2: How do you verify a system's current minor release and subscription status to audit for EOSL compliance?
Answer:
Run the following sequential commands to determine the operating system version, kernel, and active repositories:
bash
# 1. Check exact Red Hat release version
cat /etc/redhat-release

# 2. View kernel version and architecture 
uname -r

# 3. Verify Subscription Manager status and lifecycle compliance
sudo subscription-manager status

# 4. List all enabled repositories to verify if EUS (Extended Update Support) is active
sudo dnf repolist
Use code with caution.
Phase 2: Enterprise File System Management
Q3: Walk me through expanding an active XFS file system on top of a Logical Volume (LVM) layer in RHEL 8/9 without causing system downtime.
Answer:
XFS is the default file system in RHEL 8 and 9. Unlike Ext4, an XFS file system can only be grown (expanded), not shrunk, and it must be mounted while doing so. [1]
Step-by-Step Implementation:
bash
# 1. Scan the storage layer for newly provisioned physical disk space (e.g., /dev/sdb)
sudo rescan-scsi-bus.sh # (If using sg3_utils) or manually:
echo "1" | sudo tee /sys/class/block/sdb/device/rescan

# 2. Initialize the Physical Volume (PV)
sudo pvcreate /dev/sdb

# 3. Extend the existing Volume Group (VG) (Assuming VG name is 'vg_data')
sudo vgextend vg_data /dev/sdb

# 4. Extend the Logical Volume (LV) by adding 100% of the newly added free space
sudo lvextend -l +100%FREE /dev/vg_data/lv_storage

# 5. Online-resize the XFS file system using the mount point path (e.g., /data)
sudo xfs_growfs /data

# 6. Verify the new size structure
df -hT /data
Use code with caution.
Q4: How do you safely fix a corrupted XFS metadata issue that causes a file system to drop into read-only mode?
Answer:
XFS uses metadata journaling. If corruption happens, the file system must be unmounted, and xfs_repair must be executed. Never run this tool on a mounted file system.
Step-by-Step Implementation:
bash
# 1. Unmount the target file system safely
sudo umount /dev/vg_data/lv_storage

# 2. Dry-run repair to inspect corruption layout without modifying blocks
sudo xfs_repair -n /dev/vg_data/lv_storage

# 3. Execute the repair. (If log corruption exists, use -L to clear log; note: clearing log may cause data loss of the last transactions)
sudo xfs_repair /dev/vg_data/lv_storage

# 4. Remount the file system and verify its integrity
sudo mount /dev/vg_data/lv_storage /data
sudo xfs_info /data
Use code with caution.
Phase 3: Advanced System Troubleshooting
Q5: A RHEL 8/9 production server displays a "100% Disk Full" warning (df -h), but running du -sh * inside the mount point shows plenty of space. What is the root cause, and how do you resolve it?
Answer:
This happens when processes keep file descriptors open for files that have already been deleted from the directory structure (e.g., an un-rotated application log file). The space is not reclaimed until the referencing process terminates.
Step-by-Step Implementation:
bash
# 1. Identify deleted files that are still being held open in memory by active processes
sudo lsof +L1
# Look for rows marked with '(deleted)' and note the PID.

# 2. Zero-out the space dynamically without killing the application process (Non-disruptive)
# Substitute the PID and file descriptor number (e.g., fd 4) found from the lsof output:
sudo sh -c 'echo > /proc/<PID>/fd/<FD_NUMBER>'

# 3. If zeroing-out fails or is unsupported by the daemon, safely reload or restart the service
sudo systemctl reload <service_name>

# 4. Re-evaluate disk metrics
df -h
Use code with caution.
Q6: A system fails to boot after an administrator modified /etc/fstab. How do you recover the server using GRUB emergency modes?
Answer:
If /etc/fstab contains an incorrect UUID or a broken mount configuration, systemd will fail to mount the target device and drop the OS into an emergency boot loop.
Step-by-Step Implementation:
  1. Reboot the server. At the GRUB2 boot menu, highlight the kernel entry and press e to edit.
  2. Locate the line starting with linux or linux16. Move to the end of this line, append a space followed by: systemd.unit=emergency.target
  3. Press Ctrl + x to boot directly into the emergency minimal shell environment.
  4. Once inside the emergency shell, run these recovery steps:
bash
# 1. Remount the root directory with read-write permissions (it defaults to read-only in emergency mode)
mount -o remount,rw /

# 2. Open /etc/fstab and correct the syntax error or comment out the problematic line
vi /etc/fstab

# 3. Reload systemd daemon to process the modified configuration file
systemctl daemon-reload

# 4. Reboot the system normally to verify the fix
reboot
Use code with caution.
Phase 4: Maintenance Tasks & System Optimization
Q7: How do you construct and automate an official OS patch baseline updates workflow on RHEL 8/9 using DNF?
Answer:
RHEL 8 and 9 use DNF (DaNdiFied YUM) as their core package manager. To maintain security and stability compliance close to an EOSL transition windows, you must isolate update rollouts to security fixes only before applying full package updates. [1]
Step-by-Step Implementation:
bash
# 1. Check for available security updates without installing them
sudo dnf check-update --security

# 2. Install only security-related errata advisories (Critical and Important patches)
sudo dnf upgrade --security -y

# 3. Automate updates via the dnf-automatic tool
sudo dnf install dnf-automatic -y

# 4. Configure automation behavior (Change apply_updates = yes)
sudo sed -i 's/apply_updates = no/apply_updates = yes/g' /etc/dnf/automatic.conf

# 5. Enable and start the systemd timer component to trigger daily updates
sudo systemctl enable --now dnf-automatic.timer
Use code with caution.
Q8: How do you properly manage persistent Systemd logs via journald to prevent log directories from exhausting system disk partitions?
Answer:
By default, RHEL 8/9 configures journald storage to be persistent under /var/log/journal/. Without configuration caps, logs can grow indefinitely.
Step-by-Step Implementation:
bash
# 1. Query the current total storage footprint consumed by journal logs
journalctl --disk-usage

# 2. Manually purge older journal records, keeping only logs from the last 7 days
sudo journalctl --vacuum-time=7d

# 3. Alternatively, cap logs by physical file size constraints (e.g., keep up to 1GB maximum)
sudo journalctl --vacuum-size=1G

# 4. Enforce this permanently by editing the configuration file
sudo mkdir -p /etc/systemd/journald.conf.d/
echo -e "[Journal]\nSystemMaxUse=2G\nSystemMaxFileSize=200M" | sudo tee /etc/systemd/journald.conf.d/maxsize.conf

# 5. Restart the systemd-journald daemon to apply live changes without a reboot
sudo systemctl restart systemd-journald
Q1: Can you explain the difference between the lifecycle phases of RHEL 8 and RHEL 9, specifically outlining their Full Support and Maintenance Support End-of-Life (EOL) dates?
RHEL follows a structured 10-year lifecycle split into a 5-year Full Support Phase and a 5-year Maintenance Support Phase. The key timelines for both versions are:
RHEL Major VersionGeneral Availability (GA)Full Support End DateMaintenance Support End Date (EOSL)
RHEL 8May 2019May 31, 2024 (Ended)May 31, 2029
RHEL 9May 2022May 31, 2027May 31, 2032
  • Full Support Phase: Red Hat provides critical/important security fixes (RHSAs), urgent bug fixes (RHBAs), software enhancements, and new hardware enablement.
  • Maintenance Support Phase: Red Hat provides only critical and important security patches and urgent bug fixes. No new features or hardware enablements are added. [1, 2]
Q2: How do you check the exact OS minor version, kernel release, and subscription lifecycle status on a live system?
An administrator must verify the precise minor stream to determine if they qualify for Extended Update Support (EUS) or if the server is exposed to unpatched vulnerabilities. [1]
Step-by-Step Commands:
  1. Check the distribution release version:
    bash
    cat /etc/redhat-release
# Or using systemd's tool:
hostnamectl
    Use code with caution.
  2. Verify the running kernel architecture and version:
    bash
    uname -r
    Use code with caution.
  3. Check Red Hat Subscription Manager status to see lifecycle extensions:
    bash
    subscription-manager status
    Use code with caution.
Section 2: Linux Boot Process & Recovery Architecture
[BIOS / UEFI] ➔ [GRUB2 Bootloader] ➔ [Initramfs / Initrd] ➔ [systemd (PID 1)] ➔ [Targets / Services]
Q3: Detail the step-by-step boot flow in RHEL 8/9 and explain where it typically fails.
The Enterprise Linux boot process consists of four discrete phases:
  1. Hardware/Firmware Phase (BIOS/UEFI): Executes POST (Power-On Self-Test) and loads the primary bootloader from the EFI system partition (ESP) or MBR.
  2. Bootloader Phase (GRUB2): Loads the configuration (grub.cfg), displays the boot menu, and extracts the selected Linux kernel and RAM disk image (initramfs) into memory.
  3. Kernel & Initramfs Phase: The kernel initializes hardware minimal drivers and mounts the temporary root file system (initramfs) to locate the real root storage volume.
  4. Initialization Phase (systemd): The kernel executes /usr/lib/systemd/systemd as Process ID 1 (PID 1). systemd processes the default target (e.g., multi-user.target), starting services concurrently using unit dependency charts. [1]
Q4: Walk me through troubleshooting a system that drops into an initramfs emergency shell due to a corrupted /etc/fstab or unmountable root partition.
Interview Context: This is the most common live troubleshooting scenario. It happens when a storage UUID changes or a disk volume suffers corruption.
Step-by-Step Remediation:
  1. Interrupt the boot sequence at the GRUB menu by pressing e to edit the default kernel argument line.
  2. Move the cursor down to the line beginning with linux or linux16. Append the following argument to the end of the line:
    text
    systemd.unit=emergency.target
    Use code with caution.
  3. Press Ctrl + X to boot using the modified configuration.
  4. Once inside the emergency shell, the root file system is usually mounted as read-only. Remount it with write permissions:
    bash
    mount -o remount,rw /
    Use code with caution.
  5. Inspect the system block devices and file systems:
    bash
    blkid
lsblk -f
    Use code with caution.
  6. Open /etc/fstab with a text editor and match the UUIDs against your blkid output. Correct any mismatched entries, or comment out non-essential external mounts (like NFS or secondary data LVs) by adding a # to the front of the line:
    bash
    vi /etc/fstab
    Use code with caution.
  7. Apply a manual file system check if a partition is flagged as dirty or corrupted:
    bash
    fsck -y /dev/mapper/rhel-root
    Use code with caution.
  8. Reload the systemd daemon layout and reboot the server: [1]
    bash
    systemctl daemon-reload
reboot
    Use code with caution.
Q5: How do you reset a forgotten root password in RHEL 8 or RHEL 9?
RHEL 8 and 9 use rd.break to interrupt the boot process before control is passed from the initramfs to the system daemon.
Step-by-Step Remediation:
  1. Reboot the server and press e at the GRUB option selection screen.
  2. Append rd.break to the end of the line starting with linux.
  3. Press Ctrl + X to drop into the initramfs switch-root environment.
  4. The actual system disk layout is nested at /sysroot in a read-only state. Remount it to allow modifications:
    bash
    mount -o remount,rw /sysroot
    Use code with caution.
  5. Change the root directory path to your actual system deployment:
    bash
    chroot /sysroot
    Use code with caution.
  6. Reset the password:
    bash
    passwd root
    Use code with caution.
  7. Crucial Step for RHEL 8/9 (SELinux): Because you modified /etc/shadow outside of the active SELinux policy environment, you must flag the system to relabel the file context upon the next startup:
    bash
    touch /.autorelabel
    Use code with caution.
  8. Exit the chroot bubble and reboot the node: [1, 2]
    bash
    exit
exit
    Use code with caution.
Section 3: Performance Troubleshooting & System Diagnostics
Q6: A production RHEL server exhibits high load averages, but CPU usage looks low. How do you diagnose the root cause?
Analysis: High load averages paired with low CPU usage generally point to uninterruptible sleep states (D states). This indicates processes are stuck waiting on Disk I/O operations, network storage timeouts (NFS/iSCSI), or hardware locks.
Step-by-Step Diagnostics:
  1. Evaluate overall metrics. Check the procs section under columns b (blocked waiting for I/O) and r (running or waiting for run time):
    bash
    vmstat 1 5
    Use code with caution.
  2. Inspect the iowait metric percentage (%wa) and system idle time (%id):
    bash
    iostat -xz 1 5
    Use code with caution.
  3. Use top or ps to find processes stuck in the D state:
    bash
    ps aux | awk '$8 ~ /D/'
    Use code with caution.
  4. If a specific process is blocked on storage, track its active system calls to identify the source mount or file descriptor: [1]
    bash
    strace -p <PID>
    Use code with caution.
Q7: A system partition shows 100% utilization via df -h, but running du -sh * inside the directory reports minimal disk space usage. How do you resolve this?
Analysis: This mismatch happens when a massive file (like an active log) has been deleted, but a running application still holds an open file descriptor to it. The file system cannot reclaim the data blocks until the locking process closes that descriptor.
Step-by-Step Remediation:
  1. Identify deleted files that are still held open by active processes:
    bash
    lsof +L1
# Or search via grep:
lsof | grep deleted
    Use code with caution.
  2. Locate the Process ID (PID) and the file descriptor number (FD) from the command output.
  3. Instead of killing the production service, safely free the disk space by truncating the open file descriptor to zero bytes:
    bash
    echo > /proc/<PID>/fd/<FD_NUMBER>
    Use code with caution.
  4. Verify the disk space has dropped back down to expected levels:
    bash
    df -h
    Use code with caution.
Section 4: Routine Maintenance & Enterprise Upgrade Tasks
Q8: How do you safely automate minor version locks on RHEL to prevent accidental package upgrades past a certified baseline?
Enterprise applications (like SAP or Oracle databases) frequently require certified minor OS streams. You can use the subscription-manager or the DNF package manager to enforce version controls.
Step-by-Step Commands:
  1. Lock the system configuration to a specific minor release track (e.g., RHEL 8.8 or RHEL 9.2):
    bash
    subscription-manager release --set=9.2
    Use code with caution.
  2. Clear the local cache to align package maps with the selected release boundary:
    bash
    dnf clean all
    Use code with caution.
  3. Alternatively, lock individual packages (like the kernel) using the DNF version-lock plugin:
    bash
    dnf install 'dnf-command(versionlock)'
dnf versionlock add kernel-*
    Use code with caution.
Q9: What is the procedure for updating a production RHEL 8/9 system's kernel, and how do you roll back if it fails?
Step-by-Step Maintenance Workflow:
  1. Check the current active kernel version:
    bash
    uname -r
    Use code with caution.
  2. Upgrade the kernel package via the DNF repositories:
    bash
    dnf update kernel -y
    Use code with caution.
  3. Verify that the new kernel version is correctly indexed within the GRUB2 boot selection architecture:
    bash
    awk -F\' '/menuentry / {print $2}' /boot/grub2/grub.cfg
# For modern UEFI installations:
grubby --info=ALL
    Use code with caution.
  4. Reboot the host system:
    bash
    reboot
    Use code with caution.
Rollback Procedure (If Boot Fails):
  1. Access the server via out-of-band management (KVM/IPMI console).
  2. During initialization, open the GRUB bootloader menu and select the older, stable kernel entry to complete the boot.
  3. Once logged in, change the default boot selection permanently back to the stable kernel using grubby: [1]
    bash
    grubby --set-default=/boot/vmlinuz-<STABLE_KERNEL_VERSION>
Part 1: Core Lifecycle & EOSL Interview Questions
Q1: Can you explain the RHEL 8 and RHEL 9 lifecycle phases, key EOSL milestones, and what changes for a business post-EOSL?
Answer: Red Hat utilizes a predictable 10-year lifecycle model for major versions, split cleanly into two 5-year phases, followed by optional extended support: [1, 2]
  • RHEL 8: General Availability (GA) was May 2019. Full Support ended on May 31, 2024. It is currently in the Maintenance Support Phase until May 31, 2029. Extended Life Cycle Support (ELS) runs until May 31, 2033.
  • RHEL 9: GA was May 2022. Full Support ends on May 31, 2027. Maintenance Support ends on May 31, 2032, followed by ELS until May 31, 2035. [1, 2, 3, 4]
Post-EOSL/Maintenance Impact: Once a major version exits standard maintenance support, Red Hat stops providing software enhancements, bug fixes (RHBAs), and security patches (RHSAs) unless the company pays for an expensive Extended Life Cycle Support (ELS) subscription. Unpatched production systems violate strict regulatory frameworks like PCI-DSS, HIPAA, and SOC 2. [1, 2]
Q2: How do you handle minor version pinning during an EOSL migration, and what are EUS and E4S?
Answer: When preparing an application stack for migration, we cannot always leap immediately to the latest minor version due to vendor constraints. We use specific repositories: [1]
  • Extended Update Support (EUS): Available on even-numbered minor releases (e.g., RHEL 8.8, 9.2, 9.4). It extends security and critical bug fixes for 24 months, allowing an organization to skip a minor release cycle safely.
  • Update Services for SAP Solutions (E4S): Offers up to 4 years of minor release pinning for critical enterprise enterprise applications like SAP HANA. [1, 2, 3, 4]
Part 2: Step-by-Step Leapp Migration Architecture & Log Analysis
In RHEL environments, the gold standard for migrating an OS to the next major version (RHEL 8 → RHEL 9) is the Leapp utility. Interviewers will test your familiarity with its generated output, logs, and answerfiles. [1]
Crucial Leapp Logs & Files (/var/log/leapp/) [1]
  1. /var/log/leapp/leapp-report.txt – Human-readable output. Categorizes blockages as Inhibitor (must fix to proceed), High, Medium, or Low.
  2. /var/log/leapp/answerfile – A text-based question-and-answer file for configurations that require explicit admin sign-off (e.g., verifying the removal of unmaintained kernel modules or legacy storage layers).
  3. /var/log/leapp/leapp-upgrade.log – System-level execution debug logs tracking the actual DNF package transaction and initramfs execution. [1]
Part 3: Step-by-Step Troubleshooting Scenarios & Commands
Scenario A: The Pre-Upgrade Check Fails with an Inhibitor
Problem: You run the leapp preupgrade command, and it fails, stating that the transaction is blocked by third-party packages, an unconfirmed answerfile, or network interface configurations. [1]
Step-by-Step Resolution:
  1. Verify your OS baseline: Ensure the server is updated to the latest supported minor version within the migration path.
    bash
    sudo dnf update -y
sudo reboot
    Use code with caution.
  2. Execute the preupgrade analysis:
    bash
    sudo leapp preupgrade
    Use code with caution.
  3. Scan the report explicitly for Inhibitors:
    bash
    grep -B 1 -A 5 "Risk Factor: inhibitor" /var/log/leapp/leapp-report.txt
    Use code with caution.
  4. Interact with the Answerfile: If the report specifies that a module confirmation is missing (e.g., dropping support for legacy VDO storage layouts):
    bash
    # Read the file
cat /var/log/leapp/answerfile

# Provide the programmatic approval using the leapp answer command
sudo leapp answer --section remove_pam_pkcs11_module_check.confirm=True
    Use code with caution.
  5. Clean up conflicting packages: If third-party or orphaned packages from older repositories block the transaction: [1, 2]
    bash
    sudo dnf remove <package_name> --allow-erasing
    Use code with caution.
Scenario B: DNF Repository / Subscription Manager Errors During Download
Problem: The upgrade tool fails during the package retrieval phase because the server cannot reach the necessary RHEL 9 baseOS and AppStream target repositories.
Step-by-Step Resolution:
  1. Verify Subscription Status: Ensure the system is actively attached to a valid Red Hat subscription matrix.
    bash
    sudo subscription-manager status
    Use code with caution.
  2. Refresh subscription certificates and cache:
    bash
    sudo subscription-manager refresh
sudo dnf clean all
    Use code with caution.
  3. Check release locking configuration: If the system is pinned to a specific minor version, it will block the upgrade. Clear the lock:
    bash
    sudo subscription-manager release --unset
    Use code with caution.
  4. Verify RHSM repository access: [1, 2]
    bash
    sudo subscription-manager repos --list-enabled | grep -E 'baseos|appstream'
    Use code with caution.
Scenario C: Post-Migration Boot Failure or Initramfs Loop
Problem: The leapp upgrade completed, the system rebooted, but now it is stuck in an initramfs rescue shell or fails to boot into the new RHEL 9 kernel. [1, 2]
Step-by-Step Resolution:
  1. Interrupt GRUB at Boot: Restart the machine, press e at the GRUB menu, locate the line starting with linux, append systemd.debug_shell=1, and press Ctrl+X to boot.
  2. Access logs from the emergency target: If dropped into an emergency shell, extract the persistent journal logs:
    bash
    journalctl -xb -p err
    Use code with caution.
  3. Verify root filesystem mounting and space: A filled root partition or corrupted /etc/fstab will crash a major upgrade hook.
    bash
    df -h
cat /proc/mounts | grep root
    Use code with caution.
  4. Rebuild the initramfs image: If the kernel failed to load the necessary storage drivers (e.g., LVM or RAID modules) after upgrading:
    bash
    # Identify the current target RHEL 9 kernel version
ls /lib/modules/

# Force generate a clean initramfs image
sudo dracut --regenerate-all --force
    Use code with caution.
  5. Audit SELinux contexts: Relabeling issues are a primary cause of post-upgrade boot loops. Temporarily set to permissive via the boot loader or command line to recover control: [1, 2]
    bash
    sudo setenforce 0
# Trigger a complete background filesystem relabel for the new OS baseline
sudo touch /.autorelabel
sudo reboot
    Use code with caution.
Part 4: Technical Summary Table
Operational PhaseKey Log / Configuration FilePrimary Command Line Tool
Pre-Migration Audit/var/log/leapp/leapp-report.txtleapp preupgrade
Manual Override Hooks/var/log/leapp/answerfileleapp answer --section ...
Package Dependency Phase/var/log/leapp/dnf-debugdata/dnf history, subscription-manager
Post-Reboot Failure AuditPersistent Systemd Journaljournalctl -xb, dracut
Common Interview Questions & Answers
Q1: What is the primary operational difference for an administrator now that RHEL 8 has transitioned out of the Full Support phase?
  • Answer: RHEL 8 entered Maintenance Support after May 31, 2024. This means Red Hat no longer provides new software enhancements or non-critical hardware enablement. Operational focus transitions strictly to Critical and Important Security fixes (RHSAs) and urgent bug resolutions. [1, 2]
Q2: What is the technical difference between an In-Place Upgrade and a Clean Install when migrating a system from RHEL 8 to RHEL 9 near EOSL?
  • Answer: An In-Place Upgrade uses the Red Hat Leapp utility to swap the underlying package footprint from RHEL 8 to RHEL 9 while fully preserving configurations, data, and applications on the existing filesystem. A Clean Install completely overwrites or formats storage drives, requiring administrators to reconfigure the environment and restore application data from backups. [1, 2]
Part 2: Masterclass on RPM Installation & Command Details
In enterprise systems, package management is handled at two distinct layers:
  1. rpm (Red Hat Package Manager): A low-level backend tool that installs specific .rpm files directly but does not automatically resolve dependencies from remote networks.
  2. dnf / yum (Dandified YUM): The high-level frontend engine that interacts with defined package repositories, resolves intricate structural dependencies, and pulls required library layers automatically.
Scenario A: Direct, Low-Level RPM Installation (rpm)
Use this method when you have manually downloaded a standalone vendor package (e.g., application.rpm) onto your server storage.
  • Step 1: Check if the package is already installed
    bash
    rpm -q wget
    Use code with caution.
    • Details: -q stands for query. It evaluates the internal RPM database to determine if a specific package footprint exists.
  • Step 2: Install the package with detailed progress indicators
    bash
    sudo rpm -ivh wget-1.21.1-7.el9.x86_64.rpm
    Use code with caution.
    • Details:
      • -i: Initiates standard package installation.
      • -v: Verbose mode (displays detailed internal tracking information).
      • -h: Prints hash marks (#) to provide a visual progress bar during installation. [1]
  • Step 3: Upgrade an existing package version safely
    bash
    sudo rpm -Uvh wget-1.22.1-1.el9.x86_64.rpm
    Use code with caution.
    • Details: -U stands for Upgrade. It attempts to update an older version of the package. If no previous version is found, it falls back and executes a clean install. [1]
  • Step 4: Erase / Remove a package
    bash
    sudo rpm -e wget
    Use code with caution.
    • Details: -e stands for erase. This deletes the application files and purges its signature footprint from the central RPM tracking index.
Scenario B: Advanced Frontend Package Management (dnf)
dnf is the default standard for RHEL 8 and RHEL 9. It dynamically automates cross-repository installation.
  • Step 1: Search for an available package inside your active repos
    bash
    dnf search httpd
    Use code with caution.
  • Step 2: Install a package and auto-resolve dependencies
    bash
    sudo dnf install httpd -y
    Use code with caution.
    • Details: The -y flag answers "yes" to all prompts automatically, bypassing interactive confirmation check-points during deployments or CI/CD pipelines.
  • Step 3: Force re-installation of a corrupted package
    bash
    sudo dnf reinstall httpd
    Use code with caution.
    • Details: Overwrites the binary layers of an already installed package without needing to uninstall it first, fixing broken configurations or missing dependencies.
  • Step 4: Manage complex software bundles using groups
    bash
    sudo dnf groupinstall "Development Tools"

Q1: What is the operational difference between "Full Support" and "Maintenance Support" for RHEL 8/9?
Answer:
  • Full Support: Red Hat delivers all levels of updates—Critical/Important security patches (RHSAs), urgent bug fixes (RHBAs), new hardware enablement, and software enhancements via minor point releases.
  • Maintenance Support: Red Hat only releases Critical and Important security advisories (RHSAs) and urgent business-blocking bug fixes. There is no new hardware support and no software feature development.
  • Interview Context: RHEL 8 entered Maintenance Support on May 31, 2024. It will receive no new features up to its EOSL in 2029. RHEL 9 is currently in Full Support until May 31, 2027.
Q2: Our enterprise environment is running RHEL 8.10. It is in Maintenance Support. How do we audit our systems to check compliance and plan a migration?
Answer: We perform a system health check using native tools to identify the exact kernel, OS release, and subscription lifecycle status.
Step-by-Step Commands:
  1. Check the exact Red Hat release version:
    bash
    cat /etc/redhat-release
    Use code with caution.
  2. Verify the active Linux kernel version (RHEL 8 uses 4.18.x, RHEL 9 uses 5.14.x):
    bash
    uname -r
    Use code with caution.
  3. Check subscription status, product expiration, and underlying support lifecycles directly via the Red Hat Subscription Manager:
    bash
    sudo subscription-manager status
sudo subscription-manager list --consumed
    Use code with caution.
Q3: If a server hits the absolute End of Life (EOSL) date (e.g., RHEL 8 in May 2029), what happens to the package manager (dnf) functionality?
Answer: Once a system enters the Extended Life Phase (post-EOSL), the official standard repositories stop receiving updates. The dnf command will still run, and you can still download existing archived packages, but no new CVE fixes or security patches will ever be published to those standard repos. To continue getting patches, the enterprise must purchase an Extended Life Cycle Support (ELS) add-on subscription.
Q4: Walk me through the step-by-step process of upgrading an OS from RHEL 8 to RHEL 9 as it approaches its EOSL window.
Answer: Red Hat officially provides the Leapp utility to perform an in-place upgrade from RHEL 8 to RHEL 9.
Step-by-Step Upgrade Execution:
  • Step 1: Preparation & Full Update
    Ensure your RHEL 8 system is updated to the latest minor version (e.g., 8.10) and register it cleanly.
    bash
    sudo dnf update -y
sudo reboot
    Use code with caution.
  • Step 2: Install the Leapp Upgrade Tool
    bash
    sudo dnf install leapp-upgrade -y
    Use code with caution.
  • Step 3: Run the Pre-upgrade Assessment
    This creates a comprehensive report (/var/log/leapp/leapp-report.txt) outlining inhibitors that will block the upgrade (e.g., incompatible kernel modules, deprecated software packages).
    bash
    sudo leapp preupgrade
    Use code with caution.
  • Step 4: Remediate Inhibitors
    You must look inside the text report and resolve issues. For example, if it flags an unpermitted root login configuration, modify it:
    bash
    sudo leapp answer --section authselect_check.confirm=True
    Use code with caution.
  • Step 5: Execute the In-Place Upgrade
    Once the preupgrade returns a green light, trigger the actual package download and boot-image transformation:
    bash
    sudo leapp upgrade
    Use code with caution.
  • Step 6: Reboot to complete the conversion
    bash
    sudo reboot
    Use code with caution.
  • Step 7: Post-Upgrade Verification
    bash
    cat /etc/redhat-release
# Output should show: Red Hat Enterprise Linux release 9.x
    Use code with caution.
System Performance Tuning During Lifecycle Transitions
When evaluating system performance during migration planning or lifecycle updates, keep these core debugging procedures ready for scenario-based questions:
  • To diagnose a slow server or heavy process utilization:
    bash
    top -b -n 1 | head -n 20
    Use code with caution.
  • To check memory constraints (Virtual vs Physical Memory maps):
    bash
    free -m
    Use code with caution.
  • To look for hardware-level issues or kernel panics inside logs:
    bash
    sudo journalctl -p err..emerg -n 50

Q1: What are the lifecycle phases and EOSL dates for RHEL 8 and RHEL 9? How does Red Hat structure its support?
Answer: Red Hat utilizes a structured 10-year lifecycle for major enterprise distributions, divided cleanly into two distinct 5-year phases, followed by optional extended support options: [1]
  1. Full Support Phase (First 5 Years): Includes hardware enablement, bug fixes, enhancements, and critical/important security errata.
  2. Maintenance Support Phase (Next 5 Years): Restricts updates exclusively to critical-impact security fixes and high-priority, business-blocking bugs.
  3. Extended Life Cycle Support (ELS): An optional paid add-on allowing systems running the terminal minor release to receive specific security patches beyond the maintenance phase. [1, 2, 3, 4]
Major VersionGeneral Availability (GA)Full Support EndMaintenance Support End (Standard EOSL)Extended Life Support (ELS) EndTerminal Minor Version
RHEL 8May 7, 2019May 31, 2024 (Ended)May 31, 2029May 31, 2033RHEL 8.10
RHEL 9May 18, 2022May 31, 2027May 31, 2032May 31, 2036RHEL 9.10 (Planned)
Q2: As an administrator, what operational risks do you face if a production fleet reaches its EOSL date?
Answer: The primary risks include:
  • Zero Security Errata: Red Hat stops providing Critical Security Advisories (RHSAs), leaving systems highly vulnerable to newer CVE exploits.
  • Compliance Failure: Running an unpatched, unsupported OS breaks major industry compliance regulations such as PCI-DSS, HIPAA, and SOC 2.
  • Third-Party Software Drop: ISVs (Independent Software Vendors) like Oracle, SAP, and IBM will drop compatibility support for modern software builds on an expired base OS. [1]
Part 2: Automated Installation (Kickstart)
Q3: How do you provision hundreds of RHEL 8/9 bare-metal or virtual servers consistently without manual intervention?
Answer: I leverage Kickstart automation coupled with a network boot infra (PXE/DHCP/TFTP). Kickstart uses a flat text configuration file (anaconda-ks.cfg) containing all predefined configurations (partitioning, packages, network, root password).
Step-by-Step Production Command Workflow:
  1. Locate the Kickstart Template: When you install a RHEL machine manually once, Anaconda automatically dumps a valid blueprint to /root/anaconda-ks.cfg.
  2. Host the File: Put the configuration file on a centralized network endpoint (HTTP/HTTPS server), for instance: http://192.168.1.
  3. Trigger the Installation via Boot Arguments:
    Boot your server via PXE or a minimal ISO, hit Tab or e at the GRUB boot menu, and append the direct pointer parameter to the kernel command line:
    bash
    inst.ks=http://192.168.1
    Use code with caution.
Part 3: Enterprise Patching & Package Management
Q4: What is the underlying software repository framework in RHEL 8 and 9, and how do you patch systems securely?
Answer: Both RHEL 8 and 9 split software distribution into two primary foundational repositories: [1, 2]
  • BaseOS: Delivers the core underlying operating system functionality (Kernel, systemd, structural tools).
  • AppStream: Contains runtime languages, databases, web applications, and developer tools delivered via specialized application streams or modules. [1]
Step-by-Step Command Workflow for System Patching:
  • Register and Subscribe System to Red Hat CDN:
    bash
    subscription-manager register --username <your_username> --password <your_password>
subscription-manager attach --auto
    Use code with caution.
  • Verify Repository Status:
    bash
    dnf repolist
    Use code with caution.
  • Check for Available Security Updates Only:
    bash
    dnf check-update --security
    Use code with caution.
  • Apply Vulnerability Patches targeting a specific CVE:
    bash
    dnf update --cve CVE-2026-XXXX
    Use code with caution.
  • Apply All Available System Patches:
    bash
    dnf update -y
    Use code with caution.
Part 4: In-Place Production Upgrade (RHEL 8 to RHEL 9)
Q5: Walk me through a professional, zero-data-loss in-place upgrade from RHEL 8 to RHEL 9 in a production ecosystem. [1]
Answer: Red Hat formally supports and provides the Leapp utility to execute automated, structural in-place upgrades from RHEL 8 to RHEL 9. [1, 2]
Phase 1: Heavy Pre-flight Checks & System Lock
  • Verify System Status & Support Path: Enforce latest updates onto your current RHEL 8 system (RHEL 8.10 is required for clean transitions to RHEL 9).
    bash
    cat /etc/redhat-release
dnf update -y && reboot
    Use code with caution.
  • Set Target Release Lock & Install Upgrade Utilities:
    bash
    subscription-manager release --set 8.10
dnf install leapp-upgrade -y
    Use code with caution.
  • Clear DNF Versionlocks (Crucial to prevent tool dependency conflicts): [1, 2, 3]
    bash
    dnf versionlock clear
    Use code with caution.
Phase 2: The Pre-Upgrade Assessment (Dry-Run)
Run the analytical scanner. This checks filesystems, networking configurations, kernel compatibility, and missing repository linkages: [1]
bash
leapp preupgrade --target 9.4
Use code with caution.
  • Read the Report: The tool flags binary blockers as "Inhibitors" inside the report file located at /var/log/leapp/leapp-report.txt. The upgrade cannot proceed until all Inhibitors are resolved.
  • Address Common Inhibitors (e.g., PermitRootLogin configuration / Firewalld Zone Drifting): [1, 2]
    bash
    # Resolve common firewalld inhibitor
sed -i 's/AllowZoneDrifting=yes/AllowZoneDrifting=no/g' /etc/firewalld/firewalld.conf
    Use code with caution.
Phase 3: Executing the Binary Upgrade
Once leapp preupgrade returns success with zero inhibitors, trigger the download and transaction building: [1]
bash
leapp upgrade --target 9.4
Use code with caution.
  • Reboot the host:
    bash
    reboot
    Use code with caution.
  • GRUB Intervention: During the initial boot phase, the system automatically redirects into a temporary RAM disk image labeled RHEL-Upgrade-Initramfs. It performs all package swaps, relocations, and structural configuration overrides automatically here. The node will automatically reboot when completed. [1, 2, 3]
Phase 4: Post-Upgrade Validation
  • Verify OS Distribution Release & Architecture:
    bash
    cat /etc/redhat-release
# Expected Output: Red Hat Enterprise Linux release 9.4 (Ootpa)
    Use code with caution.
  • Unset Release Lock & Update Subscription Profile to RHEL 9:
    bash
    subscription-manager release --unset
subscription-manager refresh
    Use code with caution.
  • Clean Up Outdated RHEL 8 Package Remnants: [1]
    bash
    dnf repoquery --duplicated
dnf autoremove -y
    Use code with caution.
Part 5: Diagnostic & Troubleshooting Scenarios
Q6: During a Leapp upgrade, the process fails with a dependency error involving custom or third-party packages. How do you recover?
Answer:
  1. I inspect /var/log/leapp/leapp-report.json and /var/log/leapp/leapp-upgrade.log to trace the specific culprit package.
  2. Because Leapp strictly handles standard Red Hat repositories, any third-party or custom software must be temporarily uninstalled before the upgrade using rpm -e --nodeps <package_name>.
  3. Alternatively, I can provide custom repository map files to Leapp by adding repository data to /etc/leapp/files/leapp_upgrade_repositories.repo so that the tool can calculate the upgrade paths for third-party packages seamlessly

Part 1: Expert Interview Q&A
Q1: Can you detail the differences between the RHEL 8 and RHEL 9 lifecycle milestones?
Answer: Both distributions follow Red Hat's standard 10-year enterprise lifecycle, divided into 5 years of Full Support and 5 years of Maintenance Support.
  • RHEL 8 was released in May 2019. Its Full Support phase ended on May 31, 2024, and it is currently in the Maintenance Support phase until May 31, 2029.
  • RHEL 9 was released in May 2022. Its Full Support phase ends on May 31, 2027, after which it enters Maintenance Support until May 31, 2032.
  • Senior insight: During Maintenance Support, systems only receive Critical and Important Security Advisories (RHSAs) and urgent bug fixes; no new hardware enablement or software features are provided.
Q2: What major technical shifts occur under the hood when upgrading from RHEL 8 to RHEL 9?
Answer: The primary shifts span the package manager, security defaults, and the software ecosystem:
  1. Package Management & System Core: RHEL 9 updates the core components to glibc 2.34 and shifts fully to DNF v4 (with enhanced modularity filters).
  2. Crypto Policies: RHEL 9 disables TLS 1.0, TLS 1.1, and SHA-1 by default at the system-wide cryptographic level (DEFAULT profile).
  3. Network Configuration: RHEL 9 officially deprecates legacy network scripts (network-scripts). All network interfaces must be entirely managed by NetworkManager via keyfiles.
  4. Filesystem/Kernel: The kernel shifts from 4.18 (RHEL 8) to 5.14 (RHEL 9), dropped legacy hardware drivers, and optimized cgroup v2 by default.
Q3: How do you plan, validate, and execute an in-place migration for a fleet of RHEL 8 servers approaching its lifecycle limits?
Answer: I follow a strict 4-stage automated process:
  1. Inventory & Target Profiling: Identify workloads running on RHEL 8.10 (the final minor release) using configuration management or the subscription-manager.
  2. Pre-conversion Assessment: Execute the leapp preupgrade utility to generate an actionable JSON assessment report outlining blockers.
  3. Remediation & Automation: Address inhibitors (e.g., modifying answering files, updating third-party kernel modules) using an automated Ansible playbook.
  4. Execution & Validation: Run leapp upgrade, reboot into the upgrade initramfs environment, and perform post-upgrade schema checks, network availability tracking, and application smoke tests.
Part 2: Routine Task Playbook — In-Place Upgrade (RHEL 8 to RHEL 9)
This playbook outlines a standard infrastructure task to upgrade an enterprise server safely.
[Target Architecture]
RHEL 8.10 (Source Production VM) ──► [Leapp Engine Validation] ──► RHEL 9.x (Target Stable)
Step 1: Pre-Flight Environment Checks
Before deploying code changes, verify system registration, architecture, and version parity.
bash
# Verify the current OS release version (Must be RHEL 8.10 for stable upgrade pathway)
cat /etc/redhat-release

# Ensure the machine is properly registered with Red Hat Subscription Management
sudo subscription-manager status

# Enable both BaseOS and AppStream 8 repositories explicitly
sudo subscription-manager repos --enable rhel-8-for-x86_64-baseos-rpms --enable rhel-8-for-x86_64-appstream-rpms

# Install the Leapp upgrade automation architecture framework
sudo dnf install leapp-upgrade -y
Use code with caution.
Step 2: Running the Pre-Upgrade Analyzer
This non-disruptive phase evaluates your file systems, active configurations, and installed modules against RHEL 9 rulesets.
bash
# Execute the check engine (Does NOT modify your system)
sudo leapp preupgrade
Use code with caution.
  • Critical Deliverable: Inspect /var/log/leapp/leapp-report.txt. If blockers exist, the process fails.
  • Common Blocker Remediation Example: Leapp frequently requires you to acknowledge a policy option manually.
bash
# Example: Resolve the common "PermitRootLogin" warning by setting an explicit choice
sudo leapp answer --section auth_select_check.confirm=True
Use code with caution.
Step 3: Executing the Binary Migration Phase
Once the report has zero Inhibitor flags left, initiate the packages download and execution.
bash
# Download RHEL 9 packages and generate the trans-OS initramfs
sudo leapp upgrade

# Initiate immediate graceful system reboot to hand control over to the Leapp environment
sudo reboot
Use code with caution.
Note: During this phase, the server will load into a dedicated boot menu entry (Red Hat Enterprise Linux Upgrade Initramfs), update all binaries, re-label SELinux context files, and reboot back to standard login.
Step 4: Post-Migration System Validation
Verify that the underlying platform successfully transitioned without configuration regression.
bash
# Check the post-upgrade distribution string
cat /etc/redhat-release

# Verify the updated enterprise kernel release version (Should be 5.14+)
uname -r

# Verify that the active subscription automatically flipped onto RHEL 9 conduits
sudo subscription-manager list --consumed

# Remove residual old RHEL 8 software artifacts and cached metadata packages
sudo dnf rpm-va --do-not-verify digest orders
sudo rm -rf /var/log/leapp

Part 1: The Core EOL Interview Question & Concept
Interviewer: "RHEL 8 is progressing through its lifecycle. Can you explain its current support phase, when it hits absolute EOL, and what steps you would take to handle infrastructure running this OS?"
Your Answer Structure:
  • The Status & Milestones: RHEL 8's Full Support phase ended on May 31, 2024. It is currently in the Maintenance Support phase, which runs until May 31, 2029. Its final minor release is RHEL 8.10. After May 31, 2029, it enters the Extended Life Phase, meaning no more standard patches or CVE security fixes unless the company purchases an Extended Life Cycle Support (ELS) add-on. [1, 2, 3, 4, 5]
  • The Impact: During the current Maintenance Support phase, we only receive Critical and Important Security Advisories (RHSAs) and urgent bug fixes. No new features or hardware enablement are added. [1]
  • The Action Plan: As an administrator, my routine involves audit tracking, keeping the system securely locked down to its terminal minor release (8.10) using subscription-manager, and proactively planning an in-place upgrade to RHEL 9 using the Leapp utility. [1, 2]
Part 2: Routine Tasks & Commands for RHEL 8 Infrastructure
In an interview, you must back up your explanations with precise commands. Here are the 4 major routine tasks expected of an engineer managing RHEL 8 environments.
Task 1: Auditing & Verifying OS Lifecycle Status
Before managing an environment, you must dynamically pull system information to check minor release statuses.
  • Check OS Release details:
    bash
    cat /etc/redhat-release
# Or for a detailed breakdown:
hostnamectl status
    Use code with caution.
  • Check Red Hat Subscription Status: Verify if the system is registered to the Red Hat Content Delivery Network (CDN) and receiving maintenance repositories.
    bash
    sudo subscription-manager status
    Use code with caution.
  • List Enabled Repositories: Verify if the standard or extended support streams are enabled. [1, 2]
    bash
    sudo dnf repolist
    Use code with caution.
Task 2: Locking Repositories to a Specific Minor Version (RHEL 8.10)
To avoid unpredictable application breaks while in maintenance mode, environments lock systems to the terminal minor version. [1]
  • Lock the system to RHEL 8.10:
    bash
    sudo subscription-manager release --set=8.10
    Use code with caution.
  • Clear the DNF Cache and Verify:
    bash
    sudo dnf clean all
sudo subscription-manager release --show
    Use code with caution.
Task 3: Routine Patching of Maintenance & Security Flaws (RHSAs)
During maintenance support, patching focuses strictly on minimizing vulnerabilities without upgrading functional software layers. [1]
  • Check for available security updates only:
    bash
    sudo dnf updateinfo list security --installed
sudo dnf check-update --security
    Use code with caution.
  • Apply ONLY Critical and Important Security Patches:
    bash
    sudo dnf update --security -y
    Use code with caution.
Task 4: Preparing for Migration via Pre-Upgrade Assessment (Leapp)
An interviewer will want to hear how you plan to transition off RHEL 8. The industry-standard way is using the Leapp tool framework for an in-place upgrade to RHEL 9.
  • Install the Leapp utility package:
    bash
    sudo dnf install leapp-upgrade -y
    Use code with caution.
  • Execute the Pre-Upgrade Check: This creates a report (/var/log/leapp/leapp-report.txt) outlining system blockers without altering files.
    bash
    sudo leapp preupgrade
    Use code with caution.
  • Analyze Inhibitors (Routine Admin Work): You will read the report and resolve issues (e.g., removing unsupportable legacy packages, modifying kernel parameters). Once clear, the production upgrade command is:
    bash
    sudo leapp upgrade
    Use code with caution.
Part 3: Cheat Sheet for Interview Pro-Tips
Interview ScenarioThe "Expert" Response
"What if an application cannot be migrated off RHEL 8 past 2029?"Explain that you would architect a mitigation strategy by subscribing the host to Red Hat Extended Life Cycle Support (ELS) to obtain critical CVE patches, or look into containerizing the application using Podman on a newer RHEL 9 host.
"How do you handle package management shifts in RHEL 8?"Mention that RHEL 8 natively transitioned from yum to DNF (Dandified YUM) and implemented Application Streams (AppStreams), allowing us to run multiple versions of languages (like Python or Node.js) on the same OS structure.
"How do you automate this maintenance across 500+ servers?""I use Ansible Playbooks integrated with Red Hat Satellite. I push target minor releases via Satellite Content Views and use Ansible's dnf module to run automated patch cycles."

Part 1: RHEL 8 Lifecycle & Strategic Interview Questions
Q1: What is the current lifecycle status of RHEL 8, and what does it mean for our infrastructure?
  • Answer: RHEL 8 ended its Full Support Phase on May 31, 2024. It is now in the Maintenance Support Phase until May 31, 2029. During this time, Red Hat only provides Critical and Important Security Advisories (RHSAs) and urgent bug fixes. No new features or hardware enablement are added. After May 2029, it will enter the Extended Life Phase, requiring a paid ELS add-on to receive any security updates.
  • Key Interview Tip: Highlight that because we are past the Full Support window, our immediate priority is ensuring we only run the latest minor release (RHEL 8.10) to receive maintenance patches, while actively mapping out migrations to RHEL 9 or 10.
Q2: If a team requests a new application deployment on RHEL 8 today, how do you handle it?
  • Answer: I evaluate the application's lifespan. If it's a short-term project, deploying on RHEL 8 is fine since Maintenance Support goes to 2029. However, if it's a core production workload intended to stay for 3+ years, I strongly advise deploying it on RHEL 9 (or RHEL 10 depending on software compatibility) to avoid an emergency migration later. If RHEL 8 is mandatory due to legacy software dependencies, I document the system in our Technical Debt Register to ensure it is slated for regular patching via dnf until its 2029 EOSL date.
Q3: How do you track OS lifecycles and compliance across a massive server fleet?
  • Answer: I rely on automated asset tracking and patch management. I query server metadata using infrastructure monitoring tools or tools like the Red Hat Hybrid Cloud Console to segment inventory by OS minor version. To prevent compliance flags under frameworks like PCI-DSS or HIPAA (which mandate active vendor support), I write automated compliance scripts that alert us if any system falls below RHEL 8.10 or uses a point release that has reached its individual Extended Update Support (EUS) end.
Part 2: Daily System Administration Tasks & Commands
In an interview, you must show you can handle the daily operational reality of managing RHEL 8 nodes. Structure your day-to-day duties like this:
1. Lifecycle Tracking & Version Audits
You must constantly check what minor version your servers are on to ensure they are getting maintenance updates.
bash
# Check the exact RHEL release version
cat /etc/redhat-release
# Or use subscription-manager to check pinned release status
subscription-manager release --show
Use code with caution.
2. Vulnerability Management & Targeted Patching
Since RHEL 8 only receives Critical/Important security patches now, daily or weekly tasks involve auditing and applying security-only errata rather than doing complete system upgrades.
bash
# Check for available security updates without installing them
dnf updateinfo list security --installed
# Install ONLY critical and important security patches
dnf upgrade --security -y
Use code with caution.
3. Proactive Migration Planning (Pre-upgrade Verification)
As part of your daily roadmap tasks, you prepare RHEL 8 systems for eventual upgrades to RHEL 9 using Red Hat's official utility, Leapp.
bash
# Install the Leapp pre-upgrade tool
dnf install leapp-upgrade-el8toel9
# Run a pre-upgrade assessment check (generates a detailed report at /var/log/leapp/leapp-report.txt)
leapp preupgrade
Summary Table: RHEL 8 Support Timeline
PhaseTime PeriodWhat is Provided?Impact on Daily Operations
Full SupportMay 2019 – May 2024All bugs, CVEs, hardware enablement, new features.Standard maintenance, package installs, and configuration.
Maintenance Support (Current)Jun 2024 – May 2029Only Critical/Important Security fixes (RHSAs) & urgent bugs.Strict patching of CVEs, freezing feature updates, preparing migration paths.
Extended Life Cycle (ELS)Jun 2029 – May 2033Limited critical fixes via paid add-on subscription.High subscription cost overhead, high risk, isolated legacy setups.

 



1. What is the current lifecycle status of Red Hat Enterprise Linux (RHEL) 8, and when does it reach EOSL?

Answer:
  • Current Status: RHEL 8 transitioned out of the Full Support phase on May 31, 2024, and is currently in the Maintenance Support Phase.
  • EOSL / EOL Date: RHEL 8 will officially reach the end of its standard Maintenance Support on May 31, 2029.
  • Extended Phase: After May 31, 2029, it enters the Extended Life Phase, or customers can purchase the new Enhanced Life Cycle Planning (ELCP) add-on (which replaces the traditional ELS starting with RHEL 8.10) for an additional 4 years of limited support. 
2. What is the difference between RHEL 8's "Full Support" phase and its current "Maintenance Support" phase?
Answer:
  • Full Support Phase (Ended May 2024): Red Hat provided comprehensive software enhancements, new hardware enablement, bug fixes (RHBAs), and all levels of security errata (Critical, Important, Moderate). 
  • Maintenance Support Phase (Active until May 2029): Red Hat only releases Critical and Important security patches (RHSAs) and selected urgent bug fixes. There is no new hardware support, no architectural changes, and no new features or software enhancements being introduced.
3. If a production server runs RHEL 8 past May 2029 without an extended support agreement, what are the primary business and technical risks?
Answer:
  • Security & Vulnerabilities: Red Hat stops issuing CVE patches. Zero-day vulnerabilities will remain unpatched, exposing the infrastructure to attacks.
  • Compliance Failures: Running an unsupported operating system without active security patching violates major regulatory frameworks, including PCI DSS, HIPAA, and SOC 2.
  • Software/Vendor Isolation: New versions of third-party software, agents, and database systems will drop support for RHEL 8, creating compatibility deadlocks. [
4. As a System Administrator/Architect, what strategies would you propose to handle the upcoming RHEL 8 EOSL?
Answer:
I would evaluate the infrastructure and propose a tiered approach based on workload criticality:
  1. In-place Upgrade to RHEL 9: For core enterprise applications, use Red Hat’s official migration tool (Leapp) to upgrade the underlying OS directly to RHEL 9. 
  2. Fresh Deployment / Migration: Spin up new RHEL 9 (or RHEL 10) instances, deploy the applications via automated CI/CD pipelines, and gracefully decommission the RHEL 8 servers.
  3. Enterprise Linux Alternatives: For non-critical, development, or cost-sensitive workloads, consider migrating to binary-compatible alternatives like Rocky Linux 8/9 or AlmaLinux 8/9. 
  4. Legacy Retention (ELCP): If an application cannot be modified or upgraded due to strict vendor locks, we must purchase the Enhanced Life Cycle Planning (ELCP) add-on from Red Hat to buy up to 4 more years of maintenance. 
5. Can you explain how the Leapp utility works when upgrading from RHEL 8 to RHEL 9?
Answer:
The Leapp utility is Red Hat's supported framework for executing in-place major upgrades. The process follows two main stages: 
  • Pre-upgrade Phase (leapp preupgrade): This executes a dry run that analyzes the system configuration, installed repositories, kernel modules, and applications. It generates a comprehensive report (/var/log/leapp/leapp-report.txt) highlighting potential inhibitors (e.g., incompatible packages, deprecated configurations) that must be resolved before proceeding.
  • Upgrade Phase (leapp upgrade): Once all inhibitors are cleared, this command downloads RHEL 9 packages, creates a temporary initial RAM disk (initramfs), updates the bootloader configuration, and triggers a system reboot to execute the package replacements. 
6. How does Red Hat's lifecycle policy differ for minor point releases (e.g., RHEL 8.6 vs 8.10) approaching EOL?
Answer:
  • Standard RHEL minor versions generally have a very short lifecycle; they go EOL as soon as the next minor version is released (roughly every 6 months).
  • However, Red Hat offers Extended Update Support (EUS) for select even-numbered minor releases (like RHEL 8.6 or 8.8), extending their support for up to 2 years to provide stability for critical workloads.
  • RHEL 8.10 is the final, terminal minor release of the RHEL 8 lifecycle. It inherits the remainder of the overall Maintenance Support phase up until the May 2029 deadline. 
on

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)