FAQs
Why Does openEuler Fail to Start After I Install It to the Second Disk?
Symptom
The OS is installed on the second disk sdb during the installation. The openEuler fails to be started.
Possible Cause
When openEuler is installed to the second disk, MBR and GRUB are installed to the second disk sdb by default. The following two situations may occur:
- openEuler installed on the first disk is loaded and started if it is complete.
- openEuler installed on the first disk fails to be started from hard disks if it is incomplete.
The preceding two situations occur because the first disk sda is booted by default to start openEuler on the BIOS window. If openEuler is not installed on the sda disk, system restart fails.
Solution
This problem can be solved using either of the following two methods:
- During the installation of openEuler, select the first disk or both disks, and install the boot loader on the first disk sda.
- After installing openEuler, restart it by modifying the boot option on the BIOS window.
Why Does openEuler Enter Emergency Mode After It Is Powered On?
Symptom
openEuler enters emergency mode after it is powered on.
Possible Causes
Damaged OS files result in disk mounting failure, or overpressured I/O results in disk mounting timeout (threshold: 90s).
An unexpected system power-off, and low I/O performance of disks may also cause the problem.
Solution
Enter the password of the root account to log in to openEuler.
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 the system is powered off or a disk is faulty, run the fsck command to check file systems. Run the fsck.ext3 -h and fsck.ext4 -h commands to view the usage method of the fsck tool.
If you want to disable the timeout mechanism of disk 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
Failed to Reinstall openEuler When a Logical Volume Group That Cannot Be Activated Has Existed in openEuler
Symptom
After a disk fails, openEuler fails to be reinstalled because a logical volume group that cannot be activated has existed in openEuler.
Possible Cause
During the installation of openEuler, a logical volume group cannot be activated.
Solution
Before reinstalling openEuler, restore the abnormal logical volume group to the normal status or clear it. The following uses an example:
Restore the logical volume group.
Run the following command to clear the active 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 testvg32947Run the following command to recreate a physical volume based on the backup file:
pvcreate --uuid JT7zlL-K5G4-izjB-3i5L-e94f-7yuX-rhkLjL --restorefile /etc/lvm/backup/testvg32947 /dev/sdcRun the following command to restore the logical volume group information:
vgcfgrestore testvg32947Run the following command to reactivate the logical volume group:
vgchange -ay testvg32947
Run the following commands to clear the logical volume group:
vgchange -a n testvg32947 vgremove -y testvg32947
An Exception Occurs During the Selection of the Installation Source
Symptom
After the selection of the installation source, the message "Error checking software selection" is displayed.
Possible Cause
This is because the software package dependency in the installation source is abnormal.
Solution
Check whether the installation source is abnormal. Use the new installation source.
How Do I Manually Enable the kdump Service?
Symptom
Run the systemctl status kdump command. The following information is displayed, indicating that no memory is reserved.
Possible Cause
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.
Solution
For the scenario where the OS has been installed
Add crashkernel=1024M,high to /boot/efi/EFI/openEuler/grub.cfg.
Restart the system for configuration to take effect.
Run the following command to check the kdump status:
systemctl status kdumpIf 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 table describes the parameters of the memory reserved for the kdump kernel.
Table 1 crashkernel parameters
Failed to Selected Only One Disk for Reinstallation When openEuler Was Installed on a Logical Volume Consisting of Multiple Disks
Symptom
If openEuler was installed on a logical volume consisting of multiple disks, an error message will be displayed as shown in Figure 1 when you attempt to select one of the disks for reinstallation.
Possible Cause
The previous logical volume contains multiple disks. If you select one of the disks for reinstallation, the logical volume will be damaged.
Solution
The logical volume formed by multiple disks is equivalent to a volume group. Therefore, you only need to delete the corresponding volume group.
Press Ctrl+Alt+F2 to switch to the CLI and run the following command to find the volume group:
vgs
Run the following command to delete the volume group:
vgremove eulerosRun 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.
Failed to Install openEuler on an x86 PM in UEFI Mode due to Secure Boot Option Setting
Symptom
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 set to disabled), as shown in Figure 2.
Figure 2 Dialog box showing "No bootable device" 
Possible Cause
After secure boot is set to enabled, the mainboard verifies the boot program and OS. If the boot program and OS are not signed using the corresponding private key, the boot program and OS cannot pass the authentication of the built-in public key on the mainboard.
Solution
Access the BIOS, set secure boot to disabled, and reinstall the openEuler.
During the system startup, press F11 and enter the password Admin@9000 to access the BIOS.
Choose Administer Secure Boot.
Set Enforce Secure Boot to Disabled.
NOTE:
After Enforce Secure Boot is set to Disabled, save the settings, and exit. Then, reinstall the system.
The Installation Fails when a User Selects Two Drives on Which the OS Has Been Installed and Customizes Partitioning.
Symptom
During the OS installation, the OS has been installed on two drives. In this case, if you select one drive for customized partitioning, and click Cancel to perform customized partitioning on the other drive, the installation fails.
Cause Analysis
A user selects a drive for partitioning. After the user clicks Cancel and then selects the other drive, the drive information is incorrect. As a result, the installation fails.
Solution
Select the target drive for customized partitioning. Do not frequently cancel the operation. If you have to cancel and select another drive, you are advised to reinstall the OS.
Learn More About the Issue at:
https://gitee.com/src-openeuler/anaconda/issues/I29P84?from=project-issue
