How to: inplace upgrade from Centos 7 to Almalinux 8.5

What do you get if you now manually issue this grubby command?
grubby --info ALL
Does it show all your kernels?
 
Owz, that's not good.
Can you check if /boot/grub2/grub.cfg exists?

Could also be some efi stuff, but I'm not good in boot stuff, maybe @Active8 knows how to fix this.
I would not risk to just create that file manually if not exists so lets wait for him.
 
What kind of virtualization are you using? this is not tested on OpenVZ 7 or other types, only on KVM
And did you check the log? : /var/log/leapp/leapp-report.txt

Its kind odd that you have grub problems in that step because on that stage you must already had some errors after preupgrade command
Did you ignored that and proceed the update without fixing any problems ?

After the reboot, did you monitored the boot process ?
 
Active8 said:
What kind of virtualization are you using? this is not tested on OpenVZ 7 or other types, only on KVM
And did you check the log? : /var/log/leapp/leapp-report.txt

Its kind odd that you have grub problems in that step because on that stage you must already had some errors after preupgrade command
Did you ignored that and proceed the update without fixing any problems ?

After the reboot, did you monitored the boot process ?
Click to expand...
Hi,

I found out that i’m indeed running in a OpenVZ space.
After the preupgrade step i got this, nothing before (from what i saw)
 
Its official , inplace upgrade doesn't support containers like OpenVZ !!
From their chat : No containers won't work as booting to the custom initramfs is required
 
I was reading this again and just have a question.
See how the update process goes in the console. << you must have console access to follow the process !!
Click to expand...
What exactly to you mean by this? Console as in SSH or as in a monitor (tv screen) in which you can view?

I've seen some YT video about this, but seems they used a pc monitor, because they could see the boot choices too.
So if you don't have physical access to the server, can this be done via remote KVM? Or what is the best method to monitor this remotely?

As for the license part. I presume with the newly created license system, there might be some slight change needed in the commands?
 
Richard G said:
Console as in SSH
Click to expand...
Similar but then you have to connect by VNC & ILO or similar program.
This upgrade was performed on an VPS and not bare metal.
Richard G said:
I presume with the newly created license system, there might be some slight change needed in the commands?
Click to expand...
I am not certain if this is changed or not in the meantime , at the time I did this it was not an problem
 
I am having some issues after using the upgrade guide

​

I can no longer ssh into the machine. Logs say this:
pam_systemd(sshd:session): Failed to stat() runtime directory '/run/user/1001': No such file or directory

Anyone have a good suggestion on how to resolve this?
 
Mixtery said:
Anyone have a good suggestion on how to resolve this?
Click to expand...
User 1001 is admin if I'm not mistaken. Do you login via SSH as admin and the su to root? That seems not to work at the moment.
Try to login directly as root, that should work.

If that works. You might need to check the /tmp folder to clear old ssh logins out.

If you have direct root login disabled, you have a problem. In that case if you can login to DA itself as admin, login as admin, go to the file editor in the admin section and change the sshd config so root can login and restart sshd.
If that is not possible you should contact your host/datacenter for a KVM or VNC connection or something to your server.
 
Ok. so logging in as root does not work either (in ssh).
Permitrootlogin=yes

ssh when connecting says "no authentication methods available".

Additionally, when i reboot the server i also cannot login to the server via the terminal, it just kicks me back to login again until i reset the password. When i reboot it again, same issue.

(and thank you so much for sharing your thoughts about this.)
 
Mixtery said:
ssh when connecting says "no authentication methods available".
Click to expand...
In that case probably the plain password authentication is not set to yes or is commented.

Check you sshd_config that you have that line like this in the sshd_config file:
PasswordAuthentication yes
and restart SSHD. Then you at least have an authentication method so you should not have that issue anymore.
 
And restarted sshd? Very odd indeed.
I presume you set your SSH client also to password authentication.
Strange.

Does it still say "no authentication methods available" or kicks you out?

I'm just wondering. Is it possible to login to DA as admin? If yes possible to stop all services from there (so they don't autostart again), then via SSH stop the DA service afterwards and then clean the complete /tmp directory, at least if you can get in via SSH after a reboot.

As like Active8 said, is this a bare metal dedicated server or was this on a VPS?
 
I can login as admin in DA. Everything runs fine.

Issue is that when i reboot the server i also cannot login into the terminal using KVM, it trows me back to the login. This is "fixed" when i reset the password, but the next reboot the issue is back.
As for ssh i can not login at all. Client says "no authentication methods available" and on the server site i find "pam_systemd(sshd:session): Failed to stat() runtime directory '/run/user/1001': No such file or directory".

Very strange behaviour. I emptied out the /tmp directory. Stopped all the services and rebooted. No effect.

It is a dedicated server.
 
I also see this in the log "Not setting $XDG_RUNTIME_DIR, as the directory is not in order." and i'm no expert, but this feels like the issue. I just havent a clue what it means
 
Mixtery said:
"pam_systemd(sshd:session): Failed to stat() runtime directory '/run/user/1001': No such file or directory".
Click to expand...
This one still confuses me the most as user 1001 is admin, not root, so this should not appear when trying to login as root directly.

However... Might also be something caused by another issue like the runtime dir.
If I'm not mistaken it has something to do with systemd, but I don't know what exactly.

Maybe if you can get into terminal again as root via the KVM, you could try this:
yum reinstall openssh
yum reinstall openssh-clients
yum reinstall openssh-server

Hopefully that fixes something.
But I'm not that good in systemd debugging. Maybe @Activ8 a clue on this?
 
You must log in or register to reply here.
Back
Top