Kernel update not applying - WHM/cPanel Installation

[Hefin]

My issue is similar to this one

I’ve spun up a copy of AlmaLinux release 8.7 (Stone Smilodon) on a remote server, with the intention of running WHM/cPanel on it (WHM/cPanel recommends this OS). WHM/cPanel which I’ve installed now but WHM is constantly complaining via a notification on the dashboard that the server requires a reboot, of which I have done many now:

WHM notification

I have run the command sudo dnf list kernel to check the list of available kernel versions on the server

Installed Packages
kernel.x86_64   4.18.0-372.9.1.el8                @baseos
kernel.x86_64   4.18.0-425.10.1.el8_7          @baseos
kernel.x86_64   4.18.0-425.13.1.el8_7           @baseos

Running sudo grubby --default-kernel in order to check the kernal which is selected to be run on boot I get:

/boot/vmlinuz-4.18.0-425.13.1.el8_7.x86_64

which is the latest kernel. After multiple reboots and running the command sudo dnf updateinfo

Results in:

Last metadata expiration check: 3:15:16 ago on Thu 02 Mar 2023 10:33:41 AM UTC.
Updates Information Summary: available
    1 Security notice(s)
        1 Important Security notice(s)
    1 Bugfix notice(s)
Security: kernel-core-4.18.0-425.13.1.el8_7.x86_64 is an installed security update
Security: kernel-core-4.18.0-425.10.1.el8_7.x86_64 is the currently running version

It appears the server is booting to run:

• kernel-core-4.18.0-425.10.1.el8_7.x86_64 instead of the latest kernel
• kernel-core-4.18.0-425.13.1.el8_7.x86_64

Issuing the command uname -r to get the running kernal I get

4.18.0-425.10.1.el8_7.x86_64

I’m expecting kernel-core-4.18.0-425.13.1.el8_7.x86_64 to be running on reboot. Any help is much appreciated, I’m a bit of a Linux noob, hence wanting to run a web control panel like WHM hoping to reduce the server management side of things with this product on the server.

[sej7278]

seems to be a common thread with all web panels - people have reported it with cockpit and webmin lately.

what does this return:

sudo grubby --info=DEFAULT
sudo grubby --default-kernel
sudo grubby --default-index
sudo grubby --info=ALL | grep -E '^(index|kernel)='

[Hefin]

Thanks for the reply @sej7278

Yeah, this issue is weird.

In order to rule out any ambiguity or shenanigans that any web hosting software may or may not be causing I’ve applied fresh image of AlmaLinux 8 to the box today. Fresh & clean nothing on it apart from a clean AL8 OS on it to get to the bottom of this issue.

Following the new image of AlamaLinux 8 that was applied, these are the only commands that have been run on this box.

Get the currently running Kernel version:

COMMAND: uname -r
OUTPUT 4.18.0-425.10.1.el8_7.x86_64

Get the list of default kernel selected to load from the grublist/bootloader
COMMAND: sudo grubby --default-kernel
OUTPUT /boot/boot/vmlinuz-4.18.0-425.10.1.el8_7.x86_64

Get list of Kernel versions for OS:
COMMAND: sudo dnf list kernel
OUTPUT

Last metadata expiration check: 0:23:20 ago on Mon 06 Mar 2023 10:25:43 AM UTC.
Installed Packages
kernel.x86_64 4.18.0-348.12.2.el8_5 @baseos
kernel.x86_64 4.18.0-372.9.1.el8 @baseos
kernel.x86_64 4.18.0-425.10.1.el8_7 @baseos
Available Packages
kernel.x86_64 4.18.0-425.13.1.el8_7 @baseos

Update Packages and Kernal
COMMAND: sudo dnf update
OUTPUT

Last metadata expiration check: 0:31:34 ago on Mon 06 Mar 2023 10:25:43 AM UTC.
Dependencies resolved.
Package Architecture Version Repository Size
Installing:
kernel x86_64 4.18.0-425.13.1.el8_7 baseos 8.8 M
kernel-core x86_64 4.18.0-425.13.1.el8_7 baseos 41 M
kernel-devel x86_64 4.18.0-425.13.1.el8_7 baseos 22 M
kernel-modules x86_64 4.18.0-425.13.1.el8_7 baseos 33 M

Also installed other non-kernel package updated

