Red Hat and CentOS Installation and Troubleshooting FAQ

Archived OEM FAQ for RHEL/CentOS 5/6/7-era systems. Seven English instructional localizations/excerpts and ten original English figures retain all seventeen source image positions. Kernel, driver and firmware workarounds are tied to the source cases; destructive metadata operations and obsolete cryptography are explicitly identified. No command, package update, storage write, reboot or network change was performed while preparing this translation.

1. Load a required storage driver in the source UEFI installation workflow

Problem Description

When installing Red Hat 6.x/7.x systems in UEFI mode, the driver loading method differs from the legacy mode described in system installation tutorials on IT information websites.

Problem Cause

The way array card drivers are loaded in legacy mode differs from that in UEFI mode.

Solution

If you confirm during installation that array card/RAID card drivers need to be loaded,

Enter the GRUB menu, move to the line "Install Red Hat Enterprise Linux 7.X" and press the "E" key to edit boot parameters.

The source RHEL 7.3 GRUB figure appends dd before quiet on the linuxefi line and uses Ctrl+X to boot. This is the archived shorthand as pictured, not a disk-writing dd shell command. Red Hat’s RHEL 7 installation documentation specifies inst.dd for the driver-update prompt or inst.dd=<location> for a specified image. Use the option documented for the actual release; the figure does not prove that every RHEL 6/7 boot loader uses the same syntax.

Locate the USB drive containing the drivers, such as "2) sda1", and enter the number "2".

In the source interactive example, R refreshes the device list and 2 selects its sda1 media entry. Select the actual driver media rather than assuming it is always device 2. The OEM refers to its related installation tutorial; this stored article does not contain further figures for that driver-selection sequence.

 

2. Unsupported Hardware Detected (Hardware Not Supported) prompt appears when installing Red Hat/CentOS systems

Problem Description

During Red Hat/CentOS system installation, the following error message may occasionally appear: Unsupported Hardware Detected, This hardware (or a combination thereof) is not supported by RedHat. For more information on supported hardware, please refer to http://www.redhat.com/hardware

Problem Cause

Red Hat/CentOS systems have different compatibility requirements for different types of CPUs.

Red Hat Official Statement:https://access.redhat.com/support/policy/intel

The OEM lists these historical CPU-generation/minimum-release examples. They are not a current complete system certification matrix; verify the exact server model, CPU and OS/kernel combination with the hardware and OS vendors:

Intel IvyBridge series CPUs E5-26xx/46xx/88xx V2 require version 6.4/7.0 or higher to support;

Intel Haswell series CPUs E5-26xx/46xx V3 require version 6.5/7.0 or higher to support;

Intel Haswell series CPUs E5-88xx V3 require version 6.6/7.1 or higher to support;

Intel Broadwell series CPUs E5-26xx/46xx/88xx V4 require version 6.7/7.2 or higher to support.

Solution

Do not treat dismissing Unsupported Hardware Detected as proof of hardware support. The OEM source describes continuing past the warning or using a suitable release, and an unsupported_hardware Kickstart option in RHEL/CentOS 6.4-era deployments. That option suppresses a warning; it does not certify the platform. Red Hat’s current linked policy describes support in terms of certified complete system configurations. The source warning’s OK highlight is retained as historical context.https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Installation_Guide/s1-kickstart2-options.html

3. Selecting freeipmi-related packages when installing Red Hat/CentOS 6.5 may cause servers to restart intermittently.

Problem Description

Servers restart at irregular intervals. Upon collecting logs, bmc-watchdog errors are observed within ten to twenty minutes prior to the unexpected shutdown time, similar to the following:

/usr/sbin/bmc-watchdog[xxxx]: fiid_obj_get:’present_countdown_value’: data not available

Problem Cause

This issue is a bug in the Red Hat/CentOS 6.5 system; official statement:https://access.redhat.com/site/solutions/628963

Preliminary analysis indicates that freeipmi fails to correctly reset the watchdog timer, causing the watchdog timer to reach zero, thereby triggering the BMC to send a restart command.

Solution

