Alma Elevate Boot Issue

[dstana]

Decided to attempt to run Elevate on my fleet, starting with one of the DNSonly servers. All checks were good before attempting to run the script. Made it to Step 4 and I've got a boot issue:

`error file '/boot/initramfs-4.10.0-477.21.1.e18._8.x86_64.img' not found.`

I did snapshot before running Elevate. Is it worth taking a look in that boogered up drive before just restoring it?

 

[cPRex]

Hey there! We did some testing on DNSOnly as part of this post, and it worked normally in our testing environment. It sounds like this specific issue is a problem with your system not properly detecting the kernel on the machine after the reboots, so I can't say for sure what would cause that.

 

[dstana]

Ok, I guess I'll do some more fooling around with it. Is 4.10.0-477.21.1.e18._8.x86_64 the correct kernel expected to be installed during the elevate process?

Also, is there a mechanism in the elevate script to pause before the reboot to stage 4? This would give me a chance to see what's going on before diving in, or snapshot it at that point as well so I can try a few different things if needed.

 

[cPRex]

That does seem like the correct kernel version, yes - https://almalinux.pkgs.org/8/almalinux-baseos-x86_64/kernel-4.18.0-477.21.1.el8_8.x86_64.rpm.html

 

[dstana]

That does seem like the correct kernel version, yes - https://almalinux.pkgs.org/8/almalinux-baseos-x86_64/kernel-4.18.0-477.21.1.el8_8.x86_64.rpm.html

What about pausing elevate before getting to stage 4? Is that a thing? I get that I'll have to be there watching it but is there a way to make that happen?

Maybe that's the problem, 4.18.0-477.21.1.el8_8.x86_64 is the version Alma provides but it's looking for 4.10.0-477.21.1.e18._8.x86_64. Pausing the script before reboot would be a good way to see what's installed and what's not.

 

[cPRex]

That isn't an option - the whole process is automated.

 

[dstana]

That isn't an option - the whole process is automated.

I just looked in the code for the script, I'm seeing a function in there called "request_manual_reboots", is there some reason I can't use that?

 

[cPRex]

Better question - why would a manual reboot help the process? If it can't find the kernel, it's still going to fail. But no, ELevate needs to be left alone and is 100% automated.

 

[dstana]

Better question - why would a manual reboot help the process? If it can't find the kernel, it's still going to fail. But no, ELevate needs to be left alone and is 100% automated.

Well before it does that reboot I can see what kernel was installed. Because the one it's looking for and the link you sent for the Alma kernel don't match up.

 

[cPRex]

Could you submit a ticket to our team so we can take a look?

 

[dstana]

I'm not sure what there is to look at, after running the script the instance isn't accessible.

 

[dstana]

Well I found the --manual-reboots flag squirreled away in the docs, so I'm giving that a try. Not sure what the big deal is with trying that.

 

[cPRex]

With that particular instance, there wouldn't be anything to look at, that's true. But, if you can reproduce this problem in your particular environment, we may be able to work with the host to improve that process.

 

[dstana]

Well, not sure what happened with that goofy kernel issue. But after a couple of other issues, I've successfully moved to Alma. The first one was done with --manual-reboot and I confirmed the correct kernels were installed before moving on to that last boot.

 

[cPRex]

Nice!