Ah yeah, that would explain it then :)
Today after rebooting the Ovh server i got the grub prompt Code: grub> Didn't know why and as i was not able to view the kernels menu when booting to be able to try with another kernel i just open a support ticket ... They fix it and as they told me they just used an Ovh kernel.... I am wondering if there is any idea why and if i can run any commands to provide any output that may help the related Centminmod fix If yes please let me know....
All the commands would be in this thread. Did you reboot after doing a yum/yum kernel update ? Did you do the manual grub2-mkconfig rebuild after yum update before reboot ? Is this a new OVH server just setup or old one that has been running for months without issue ? You using NVMe SSD based OVH server ? Which model? Output for Code (Text): lscpu Code (Text): df -hT Code (Text): ls -lah /boot/efi/EFI/centos/ Code (Text): efibootmgr -v you can check your kernel yum history via command Code (Text): yum history list kernel -q
Yes. I update the system yesterday and it was a kernel update on the list. No Old one Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian CPU(s): 8 On-line CPU(s) list: 0-7 Thread(s) per core: 2 Core(s) per socket: 4 Socket(s): 1 NUMA node(s): 1 Vendor ID: GenuineIntel CPU family: 6 Model: 158 Model name: Intel(R) Xeon(R) CPU E3-1270 v6 @ 3.80GHz Stepping: 9 CPU MHz: 3808.084 CPU max MHz: 4200.0000 CPU min MHz: 800.0000 BogoMIPS: 7584.00 Virtualization: VT-x L1d cache: 32K L1i cache: 32K L2 cache: 256K L3 cache: 8192K NUMA node0 CPU(s): 0-7 Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb invpcid_single pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm mpx rdseed adx smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp md_clear flush_l1d Filesystem Type Size Used Avail Use% Mounted on /dev/root ext4 96G 65G 27G 71% / devtmpfs devtmpfs 16G 0 16G 0% /dev tmpfs tmpfs 16G 0 16G 0% /dev/shm tmpfs tmpfs 16G 18M 16G 1% /run tmpfs tmpfs 16G 0 16G 0% /sys/fs/cgroup /dev/nvme0n1p1 vfat 510M 3.6M 507M 1% /boot/efi tmpfs tmpfs 16G 164K 16G 1% /tmp /dev/md3 ext4 316G 194G 106G 65% /home tmpfs tmpfs 3.2G 0 3.2G 0% /run/user/0 total 1.1M drwxr-xr-x 3 root root 4.0K Sep 23 2019 . drwxr-xr-x 3 root root 4.0K Oct 27 2017 .. drwxr-xr-x 2 root root 4.0K Sep 23 2019 fonts -rwxr-xr-x 1 root root 1.0K Mar 19 23:13 grubenv -rwxr-xr-x 1 root root 1.1M Aug 8 2019 grubx64.efi BootCurrent: 0003 Timeout: 0 seconds BootOrder: 0003,0009,0008,0004,0006,0007,0002,0005,0000,0001 Boot0000* Enter Setup FvVol(cdbb7b35-6833-4ed6-9ab2-57d2acddf6f0)/FvFile(462caa21-7614-4503-836e-8ab6f4662331) Boot0001 Boot Device List FvVol(cdbb7b35-6833-4ed6-9ab2-57d2acddf6f0)/FvFile(eec25bdc-67f2-4d95-b1d5-f81b2039d11d)$.I.B.T... Boot0002 Network Boot FvVol(cdbb7b35-6833-4ed6-9ab2-57d2acddf6f0)/FvFile(9e09e6fd-4e16-6468-9b78-bdaeaf609cff)$.I.B.T... Boot0003* UEFI IPv4: Intel I210 Network 00 at Baseboard /Pci(0x1d,0x2)/Pci(0x0,0x0)/MAC(a4bf01176a44,0)/IPv4(0.0.0.00.0.0.0,0,0)N.....YM....R,Y. Boot0004* UEFI IPv6: Intel I210 Network 00 at Baseboard /Pci(0x1d,0x3)/Pci(0x0,0x0)/MAC(a4bf01176a45,0)/IPv6([::]:<->[::]:,0,0)N.....YM....R,Y. Boot0005* Launch EFI Shell FvVol(cdbb7b35-6833-4ed6-9ab2-57d2acddf6f0)/FvFile(c57ad6b7-0515-40a8-9d21-551652854e37) Boot0006* UEFI IPv4: Intel I210 Network 00 at Baseboard 2 /Pci(0x1d,0x3)/Pci(0x0,0x0)/MAC(a4bf01176a45,0)/IPv4(0.0.0.00.0.0.0,0,0)N.....YM....R,Y. Boot0007* UEFI IPv6: Intel I210 Network 00 at Baseboard 2 /Pci(0x1d,0x2)/Pci(0x0,0x0)/MAC(a4bf01176a44,0)/IPv6([::]:<->[::]:,0,0)N.....YM....R,Y. Boot0008* centos HD(1,GPT,90180b09-3f5b-4d0d-a840-5f9d1ae23f73,0x800,0xff800)/File(\EFI\centos\grubx64.efi) Boot0009* centos7_64 (GRUB) (first drive nvme0n1) HD(1,GPT,90180b09-3f5b-4d0d-a840-5f9d1ae23f73,0x800,0xff800)/File(\EFI\centos\grubx64.efi) ID | Login user | Date and time | Action(s) | Altered ------------------------------------------------------------------------------- 195 | root <root> | 2020-03-19 23:12 | E, I, U | 17 185 | root <root> | 2020-02-06 17:57 | E, I, U | 25 168 | root <root> | 2019-12-08 18:38 | E, I, U | 6 166 | root <root> | 2019-12-04 23:07 | E, I, U | 24 162 | root <root> | 2019-12-04 02:07 | E, I, U | 45 EE 152 | root <root> | 2019-09-23 02:06 | E, I, O, U | 277 EE 145 | root <root> | 2019-08-05 22:07 | E, I, O, U | 107 EE 138 | root <root> | 2019-02-24 05:13 | E, I, O, U | 283 EE 124 | root <root> | 2018-10-18 13:44 | E, I, U | 34 EE 123 | root <root> | 2018-08-28 10:28 | E, I, U | 42 EE 120 | root <root> | 2018-07-21 05:50 | E, I, U | 19 118 | root <root> | 2018-06-21 12:23 | E, I, U | 15 EE 117 | root <root> | 2018-06-13 10:43 | I, O, U | 269 EE 113 | root <root> | 2018-03-22 09:58 | I, U | 30 102 | root <root> | 2018-01-26 10:32 | I, U | 36 EE 101 | root <root> | 2018-01-07 01:27 | I, U | 53 EE 64 | System <unset> | 2017-10-27 23:44 | Install | 1 EE 63 | System <unset> | 2017-10-27 23:42 | Erase | 5 EE 60 | root <root> | 2017-09-14 11:47 | Erase | 1 2 | System <unset> | 2017-09-14 11:44 | I, U | 28 1 | System <unset> | 2017-09-14 11:40 | Install | 294 Thanks !
classic case of /boot/efi/EFI/centos/grub.cfg missing as originally outlined in this thread so manually rebuild it via grub2-mkconfig would of been needed after kernel update. Centmin Mod 123.09beta01 on centmin.sh runs would try to do this automatcially if relevant OVH + NVMe criteria are present to do so. But wonder if had that in place prior to reboot or if kernel updating reverted that and required centmin.sh menu run/auto fix again (or manual grub2-mkconfig rebuild) looks like CentOS 7.8 is released so that is what your yum updates were for ?
I think so....as on my other servers i got that update for sure. Not 100% sure for this server... Now i am getting: cat /etc/centos-release CentOS Linux release 7.7.1908 (Core) but i am not sure if they (OVH) revert it....or by using the Ovh kernel revert it in any way..
Do you recommend me to run manually before restarts the command: Code: grub2-mkconfig rebuild ? Can i run the above command from the grub> prompt also after the failed restart or is it from ssh only? Maybe latest Centminmod needs some adjustments to get that fixed automatically and help us? Thank you
no that is not the command, you need to re-read this thread to learn how to get out of grub command prompt first and then to properly rebuild your grub.cfg file as the path to it is dependent on how NVMe disk was installed/configured Sysadmin - Grub Help?
Well 4 years after the original post, I've just ran into this again on my backup server from OVH. Single NVMe drive and 4 x 4TB HDD in RAID10. First reboot since setting it up, and I'd assumed it wouldn't have this issue without checking. Rescue mode and rebuild the missing grub config.
Wow still! Though alot of new servers don't have CentOS 7 anymore only CentOS 8 support at OVH. Or is this happening with CentOS 8 too?
The server was installed almost 2 years ago. I was trying to convert it to Alma using the Elevate package, but it’s ended in a right mess after 6 hours.