Archived method 1: the source discusses removing freeipmi, freeipmi-bmc-watchdog, freeipmi-ipmidetectd and watchdog at the pictured package versions. Inspect whether those packages/services are actually installed and what depends on them; this is not an instruction to remove every IPMI package on an unrelated host.

The original explicitly uses rpm -e --nodeps because conman depends on freeipmi in its example. --nodeps bypasses dependency checks and can leave dependent software broken; do not treat it as a generally safe package-removal prerequisite. This translation records the historical method without performing it.

Archived method 2: the OEM names freeipmi 1.2.1-6.el6_5 or later and its old erratum link. Red Hat’s publicly visible KB confirms the RHEL 6.5/freeipmi 1.2.1-3.el6 watchdog symptom, but the detailed resolution is subscription-restricted; it was not independently read here. Select a vendor-supported update for the actual legacy deployment rather than assuming that this historic version is a current universal target.

Download link:http://rhn.redhat.com/errata/RHBA-2013-1795.html

Upgrade command: yum update freeipmi

The source then shows /etc/modprobe.d/watchdog-reboot-workaround.conf aliases and module/service commands. Its ACPI pattern is an archived example and has not been validated against another host’s hardware; verify the actual vendor package requirements. The English figure is explicitly an excerpt of the post-update module/service commands and omits the alias lines; the following text preserves those source lines for reference, not as commands executed here:

alias acpi:IPI000*:* ipmi_si
alias acpi:IPI000*:* ipmi_devintf
alias acpi:IPI000*:* ipmi_msghandler

 

4. System fails to boot after installation if tboot package is selected when installing Red Hat/CentOS 6.x or 7.x systems in UEFI mode.

Problem Description

If the tboot package is selected during Red Hat 6.x/7.x system installation in UEFI mode, the system fails to boot after installation. Error message: invalid magic number:0 Error 13:Invalid or unsupported executable format

Problem Cause

The source attributes this boot failure to tboot/TXT in its legacy UEFI configuration. Red Hat has an English article covering this RHEL 6/7-era restriction. Preserve the release/firmware context; this is not a claim about every later trusted-boot implementation.

Solution

The OEM’s first alternative is a Legacy BIOS installation for the affected historical configuration. Changing boot mode affects the expected boot media and installed-system boot path; do not switch an existing installation blindly.

Its second alternative is an affected UEFI installation without selecting tboot, when that matches the actual deployment’s boot/security requirements. The source package-selection figure shows tboot unchecked.

Issue where hard drives are recognized as /dev/mapper/ddf1 instead of /dev/sdX when installing a Linux system with SATA drives directly connected to the motherboard.

Problem Description

Local disks cannot be seen during installation, and the following prompt appears: "Disk sda,sdb contain BIOS RAID metadata, but are not part of any recognized BIOS RAID sets. Ignoring disks sda, sdb", as shown in the figure below:

Problem Cause

The hard drive was previously configured for SATA RAID, and the RAID information was not fully deleted. The Linux system can identify

the soft RAID information on the hard drive and marks the hard drive with the device name /dev/mapper/ddf1... instead of names like /dev/sda.

Solution

If unexpected BIOS-RAID metadata affects target visibility, stop before changing storage. Identify the physical disks, existing array and data requirements. The source’s proposed RAID deletion and BIOS SATA-to-AHCI change are state-changing operations, not diagnostic checks; do not apply them to a needed array just to obtain a different /dev/sdX name.

The following source examples describe inspecting and then erasing residual metadata. Device names, metadata offsets and lengths are specific to that example. A console opened with Ctrl+Alt+F2 does not make a write operation safe. Proceed with any real storage-removal operation only under the intended recovery/redeployment plan with verified target identity and backups.

1) Check the current soft RAID status:

The source describes dmraid metadata dump files in the current directory or a dmraid subdirectory. Its fallback dmraid -r -E /dev/sda is an erase action, not a harmless way to generate missing dump files. Do not run it merely because a dump file is absent.

2) Execute the following command to view the soft Raid configuration file:

# ls -l sda_ddf1.*

