Elevate with linode kernel?
Hello!
I was evaluating whether to do elevate or install everything from scratch on a dnsonly server. Does the elevate check give me this warning? Do you think it is advisable to continue?
I tried switching to grub2, but linode just won't start.
2024-06-11 16:40:58 [WARN] *** Elevation Blocker detected: ***
The running kernel version (6.8.9-x86_64-linode164) does not match that of
the default boot entry (0-rescue-153a217486fe4be8a8dbd28db67ed581). This could be due to the kernel
being changed by an update, meaning that a reboot should resolve this.
However, this also could indicate that the system does not have control
over which kernel and early boot environment (initrd) is used upon
reboot, which is required to upgrade the operating system with this
script.If this message remains after a reboot, your server may have been
configured to boot into a particular kernel directly rather than to an
instance of the GRUB2 boot loader. This often happens to virtualized
servers, but physical servers also can have this problem under certain
configurations. Your provider may have a solution to allow booting into
GRUB2; contact them for further information.
-
Hey there! Since it's detected as a Blocker and not a Warning, you wouldn't be able to perform ELevate on the server in it's current state. It's possible they use a custom kernel setup, but I wouldn't be able to say for sure, but I would expect trying to change the type of kernel from a boot menu would keep the system from starting.
You can always just add another DNS server to the cluster and then decommission the old one once everything is up and running.
0 -
Hello Rex!
Today I'm a little stubborn and I want to see if I can do elevate.
I managed to boot with grub2 following linode's instructions https://www.linode.com/docs/products/compute/compute-instances/guides/manage-the-kernel/
And then, I have a new blocker. I added that line that Elevate asks me to change, following Linode's instructions. Is it safe to change it to true?2024-06-11 17:46:42 [WARN] *** Elevation Blocker detected: ***
Disabling the BLS boot entry format prevents the resulting system from
adding kernel updates to any boot loader configuration, because the old
utility responsible for maintaining native GRUB2 boot loader entries was
removed and replaced with a wrapper around the new utility, which only
understands BLS format. This means that the old kernel will be used on
reboot, unless the GRUB2 configuration file is manually edited to load the
new kernel. Furthermore, after a few kernel updates, the DNF package
manager may begin to remove old kernels, including the one still used in
the configuration file. If that happens, the system will fail to come back
after a subsequent reboot.The safe option is to remove the following line in /etc/default/grub:
GRUB_ENABLE_BLSCFG=false
or to change it so that it is set to "true" instead.
0 -
This is one I can't answer, because if I tell you the wrong thing your server won't be bootable :D
It would be best to ask Linode about that setting and how it interacts with their system and tools.
1 -
There is no time for weak people (I have backups) and I changed the line. Booted correctly. I also had to change the default line of grub2.
After all it seems that we are ready to elevate. I'll tell you tomorrow, today I'm sleepy.
[root@ns1 ~]# /scripts/elevate-cpanel --check
* 2024-06-11 18:05:14 [INFO] Successfully verified signature for cpanel (key types: release).
* 2024-06-11 18:05:16 [INFO] Checking EasyApache profile compatibility with AlmaLinux 8.
* 2024-06-11 18:05:16 [WARN] Skipping EA4 backup. EA4 does not appear to be enabled on this system
* 2024-06-11 18:05:16 [WARN] /boot/grub/grub.cfg is currently a symlink to /boot/grub2/grub.cfg. Your provider
may have added this to support booting your server using their own
instance of the GRUB2 bootloader, one which looks for its
configuration, boot entries, and modules in a different location from
where your operating system stores this data. In order to allow the
process to complete successfully, the upgrade process will rename the
current /boot/grub directory, re-create /boot/grub as a symlink to /boot/grub2,
and then copy as much of the old /boot/grub into /boot/grub2 as possible.
* 2024-06-11 18:05:17 [INFO] There are no known blockers to start the elevation process.
You can consider running:
/scripts/elevate-cpanel --start
[root@ns1 ~]#0 -
Glad to hear there's hope!
0 -
Total success, the Elevate process went perfectly. The ugliest part was between stage 3 and 4 that I spent about 9 minutes blindly because I didn't have ssh and the linode terminal didn't show anything. Then the light came back on and I was able to continue monitoring the process.
The DNS must have been down for about 20 minutes in total.
When Elevate finished, all I had to do was update cPanel to version 120 and that's it.
0 -
9 minutes is really quick for that stage, so that's great to hear! It is unsettling as the server doesn't seem to be doing anything, but it's working behind the scenes.
I'm glad to hear things went so well!
0 -
cPRex one last thing:
The elevated server send us one of these each hour, and one daily.
It is something we need to fix or ignore?
0 -
These are the contents of that cronjob.
[root@ns1 cron.hourly]# ll
total 4
-rwxr-xr-x. 1 root root 575 Apr 6 08:40 0anacron
[root@ns1 cron.hourly]# cat 0anacron
#!/bin/sh
# Check whether 0anacron was run today already
if test -r /var/spool/anacron/cron.daily; then
day=`cat /var/spool/anacron/cron.daily`
fi
if [ `date +%Y%m%d` = "$day" ]; then
exit 0
fi# Do not run jobs when on battery power
online=1
for psupply in AC ADP0 ; do
sysfile="/sys/class/power_supply/$psupply/online"if [ -f $sysfile ] ; then
if [ `cat $sysfile 2>/dev/null`x = 1x ]; then
online=1
break
else
online=0
fi
fi
done
if [ $online = 0 ]; then
exit 0
fi
/usr/sbin/anacron -s
[root@ns1 cron.hourly]#0 -
We see this with the logging tool once in a while after ELevate. Try this and see if that helps:
mv -v /dev/log /root/dev-log.bak
systemctl restart systemd-journald.service0 -
Hello!
Only changed the message.
0 -
Well that wasn't what I was hoping for. Any chance you'd like to make a ticket for this one?
0 -
Sure, #95282518
Thanks!
0 -
Thanks - I'm following along now!
0 -
I see we noted some possible kernel issues on the machine that you were going to check - let us know how it goes!
1 -
For the cron issue we created the following guide here:
https://support.cpanel.net/hc/en-us/articles/24172069954711-Cron-error-emails-after-Elevate
that explains how you can manually recreate the missing links, although I'm hoping the ELevate team comes up with an automatic solution.
0 -
Yes, I had totally ignored that. I never thought Almalinux 8 could be running with a Centos 7 Kernel. Even after several reboots.
1 -
@Benito I was running this on a new Linode instasnce built from a snapshot of my running Linode. I was stuck between 3-4. Switched to the latest Kernal in Linode configs and got SSH back. Got everything up and running but couldn't access cPanel/whm on the new ip before migrating the old ip to the new instance. How did you get past this? Did you just do a full standup migration and allowed you to see Cpanel/WHM?
0 -
Hello ReFresh
The entire Elevate process worked fine but my server was stuck with the Centos 7 Kernel. When we made it want to boot with the Almalinux 8 Kernel it didn't work. I could have put the Linode Kernel back and tried to recover it but I preferred not to waste any more time and reinstalled everything again directly with Almalinux 9.
0 -
Benito So during the reinstall did you go back to the centOS snap shot and skip Alma 8 going straight to 9? Was there a guide you followed somewhere?
0 -
No, I did not restore my Snapshot because that would be going back to Centos 7 and starting the whole Elevate process. I directly reinstalled the VPS from scratch with an Almalinux 9 image. Then I installed cPanel DNSOnly, configured everything and added the server to the cluster again.
0
Please sign in to leave a comment.
Comments
21 comments