Check the default kernal again due to load to see if it’s the new one
COMMAND: sudo grubby --default-kernel
OUTPUT /boot/vmlinuz-4.18.0-425.13.1.el8_7.x86_64 - Great updated kernel set to run

Reboot the box.

Get the currently running Kernel version:

COMMAND: uname -r
OUTPUT 4.18.0-425.10.1.el8_7.x86_64 - Not good still old Kernel

Running the commands you suggested @sej7278

COMMAND: sudo grubby --info=DEFAULT
OUTPUT:

index=0
kernel="/boot/vmlinuz-4.18.0-425.13.1.el8_7.x86_64"
args="ro crashkernel=auto resume=/dev/mapper/almalinux-swap rd.lvm.lv=almalinux/root rd.lvm.lv=almalinux/swap $tuned_params"
root="/dev/mapper/almalinux-root"
initrd="/boot/initramfs-4.18.0-425.13.1.el8_7.x86_64.img $tuned_initrd"
title="AlmaLinux (4.18.0-425.13.1.el8_7.x86_64) 8.7 (Stone Smilodon)"
id="5b3d368fc52a4cf7ad96fb517a77eb3b-4.18.0-425.13.1.el8_7.x86_64"

COMMAND: sudo grubby --default-kernel
OUTPUT: /boot/vmlinuz-4.18.0-425.13.1.el8_7.x86_64

COMMAND: sudo grubby --default-index
OUTPUT: 0

COMMAND: sudo grubby --info=ALL | grep -E '^(index|kernel)='
OUTPUT:

index=0
kernel="/boot/vmlinuz-4.18.0-425.13.1.el8_7.x86_64"
index=1
kernel="/boot/boot/vmlinuz-4.18.0-425.10.1.el8_7.x86_64"
index=2
kernel="/boot/boot/vmlinuz-4.18.0-372.9.1.el8.x86_64"
index=3
kernel="/boot/boot/vmlinuz-0-rescue-5b3d368fc52a4cf7ad96fb517a77eb3b"

I also spun up a small test instance of AlmaLinux 8 via AWS on a VPS. . The COMMAND: sudo dnf update is simply enough for it to update the packages and kernels and a reboot, boots the new kernel with no issues. Obviously kernel updates should be this simple.

At the moment I starting to think it’s a weird datacentre/server configuration issue that the server/hosting company I have the server leased with should be looking into.

Do you think this is the case, everything is telling me that the AlmaLinux is set to run the updated Kernel but the server simply looks to ignore the grub list/bootloader on reboot.

[toracat]

Could you confirm that the fresh & clean image of AlmaLinux 8 does not have WHM/cPanel on it?

[Hefin]

No, just Almalinux 8 nothing else on the image. I’ve raised this with the server hosting provider. As talking with you guys it all appears a server-level issue, nothing to do this the OS, grub list defaults all appear to be correct to load the latest installed kernel, but the server appears to be ignoring the grublist on boot and booting the original kernel.

Response from my server provider
We have been investigating the issue and in an attempt to replicate this, we have spun up a test Server with Alma Linux 8 and we found that this image/server actually deployed with the latest kernel version straight away. It may be a possibility that the issue lies with the specific image for Bare Metal servers, however these take a little longer to deploy. We are currently in the process of deploying a Bare Metal server with Alma Linux 8 so that we can attempt to replicate this again. If the issue persists we will then deploy this to our build team for investigation.

Then there most recent message was:

"An engineer here has built a bare metal server with Alma 8 and updated the kernel successfully as shown below

[root@3B1E458 ~]# history
1 uname -r
2 grubby --default-kernel
3 dnf list kernel
4 dnf update
5 dnf list kernel
6 grubby --default-kernel
7 reboot
8 uname -r
9 history
[root@3B1E458 ~]# uname -r
*4.18.0-425.13.1.el8_7.x86_64

My colleague is going to take a further look into the server you have with this issue , are you able to provide access to this server so we can investigate a bit more?*"

It should be as easy as that. I’ve given them full access to the server now.

So the server provider is now looking further into the box itself. Hopefully, I’ll find out more at some point tomorrow, about what was wrong and get a fix. Will let you know. Thanks for the help.

[sej7278]

that is very weird, i’d love to know what it is if they figure it out!

