Long-Term Supported Versions


    openEuler Fails to Start After It Is Installed to the Second Drive


    The OS is installed on the second drive sdb during the installation, causing startup failure.

    Possible Causes

    When openEuler is installed to the second drive, MBR and GRUB are installed to the second drive sdb by default. The following two situations may occur:

    1. The first drive contains a complete OS. The OS on the first drive is loaded and started.
    2. The first drive does not contain a complete OS. The system fails to be booted from the hard drives.

    These two situations occur because the BIOS loads the boot loader from the first drive sda by default to start the OS. If no OS is not installed on the sda drive, the system fails to be booted.


    This problem can be solved using either of the following two methods:

    • During the openEuler installation, select the first drive or both drives, and install the boot loader on the first drive sda.
    • If openEuler is already installed, modifying the boot sequence in the BIOS and restart the system.

    openEuler Enters Emergency Mode After It Is Started


    openEuler enters emergency mode after it is started.

    Possible Causes

    The drive fails to be mounted due to damaged OS files or timeout caused by excessively high I/O pressure (the timeout threshold is 90 seconds).

    These causes may be the results of an unexpected system power-off or low I/O performance of drives.


    1. Log in to openEuler as the root user.

    2. Check and restore files by using the file system check (fsck) tool, and restart openEuler.

      NOTE: The fsck tool checks and maintains inconsistent file systems. If an unexpected system power-off occurs or a drive is faulty, run the fsck command to check file systems. Run the fsck.ext3 -h and fsck.ext4 -h commands to view the usage of the fsck tool.

    If you want to disable the timeout mechanism of drive mounting, add x-systemd.device-timeout=0 to the etc/fstab file. For example:

    # /etc/fstab
    # Created by anaconda on Mon Sep 14 17:25:48 2015
    # Accessible filesystems, by reference, are maintained under '/dev/disk'
    # See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info
    /dev/mapper/openEuler-root / ext4 defaults,x-systemd.device-timeout=0 0 0
    UUID=afcc811f-4b20-42fc-9d31-7307a8cfe0df /boot ext4 defaults,x-systemd.device-timeout=0 0 0
    /dev/mapper/openEuler-home /home ext4 defaults 0 0
    /dev/mapper/openEuler-swap swap swap defaults 0 0

    openEuler Fails to Be Reinstalled When an Logical Volume Group Cannot Be Activated


    After a drive fails, a logical volume group cannot be activated and openEuler fails to be reinstalled.

    Possible Causes

    During the installation of openEuler, the logical volume groups are activated. An error message is displayed when one of the groups fails to be activated.


    Before reinstalling openEuler, restore the abnormal logical volume group to the normal status or remove it. For example:

    • Restore the logical volume group.

      1. Clear the activation status of the abnormal logical volume group to ensure that the error message "Can't open /dev/sdc exclusively mounted filesystem" is not displayed:

         vgchange -a n testvg32947
      2. Recreate a physical volume based on the backup file:

        pvcreate --uuid JT7zlL-K5G4-izjB-3i5L-e94f-7yuX-rhkLjL --restorefile /etc/lvm/backup/testvg32947 /dev/sdc
      3. Restore the logical volume group information:

        vgcfgrestore testvg32947
      4. Reactivate the logical volume group:

         vgchange -ay testvg32947
    • Remove the logical volume group:

      vgchange -a n testvg32947
      vgremove -y testvg32947

    An Exception Occurs During the Selection of the Installation Source


    After the installation source is selected, the message "Error checking software selection" is displayed.

    Possible Causes

    The software package dependency in the installation source is abnormal.


    Check whether the installation source is abnormal. If yes, use a new installation source.

    Kdump Service Fails to Be Enabled


    The systemctl status kdump command displays the following output, indicating that no memory is reserved.

    Possible Causes

    The kdump service requires the system to reserve memory for running the kdump kernel. However, the system does not reserve memory for the kdump service. As a result, the kdump service cannot be started.


    If openEuler is already installed:

    1. Add crashkernel=1024M,high to /boot/efi/EFI/openEuler/grub.cfg.

    2. Restart the system for the configuration to take effect.

    3. Run the following command to check the kdump status:

      systemctl status kdump

      If the following information is displayed, the kdump status is active, indicating that the kdump service is enabled. No further action is required.

    Parameter Description

    The following parameters are used to specify the memory reserved for the kdump kernel.

    Table 1 crashkernel parameters

    Kernel Boot Parameter


    Default Value



    Reserve X of the physical memory for kdump when the physical memory is less than 4 GB.

    None. You can adjust the value as required.

    This parameter is used only when the memory is less than 4 GB. Ensure that the available contiguous memory is sufficient for reservation.


    Reserve X of the memory at the start address Y for kdump.

    None. You can adjust the value as required.

    Ensure that the X of the memory at the start address Y is not reserved for other modules.


    Reserve 256 MB of the physical memory for kdump when the physical memory is less than 4 GB, or X of the physical memory for kdump when the physical memory is greater than or equal to 4 GB.

    None. You can adjust the value based as required. The recommended value is 1024M,high.

    Ensure that 256 MB of continuous memory is available when the physical memory is less than 4 GB, or X of continuous memory is available when the physical memory is greater than or equal to 4 GB. The actual reserved memory is 256 MB plus X.



    Reserve X of the physical memory for kdump when the physical memory is less than 4 GB, or Y of the physical memory for kdump when the physical memory is greater than or equal to 4 GB.

    None. You can adjust the value as required.

    Ensure that X of of continuous memory is available when the physical memory is less than 4 GB, or Y of continuous memory is available when the physical memory is greater than or equal to 4 GB. The actual reserved memory is X plus Y.

    Fails to Select Only One Drive for Reinstallation When openEuler Is Installed on a Logical Volume Consisting of Multiple Drives


    openEuler is installed on a logical volume consisting of multiple drives. An error message as shown in Figure 1 is displayed when you attempt to select one of the drives for reinstallation.

    Figure 1 Error message

    Possible Causes

    The logical volume used for previous installation contains multiple drives. If you select one of the drives for reinstallation, the logical volume will be damaged.


    The logical volume formed by multiple drives is equivalent to a volume group. Therefore, you only need to delete the corresponding volume group.

    1. Press Ctrl+Alt+F2 to switch to the CLI and run the following command to find the volume group:


    2. Run the following command to delete the volume group:

      vgremove euleros
    3. Run the following command to restart the installation program for the modification to take effect:

      systemctl restart anaconda

      NOTE: You can also press Ctrl+Alt+F6 to return to the GUI and click Refresh in the lower right corner to refresh the storage configuration.

    openEuler Fails to Be Installed on an x86 PM in UEFI Mode due to the Secure Boot Setting


    During the installation of openEuler on an x86 PM in UEFI mode, the system stays at the "No bootable device" page and the installation cannot continue because secure boot is set to enabled (by default, it is disabled), as shown in Figure 2.

    Figure 2 "No bootable device" page

    Possible Causes

    After secure boot is set to enabled, the mainboard verifies the boot loader and OS. If the boot loader and OS are not signed using the corresponding private key, they cannot pass the authentication of the built-in public key on the mainboard.


    Enter the BIOS, disable secure boot, and reinstall openEuler.

    1. During the system startup, press F11 and enter the password Admin@9000 to access the BIOS.

      NOTE: The server here refers to the Huawei TaiShan server. If other servers are used, you need to confirm your password.

    2. Choose Administer Secure Boot.

    3. Set Enforce Secure Boot to Disabled.

      NOTE: After Enforce Secure Boot is set to Disabled, save the settings and exit. Then, reinstall the system.

    pmie_check Failure Is Reported in the messages Log During openEuler Installation


    During the OS installation, if you click Server > Performance tool, PCP is installed. After the OS is installed and restarted, an error "pmie_check failed in /usr/share/pcp/lib/pmie" is displayed in the /var/log/messages log.

    Possible Causes

    Anaconda cannot install the SELinux policy module in the chroot environment. During the PCP-SELinux installation, the postin script fails to execute the PCP-related SELinux policy module. As a result, an error is reported after the OS is restarted.


    After the openEuler is installed and restarted, perform either of the following two operations:

    1. Install SElinux policy module pcpupstream.

      /usr/libexec/pcp/bin/selinux-setup /var/lib/pcp/selinux install "pcpupstream"
    2. Reinstall pcp-selinux

      sudo dnf reinstall pcp-selinux

    Installation Fails when You Select Two Drives with OSs Installed for Custom Partitioning


    Two drives with OSs installed exist in on the machine. During openEuler installation, if you select one drive for custom partitioning, click Cancel, and then perform custom partitioning on the other drive, the installation fails.

    Possible Causes

    Two drive selection operations are performed. After you click Cancel and then selects another drive, the drive information is incorrect. As a result, the installation fails.


    Directly select the target drive for custom partitioning. Do not frequently cancel the operation. If you have to cancel and select another drive, you are advised to restart the installation procedure.

    Learn More About the Issue at


    vmcore Fails to Be Generated by Kdump on the PM with LSI MegaRAID Controller Card Installed


    After the Kdump service is deployed, kernel breaks down due to the manual execution of the echo c > /proc/sysrq-trigger command or kernel fault. When Kdump attempts to boot into the second kernel, an error "BRCM Debug mfi stat 0x2d, data len requested/completed 0x200/0x0" is reported by the MegaRAID driver, as shown in the following figure. As a result, vmcore fails to be generated.

    Error information

    Possible Causes

    The reset_devices boot parameter is configured by default, making the MegaRAID controller card or drive faulty during second kernel startup. An error is reported when the vmcore file is dumped to the array controlled by the MegaRAID controller. As a result, vmcore fails to be generated.


    Delete the reset_devices parameter in the /etc/sysconfig/kdump file on the PM, as shown in the following figure. In this way, the I/O request will be responded when the MegaRAID driver resets the device during the second kernel startup, and vmcore will be successfully generated.

    Deleting reset_devices

    Bug Catching

    Buggy Content

    Bug Description

    Submit As Issue

    It's a little complicated....

    I'd like to ask someone.


    Just a small problem.

    I can fix it online!

    Bug Type
    Specifications and Common Mistakes

    ● Misspellings or punctuation mistakes;

    ● Incorrect links, empty cells, or wrong formats;

    ● Chinese characters in English context;

    ● Minor inconsistencies between the UI and descriptions;

    ● Low writing fluency that does not affect understanding;

    ● Incorrect version numbers, including software package names and version numbers on the UI.


    ● Incorrect or missing key steps;

    ● Missing prerequisites or precautions;

    ● Ambiguous figures, tables, or texts;

    ● Unclear logic, such as missing classifications, items, and steps.


    ● Technical principles, function descriptions, or specifications inconsistent with those of the software;

    ● Incorrect schematic or architecture diagrams;

    ● Incorrect commands or command parameters;

    ● Incorrect code;

    ● Commands inconsistent with the functions;

    ● Wrong screenshots.

    Risk Warnings

    ● Lack of risk warnings for operations that may damage the system or important data.

    Content Compliance

    ● Contents that may violate applicable laws and regulations or geo-cultural context-sensitive words and expressions;

    ● Copyright infringement.

    How satisfied are you with this document

    Not satisfied at all
    Very satisfied
    Click to create an issue. An issue template will be automatically generated based on your feedback.
    Bug Catching
    编组 3备份