-rw——- 1 root root 6144 Jun 10 04:06 sda_ddf1.dat

-rw——- 1 root root 13 Jun 10 04:06 sda_ddf1.offset

-rw——- 1 root root 10 Jun 10 04:06 sda_ddf1.size

3) Archived destructive metadata-clear example: the next English figure retains the source dd target /dev/sda, count 6144, and the offset read from sda_ddf1.offset. This writes zero bytes at a raw-disk offset and can destroy required RAID metadata/data access. A wrong disk, offset or count can cause further damage. The pictured output is a translated source example, not an operation or validation performed here.

 

The OEM’s final fallback suggests moving the disk to a PC for low-level formatting. That is destructive and is not a general diagnostic remedy or a guarantee of disk health. If metadata cannot be interpreted or the intended storage state is uncertain, preserve the evidence and use the controller/vendor recovery procedure instead of experimenting with erasure.

Issue where disk letter drift occurs when RHEL/CentOS 6.x systems boot while both RAID cards and HBA cards coexist.

Problem Description:

After installing an HBA card and mapping disks in RHEL 6, disk letter drift occurs. For example, if the original system disk was assigned /dev/sda, after mapping disks and rebooting the system, the system disk letter changes to the last one, such as

/dev/sdf.

Problem Cause:

In the Linux kernel, SCSI disk letter allocation depends on the order in which the driver scans the hard drives. That is, the first scanned hard drive gets the disk letter /dev/sda, the second gets /dev/sdb, and so on.

Generally, the order in which the driver scans hard drives is related to the loading order of drivers for different types of SAS/RAID controllers. If the RAID card driver loads first, the hard drives under that RAID controller will be assigned disk letters first; thus, the hard drive corresponding to /dev/sda is under that RAID controller. If the HBA card driver loads first, the storage volumes mapped by the HBA card will receive disk letters first; in this case, /dev/sda refers to storage under the HBA card.

Therefore, the cause of disk letter drift is a change in the loading order of HBA/RAID controller drivers. This loading order is determined by udev mechanism configuration files.

Solution:

For the source RHEL 6/dracut workflow, rdloaddriver options in the selected boot configuration influence early driver loading. The source uses this as a workaround for a specific controller scan-order case; it does not make /dev/sdX naming a persistent storage identity. Verify boot/root references and the release-specific driver-loading mechanism before changing an existing boot entry.

For example, to load the megaraid_sas driver (driver name for LSI RAID cards) first, followed by the qla2xxx driver (driver name for Qlogic HBA cards), add the following parameters to the end of the kernel line in the grub.conf file:

title Red Hat Enterprise Linux (2.6.32-358.el6.x86_64)

root (hd0,0)

kernel /vmlinuz-2.6.32-358.el6.x86_64 ro root=UUID=e3469fb3-54b0-4207-9aab-7ead38ea4f9a rd_NO_LUKS rd_NO_LVM LANG=en_US.UTF-8 rd_NO_MD SYSFONT=latarcyrheb-sun16 crashkernel=128M  KEYBOARDTYPE=pc KEYTABLE=us rd_NO_DM rhgb quiet rdloaddriver=megaraid_sas  rdloaddriver=qla2xxx

initrd /mpp-2.6.32-358.el6.x86_64.img

If using an Adaptec RAID card, the driver name is aacraid

If using an Emulex HBA card, the driver name is lpfc

If RDAC multipath software is installed on the system, the HBA card driver should be selected as mppUpper

The OEM reports that loading only its RAID driver early was sufficient in its tested case; that outcome was not reproduced here and is not a guarantee for every RAID/HBA/multipath combination. The displayed UUID, initramfs path and driver names are source-specific examples, not a boot entry to copy wholesale.

Issue where Redhat/CentOS 6.3 systems hang when entering the graphical interface

Problem Description:

After the RHEL 6.3 system boots into the graphical interface, mouse operation experiences latency, and the system soon hangs. However, if entering command-line mode, the system works normally.

 

Problem Cause:

