Note. If you are running DELL server, you probably have THIS issue.
We have found that's there's an issue on some Centos 7/8 installations with different hosting companies that prevents updating correct /boot/efi/EFI/centos/grub.cfg file and then boot into a newer kernel. After the conversion to a Cloudlinux issue stays the same.
Symptoms as follows:
1. The server has soft-raid 1 with /boot/efi partition and UEFI subsystem is used for boot.
2. File /etc/fstab contains /boot/efi partition which is mounted by LABEL or UUID, examples as follows:
- Mount by label:
[root@server ~]# cat /etc/fstab
UUID=837a2678-463b-4764-a9d0-7aadb6ebd334 / xfs defaults 0 1
UUID=8f13d21b-07a6-4bbf-9152-7ec63a8e4cc4 /boot xfs defaults 0 0
LABEL=EFI_SYSPART /boot/efi vfat defaults 0 1
- Mount by UUID:
[root@server ~]# cat /etc/fstab
/etc/fstab:
UUID=a9c13e70-0bfe-48db-a258-1d154eede5d0 / xfs defaults,uquota 0 0
UUID=f2fa53e0-8371-4aeb-a862-8e6ef2becefb /boot ext2 defaults 1 2
UUID=999C-7B59 /boot/efi vfat defaults,uid=0,gid=0,umask=0077,shortname=winnt 0 0
3. System has multiple partitions with the same LABEL or UUID
- Multiple LABEL's:
[root@server ~]# blkid | grep EFI_SYSPART
/dev/nvme0n1p1: SEC_TYPE="msdos" LABEL="EFI_SYSPART" UUID="B424-1E96" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="primary" PARTUUID="2fe5493d-96fd-4f61-95df-ef348cc9bfa8"
/dev/nvme1n1p1: SEC_TYPE="msdos" LABEL="EFI_SYSPART" UUID="B441-8529" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="primary" PARTUUID="6229c186-4be0-4900-98ff-27e334a1e0b0"
Multiple UUID's:
[root@server ~]# blkid | grep 999C-7B59
/dev/nvme0n1p1: SEC_TYPE="msdos" UUID="999C-7B59" TYPE="vfat" PARTLABEL="EFI System Partition" PARTUUID="ca702c35-9ee7-4f86-87bc-9f2aa40362a8"
/dev/nvme1n1p1: SEC_TYPE="msdos" UUID="999C-7B59" TYPE="vfat" PARTUUID="4049307c-35b8-45c5-bfa4-d74d6aee2edb"
If all three matches, this probably also means that the partition that's mounted is the second one, the first partition is not mounted but used as a boot partition by UEFI subsystem. Example below:
Proof that /dev/nvme1n1p1 is mounted:
Even If you see that right now /dev/nvme0n1p1 is mounted, that doesn't mean that you don't need to proceed with the fix, since during the next boot, /dev/nvme1n1p1 can be mounted.
/dev/nvme0n1p1 will be your boot disk under any circumstances.
What to do in order to fix?
1. Replace LABEL or UUID with a path to a partition, e.g /dev/nvme0n1p1.
- Old /etc/fstab:
New /etc/fstab:
2. Unmount previous /boot/efi with:
umount /boot/efi
3. Mount new /boot/efi:
mount -a
4. Reinstall CloudLinux kernel and modules:
yum reinstall $(rpm -qa | grep kernel | grep lve)
5. Reboot the server.
CloudLinux kernel should boot after these steps.
Comments
6 comments
Problem with booting after this fix still exist.
Using Remote KVM is the only way to boot server.
1. Got error "Unsupported returned from shimx64-cloudlinux.efi"
2. Choose second variant and successfully boot server.
Hello UAHosting,
Unfortunately, this article is not suitable for solving the problem you have mentioned.
Please follow this one:
https://cloudlinux.zendesk.com/hc/en-us/articles/5761040824860
Hello,
Thank you for the reply.
I am still having problems installing the cloudlinux on my almalinux based cPanel server.
===================================================================
[root@secure2 home]# bash cldeploy -k CL-XXYYZZ
Last available CloudLinux release: 8.7
Current system release: 8.7
WARNING! Your /etc/fstab configuration is not explicit about device mounting on boot/efi.
This is not a CL software issue but this potentially can cause problems with booting the CL kernel.
It is strongly recommended to contact your hosting provider before proceeding.
For details please read this article: https://cloudlinux.zendesk.com/hc/en-us/articles/360021620699
If you're certain that your configuration is correct, please run this script again, adding this flag: --skip-boot-check
Saiful, Have you followed the guide from this article? In any case, it's better to open a support request to check the issue in place.
Follow the step still can't :(
please advise? T.T
Thanks alot
Keith, the only possible reason for such an error is that rpm database is broken and the rpm command does not return installed packages. Better to create a support ticket so we can check. Or, let's jump to https://forum.cloudlinux.com/ which is better designed for communication and troubleshooting.
Please sign in to leave a comment.