i’m assuming its not some weird shared kernel thing like openvz, and you’re not stuck with the kernel that they’re running on the host?

or some weird bootloader that’s ignoring grub, i know there were some EFI issues in early 8.x releases with grub2-mkconfig being needed as grubby didn’t work with UEFI at that point (wasn’t updating /boot/loader/entries/ or something)

[Hefin]

It’s a bare metal server so should rule out any weird virtualization with Kernel sharing.

My money is on what you said ‘some weird bootloader that’s ignoring grub’.

The hosting company allows you to reimage the box at any time and deploy only their pre-approved selection of OS images.

They tested this image on another bare metal server today and updated the kernel no issues, so it appears the issue is isolated to this server potentially.

Running
cat /etc/os-release

I get

NAME="AlmaLinux"
VERSION="8.7 (Stone Smilodon)"
ID="almalinux"
ID_LIKE="rhel centos fedora"
VERSION_ID="8.7"
PLATFORM_ID="platform:el8"
PRETTY_NAME="AlmaLinux 8.7 (Stone Smilodon)"
ANSI_COLOR="0;34"
LOGO="fedora-logo-icon"
CPE_NAME="cpe:/o:almalinux:almalinux:8::baseos"
HOME_URL="https://almalinux.org/"
DOCUMENTATION_URL="https://wiki.almalinux.org/"
BUG_REPORT_URL="https://bugs.almalinux.org/"

ALMALINUX_MANTISBT_PROJECT="AlmaLinux-8"
ALMALINUX_MANTISBT_PROJECT_VERSION="8.7"
REDHAT_SUPPORT_PRODUCT="AlmaLinux"
REDHAT_SUPPORT_PRODUCT_VERSION="8.7"

The server spec is

Yeah it’s on the hosting company to fix now which takes the issue from me at least so I’m hopeful they’ll sort or I’ll just junk the rolling contract on this box and try again on another server.

Hopefully get a fix from them tomorrow (fingers crossed). I’ll let you know what they find. I’ll likely be immediately re-imaging the box again and attempting to update the kernel to check that kernel updates are getting correctly loaded.

Some server spec from running lshw command (is there potential to be a hardware incompatibility issue)

    product: 520002 (To Be Filled By O.E.M.)
    vendor: CI
    version: 4500108848
    serial: CI01202100296
    width: 64 bits
    capabilities: smbios-3.3.0 dmi-3.3.0 smp vsyscall32
    configuration: boot=normal family=To Be Filled By O.E.M. sku=To Be Filled By O.E.M. uuid=8c92160e-5701-4948-b006-d05099f8079c
  *-core
       description: Motherboard
       product: X470D4U2/1N1
       vendor: ASRockRack
       physical id: 0
       serial: 204964860000191
     *-firmware
          description: BIOS
          vendor: American Megatrends International, LLC.
          physical id: 0
          version: L4.09E
          date: 09/28/2022
          size: 64KiB
          capacity: 16MiB
          capabilities: pci upgrade shadowing cdboot bootselect socketedrom edd int13floppynec int13floppytoshiba int13floppy360 int13floppy1200 int13floppy720 int13floppy2880 int5printscreen int14serial int17printer int10video acpi usb biosbootspecification uefi
     *-memory
          description: System Memory
          physical id: 1d
          slot: System board or motherboard
          size: 32GiB
          capabilities: ecc
          configuration: errordetection=multi-bit-ecc
        *-bank:0
             description: [empty]
             product: Unknown
             vendor: Unknown
             physical id: 0
             serial: Unknown
             slot: DIMM 0
        *-bank:1
             description: DIMM DDR4 Synchronous Unbuffered (Unregistered) 2666 MHz (0.4 ns)
             product: M391A2K43BB1-CTD
             vendor: Samsung
             physical id: 1
             serial: 181D94ED
             slot: DIMM 1
             size: 16GiB
             width: 64 bits
             clock: 2666MHz (0.4ns)
        *-bank:2
             description: [empty]
             product: Unknown
             vendor: Unknown
             physical id: 2
             serial: Unknown
             slot: DIMM 0
        *-bank:3
             description: DIMM DDR4 Synchronous Unbuffered (Unregistered) 2666 MHz (0.4 ns)
             product: M391A2K43BB1-CTD
             vendor: Samsung
             physical id: 3
             serial: 181D946F
             slot: DIMM 1
             size: 16GiB
             width: 64 bits
             clock: 2666MHz (0.4ns)
     *-cache:0
          description: L1 cache
          physical id: 20
          slot: L1 - Cache
          size: 384KiB
          capacity: 384KiB
          clock: 1GHz (1.0ns)
          capabilities: pipeline-burst internal write-back unified
          configuration: level=1
     *-cache:1
          description: L2 cache
          physical id: 21
          slot: L2 - Cache
          size: 3MiB
          capacity: 3MiB
          clock: 1GHz (1.0ns)
          capabilities: pipeline-burst internal write-back unified
          configuration: level=2
     *-cache:2
          description: L3 cache
          physical id: 22
          slot: L3 - Cache
          size: 32MiB
          capacity: 32MiB
          clock: 1GHz (1.0ns)
          capabilities: pipeline-burst internal write-back unified
          configuration: level=3
     *-cpu
          description: CPU
          product: AMD Ryzen 5 PRO 3600 6-Core Processor
          vendor: Advanced Micro Devices [AMD]
          physical id: 23
          bus info: cpu@0
          version: 23.113.0
          serial: Unknown
          slot: AM4
          size: 4195MHz
          capacity: 4208MHz
          width: 64 bits
          clock: 100MHz
          capabilities: lm fpu fpu_exception wp vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp x86-64 constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 x2apic movbe popcnt aes xsave avx f16c rdrand lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt tce topoext perfctr_core perfctr_nb bpext perfctr_llc mwaitx cpb cat_l3 cdp_l3 hw_pstate ssbd mba ibpb stibp vmmcall fsgsbase bmi1 avx2 smep bmi2 cqm rdt_a rdseed adx smap clflushopt clwb sha_ni xsaveopt xsavec xgetbv1 xsaves cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local clzero irperf xsaveerptr wbnoinvd arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold avic v_vmsave_vmload vgif v_spec_ctrl umip rdpid overflow_recov succor smca sme sev sev_es cpufreq