This issue is related to the kernel. There is a compatibility error between the 6.3 kernel, the graphical interface, and drivers for some devices. This error is related to Intel's IOMMU functionality.

When viewing system logs, the following errors appear:

Sep 21 13:32:21 localhost kernel: pcieport 0000:00:03.0: AER: Corrected error received: id=0018

Sep 21 13:32:21 localhost kernel: pcieport 0000:00:03.0: PCIe Bus Error: severity=Corrected, type=Physical Layer, id=0018(Receiver ID)

Sep 21 13:32:21 localhost kernel: pcieport 0000:00:03.0: device [8086:340a] error status/mask=00000001/00002000

Sep 21 13:32:21 localhost kernel: pcieport 0000:00:03.0: [ 0] Receiver Error (First)

Solution:

For this archived RHEL 6.3 case, the OEM proposes changing intel_iommu=on to intel_iommu=off in the intended /etc/grub.conf kernel line and rebooting. That changes IOMMU behavior and may affect device isolation/passthrough; corrected AER log entries alone do not establish this diagnosis or guarantee the workaround will resolve a GUI hang. Match the actual kernel/platform case and keep an accessible recovery path before a real boot change.

8. Error 'kernel:do_IRQ: x.x No irq handler for vector (irq -1)' under Redhat/CentOS 6.x system

Problem Description:

Problem Cause:

The source’s explanation is a possible driver-unload/interrupt-vector cleanup defect involving pci_disable_device(), request_irq() and free_irq(). This is a case description, not a root cause established from the short error string alone. The original English console figure shows repeated No irq handler for vector messages.

Solution:

The OEM proposes pcie_aspm=off at the end of its RHEL 6 kernel line as a case-specific workaround. Its intended effect is to disable PCIe Active State Power Management in that legacy context; exact behavior must be checked for the active kernel version. The English figure is a labelled abbreviated entry with [existing options], not a complete runnable GRUB configuration. It does not prove that every interrupt-vector error is an ASPM issue.

9. Redhat certain versions may trigger panic or automatic reboot after continuous operation for 208 days

Problem Description

The archived issue affects particular older kernels: a sched_clock() overflow after roughly 208.5 days of uptime can cause a panic/reboot or related symptoms. Red Hat’s English KB identifies affected RHEL 5/6 kernel ranges and TSC-clock context; this is not a prediction that every Linux host will reboot at that uptime. A configured crash-dump/reboot path can affect what is observed.

Moreover, some processes may generate error messages similar to the following in the logs:

BUG: soft lockup – CPU#N stuck for 4278190091s!

Problem Cause

The source discusses TSC and the affected sched_clock() implementation. The current_clocksource command below is a useful observation, but changing that selection alone is not demonstrated here as a fix for the affected implementation.

Use the following command to check the current clock source used by the system:

 

Redhat official description is as follows:

The source’s quoted explanation attributes the overflow to older sched_clock() arithmetic and notes that simply choosing a slower clock or notsc may fail to address the affected RHEL 5 implementation and can reduce performance. This is an archived summary, not a verified workaround for an arbitrary kernel.

Solution

Check the installed kernel against the vendor’s affected/fixed advisory and obtain the supported corrective update through the deployment’s approved support/repository path. The source’s old licensing sentence is not a complete description of all update channels or current access entitlements. No kernel update was installed here.

10. Archived OEM release-to-kernel examples (not a complete update matrix)

Red Hat Enterprise Linux 5 (Tikanga), 2007-03-14. kernel 2.6.18-8

5.1, also termed Update 1, 2007-11-07 (kernel 2.6.18-53)

5.2, also termed Update 2, 2008-05-21 (kernel 2.6.18-92)

5.3, also termed Update 3, 2009-01-20 (kernel 2.6.18-128)

5.4, also termed Update 4, 2009-09-02 (kernel 2.6.18-164)

5.5, also termed Update 5, 2010-03-30 (kernel 2.6.18-194)

5.6, also termed Update 6, 2011-01-13 (kernel 2.6.18-238)

5.7, also termed Update 7, 2011-07-21 (kernel 2.6.18-274)

5.8, also termed Update 8, 2012-02-20 (kernel 2.6.18-308)

Red Hat Enterprise Linux 6 (Santiago), 2010-11-10. kernel 2.6.32-71

6.1 also termed Update 1, 2011-05-19 (kernel 2.6.32-131)
6.2 also termed Update 2, 2011-12-06 (kernel 2.6.32-220)
6.3 also termed Update 3, 2012-06-20 (kernel 2.6.32-279)
6.4, also termed Update 4, 2013-02-21(kernel 2.6.32-358)
6.5, also termed Update 5, 2013-11-21(kernel 2.6.32-431)
6.6, also termed Update 6, 2014-10-13(kernel 2.6.32-504)
6.7, also termed Update 7, 2015-07-22(kernel 2.6.32-573)
6.8, also termed Update 8, 2016-05-10(kernel 2.6.32-642)

Red Hat Enterprise Linux 7 (Maipo), 2014-06-10. kernel 3.10

Release	General Availability Date	redhat-release	Kernel Version
RHEL 7.0 Beta	2013-12-11	–	3.10.0-54.0.1
RHEL 7.0 GA	2014-06-09	–	3.10.0-123
RHEL 7.1	2015-03-05	2015-03-05	3.10.0-229
RHEL 7.2	2015-11-19	2015-11-19	3.10.0-327

11. Slow file copying speed using scp on Linux operating system

Problem Description

Under the Linux system, using the scp command to copy files between servers results in slow network transfer speeds. For example, on a Gigabit network, the maximum speed might only be 30-40MB/s, which is far less than the network bandwidth and disk performance.

Problem Cause

scp transfers can be constrained by CPU/encryption, storage, protocol and network behavior; a slow copy alone is not a direct measurement of link capacity. The source reports 30–40 MB/s in one Gigabit scenario and about 130 MB/s with scp -c arcfour in a separate 10 Gb/s test. arcfour is obsolete and was removed by OpenSSH; do not enable it as a current performance recommendation. The English figure explicitly preserves and labels the historical report. No transfer benchmark was run here.

Solution

 

12. Incomplete recognition of CPU and memory on Linux system

Problem Description

Problem Cause

 

 

13. Network card unusable after installing Linux system, indicator light does not turn on

Problem Description

After installing the Linux system, the network card cannot be used. The ifconfig command shows no network card information, and the network card indicator light does not turn on even after plugging in the cable.

Problem Cause

A disabled interface or ONBOOT=no can explain an unactivated legacy configuration, but a dark link LED or missing interface can also have driver, cable, port or hardware causes. Verify device detection and the intended connection before assuming a configuration-only cause.

Solution

Modify the network card configuration file to activate the network card and restart the network service.

The configuration file is located in the /etc/sysconfig/network-scripts/ directory, for example ifcfg-eth0. The content is as follows:

 

In the source legacy ifcfg example, ONBOOT=yes enables activation at boot. Its DEVICE=eth0, MAC address, 192.168.1.100/24 and gateway 192.168.1.254 are examples, not values to copy to another host. The source service network restart command restarts networking and can disconnect remote sessions. Use the management method supported by the actual distribution; newer releases may use NetworkManager instead of this legacy script layout.

English sources and scope

• Red Hat RHEL7 driver-update workflow
• Red Hat hardware/CPU support policy
• Red Hat RHEL6.5 watchdog symptom (resolution access restricted)
• Red Hat legacy tboot/TXT and boot-mode scope
• Red Hat sched_clock overflow at about208.5days
• Linux kernel boot-parameter reference (versioned example)
• OpenSSH release notes: removal of arcfour

No corresponding complete English OEM FAQ was verified; its English selector leads to the home page. The official English articles describe the same specific topics, but do not provide an equivalent complete OEM screenshot set. Their public scope was checked; inaccessible detailed resolutions and the old RHBA-2013-1795 link are not claimed as independently verified. The retained release/kernel list is an archived partial OEM reference, not an exhaustive list of supported patched kernels. The source has different dates in its RHEL7 summary and GA table; they are retained as source entries rather than silently normalized.