The server has a X470D4U2-2T motherboard could potentially be a compatibility issue with that (don’t know, guessing wildly).

Spec sheet for the motherboard says

Does Support UEFI BOOT only be a cause of the issue?

[Hefin]

case your curious @sej7278

Latest message from the hosting company:

“I have built a server of same model and OS in a test account and replicated your problem, and I have also picked a different server model and almalinux 8 where the issue does not exist.”

“This has helped identify that there is a build issue for the specific server model and OS that you have selected. I’m working with the team that governs our build images now to get this resolved.”

So the OS image, wasn’t playing ball with this server type.

[sej7278]

there was a missing “kernel” package in the minimal image of 8.7 so the team built new ISO’s that included it (not just kernel-core) e.g. AlmaLinux-8.7-update-1-x86_64-minimal.iso that might be worth exploring, but sounds like its probably just how the provider configured their image for that hardware.

bit odd it would present this way though, still smells of a bootloader thing, UEFI was a bit of a feature preview in EL8.

[Hefin]

Today’s hosting provider message:

`It looks like further progress on identifying the issue has been made, but there is no direct solution to the build image as of yet.

There is a work around. For some reason as part of the issue, when you force grub to reconfigure, it’s writing the new configuration which includes “4.18.0-425.13.1.el8_7.x86_64” to /boot/grub2/grub.cfg - But this is not what the server is using when it boots.

So running:

grub2-mkconfig Writes to: /boot/grub2/grub.cfg (Which is not used in this build)

We have to tell it where to write the file:

grub2-mkconfig -o /boot/efi/EFI/almalinux/grub.cfg

After a reboot:

[root@832B2D5 ~]# uname -r
4.18.0-425.13.1.el8_7.x86_64

So in a nutshell grub file is getting written correctly is /boot/grub2/ the expected normal directory for this grub file? But the bootloader is using another location to pick up that config from the /boot/efi/EFI/almalinux/ directory.

[jlehtone]

@Hefin

So in a nutshell grub file is getting written correctly is /boot/grub2/ the expected normal directory for this grub file? But the bootloader is using another location to pick up that config from the /boot/efi/EFI/almalinux/ directory.

On el7, el8, and el9 the EFI-version of GRUB binary placed in /boot/efi/EFI/${vendor}/ directory does look for grub.cfg at least from /boot/efi/EFI/${vendor}/.

Similarly, the legacy GRUB binary in /boot/grub2/ does look from /boot/grub2/.

That is obviously a bit inconvenient for maintenance of the config file.

On el9 the file in /boot/efi/EFI/${vendor}/ is essentially a redirector stub that
includes the /boot/grub2/grub.cfg

Hence, on el9 one can write/update the /boot/grub2/grub.cfg regardless of boot mode.

[Hefin]

@jlehtone Thanks for the info on the specifics grub directories and specifics.

Hopefully when I get this box back, I’ll have a poke around in these directories for the grub configs. Double check things are updating nicely.

My chosen webpanel WHM/cPanel supports and actively recommends al8 (after CentOS changed there bu$ine$$ model) which is why I’m on it. Looks like a solid disto. Looks as though AL 8 has a mature ecosystem of software and packages available in its repo’s.

And AlmaLinux 8 will be supported until 2029 which is awesome!

Crazy it’s community-driven enterprise-level operating system! Hope will be around for a long time and I can get some experience with it, I’m linux newbie, but it’s a nice breath of fresh air to get away from mirco$oft stuff. Although I miss GUI’s

Eventually, I’d like to get confident enough to get a wicked docker web-server up and running. With something portainer running on it.

But at the moment going to get my handheld with WHM/cPanel for the time being.

[Hefin]

Looks as though the server hosting company’s image engineer is having trouble working out why it’s writing to the wrong grub config file. The hosting company is suggesting a potential workaround which is to put the command:

grub2-mkconfig -o /boot/efi/EFI/almalinux/grub.cfg

On a daily cron job so the grub gets copied to the correct location and gets picked up on server boot.

Seems like a decent’ish workaround to me. Just wondering if anyone could see any potential gotcha’s with using the workaround in production use of the server? But it seems straight forward that it wouldn’t give me any hassle in the future?

[sej7278]

putting it in a daily cronjob seems absurd to me, i think once you run it once it fixes things, or at worst you’d only need to do it after a kernel update before you reboot

[Hefin]

Ta, haven’t put it on a cron job, just a issued the copy command. I guess the Kernel updates aren’t too frequent, once a month at most. If I have to run it 6-7 times a year like this no big deal. Thanks for your help @sej7278

[Hefin]

I reinstalled the a clean copy of the WHM/cPanel today and experienced an unexpected crash during the day the startup log is:

journalctl -p err -b
-- Logs begin at Tue 2023-03-14 10:01:55 UTC, end at Tue 2023-03-14 10:09:02 UTC. --
Mar 14 10:02:00 uk-cpanel.wpfreelancer.co.uk systemd[1]: Failed to start Rebuild Hardware Database.
Mar 14 10:02:01 uk-cpanel.wpfreelancer.co.uk systemd-tmpfiles[1116]: fchmod() of /home failed: Read-only file system
Mar 14 10:02:01 uk-cpanel.wpfreelancer.co.uk systemd-tmpfiles[1116]: Failed to create directory or subvolume "/var/lib/cni/networks": No such file or directory
Mar 14 10:02:01 uk-cpanel.wpfreelancer.co.uk systemd-tmpfiles[1116]: /tmp/.X11-unix does not exist and cannot be created as the file system is read-only.
Mar 14 10:02:01 uk-cpanel.wpfreelancer.co.uk systemd-tmpfiles[1116]: /tmp/.ICE-unix does not exist and cannot be created as the file system is read-only.
Mar 14 10:02:01 uk-cpanel.wpfreelancer.co.uk systemd-tmpfiles[1116]: /tmp/.XIM-unix does not exist and cannot be created as the file system is read-only.
Mar 14 10:02:01 uk-cpanel.wpfreelancer.co.uk systemd-tmpfiles[1116]: /tmp/.font-unix does not exist and cannot be created as the file system is read-only.
Mar 14 10:02:01 uk-cpanel.wpfreelancer.co.uk systemd-tmpfiles[1116]: /tmp/.Test-unix does not exist and cannot be created as the file system is read-only.
Mar 14 10:02:01 uk-cpanel.wpfreelancer.co.uk systemd-tmpfiles[1116]: rm(/var/lib/rpm/__db.001): Read-only file system
Mar 14 10:02:01 uk-cpanel.wpfreelancer.co.uk systemd-tmpfiles[1116]: rm(/var/lib/rpm/__db.002): Read-only file system
Mar 14 10:02:01 uk-cpanel.wpfreelancer.co.uk systemd-tmpfiles[1116]: rm(/var/lib/rpm/__db.003): Read-only file system
Mar 14 10:02:01 uk-cpanel.wpfreelancer.co.uk systemd-tmpfiles[1116]: rm_rf(/var/tmp/systemd-private-73a0ad34b0ba4beca4676c8b0605e0b9-chronyd.service-dPEBeZ): Read-only file system
Mar 14 10:02:01 uk-cpanel.wpfreelancer.co.uk auditd[1133]: Couldn't open log file /var/log/audit/audit.log (Read-only file system)
Mar 14 10:02:01 uk-cpanel.wpfreelancer.co.uk auditd[1119]: Cannot daemonize (Success)
Mar 14 10:02:01 uk-cpanel.wpfreelancer.co.uk systemd[1]: Failed to start Security Auditing Service.
Mar 14 10:02:01 uk-cpanel.wpfreelancer.co.uk systemd-update-utmp[1157]: Failed to write utmp record: Read-only file system
Mar 14 10:02:01 uk-cpanel.wpfreelancer.co.uk systemd[1]: Failed to start Update UTMP about System Boot/Shutdown.
Mar 14 10:02:01 uk-cpanel.wpfreelancer.co.uk kernel: snd_hda_intel 0000:2c:00.4: no codecs found!
Mar 14 10:02:02 uk-cpanel.wpfreelancer.co.uk systemd[1]: Failed to start mailman services.
Mar 14 10:03:16 uk-cpanel.wpfreelancer.co.uk systemd[1]: Failed to start cPanel Greylisting Daemon.
Mar 14 10:03:16 uk-cpanel.wpfreelancer.co.uk systemd[1]: Failed to start FPM service for cPanel Daemons.
Mar 14 10:03:51 uk-cpanel.wpfreelancer.co.uk kernel: ipmi_si IPI0001:00: There appears to be no BMC at this location
Mar 14 10:05:27 uk-cpanel.wpfreelancer.co.uk systemd[2227]: Failed to start Mark boot as successful.

Some concerning issues around “Rebuild Hardware Database”, “Security Auditing Service”, “Update UTMP about System Boot/Shutdown”

Could these errors could be caused by a corrupted file system, a failed hard drive, or a hardware issue?

[sej7278]

yeah all of those readonly filesystems mean there’s a disk error generally

[Hefin]

@sej7278

I found this article on cPanel forums which lists steps to remove and rebuild the tmp disks.

I ran through the steps in the article that remove the tmpDSK file and then rebuild it.

Now when I run journalctl -p err -b

[root@uk-cpanel ~]# journalctl -p err -b
-- Logs begin at Fri 2023-03-17 04:10:22 UTC, end at Fri 2023-03-17 04:31:01 UTC. --
Mar 17 04:10:29 uk-cpanel.wpfreelancer.co.uk kernel: snd_hda_intel 0000:2c:00.4: no codecs found!
Mar 17 04:10:29 uk-cpanel.wpfreelancer.co.uk systemd[1]: Failed to start mailman services.
Mar 17 04:11:44 uk-cpanel.wpfreelancer.co.uk systemd[1]: Failed to start cPanel Greylisting Daemon.
Mar 17 04:11:45 uk-cpanel.wpfreelancer.co.uk systemd[1]: Failed to start FPM service for cPanel Daemons.
Mar 17 04:12:20 uk-cpanel.wpfreelancer.co.uk kernel: ipmi_si IPI0001:00: There appears to be no BMC at this location
Mar 17 04:14:25 uk-cpanel.wpfreelancer.co.uk systemd[2427]: Failed to start Mark boot as successful.
Mar 17 04:14:25 uk-cpanel.wpfreelancer.co.uk systemd[2428]: Failed to start Mark boot as successful.

Things look a lot better all the tmp read-only file errors are gone. And I’m seeing very similar output to another al8 cPanel server I have access to!

Starting to get some more confidence in this new server build! It has the grub file issue, but (touch wood), it’s looking lots better now.

Thanks for your input and suggestions, it’s very much appreciated.