Why is the root account locked out when trying to reset the password?

Question

linux

Good day! There is such a problem, when resetting the password on CentOS 5.6 running the Xen hypervisor, the root account is blocked. Moreover, it is blocked with any reset methods. I tried to delete the hash in the shadow, and the chroot will pick up and set a new one - passwd root. The password changes, checked in /etc/shadow, the password hash also appeared there, but after a reboot, when the password was deleted and when it was changed from Chroot, it was not possible to log in, again hooked from LiveCD, checked the hash in /etc/shadow, instead of the hash of the new password or instead of nothing (with the deletion method), two exclamation marks appeared (the account is locked), and two apostrophes between them, that is, it looked something like this:
root: '!!': ..........
As far as I know, the account is blocked - it's just two !!, and if there are two apostrophes between them, what does this mean? other methods did not work at all, such as
1) xm shutdown
xm create -c
in the first line of pyBRUB boot -> e -> kernell -> e -> init=/bin/bash or /bin/sh (tried both) -> Enter -> b. Writes, although it is in the initrd, it was checked for sure. I also tried to write init=/bin/bash or /bin/sh (tried both) in brub.conf. Same song. no such file or directory.
2) register single mode also in pyGRUB or in grub.conf. On boot, single mode requires a password from root:
Give root password for maintenance (or type Control-D to continue):
Pressing Control-D just boots as usual and requires a username and password.
Has anyone experienced similar blocking? Tell me please?
By the way, I thought that maybe I'm a crooked bugger and block it after a reboot by entering it incorrectly and specifically tried to reset it with a chroot, reboot, wait for all the virtual machines to load, then without trying to enter the virtual machine to which I reset the password, reboot again from the LiveCD, and see if it's blocked? And yes it was blocked - '!!'. Interestingly, the new password is written after a reboot to the file /etc/shadow- (shadow with a dash), and in etc/shadow (without a dash) '!!'.

Answer 1

/etc/rc.local
look at the starting services... it looks like a good script is sitting somewhere and changing your password ;)

Answer 2

Is it only on one server or all?
If on one, then this is not regular means, and you need to look for where it works.
This may work:
1. On boot, not at the initrd level. You can try to boot without an initrd, take an initrd from another server, or rummage through the current one.
2. When loading, at the startup-system level. Then you need to look for init scripts, especially pay attention to /etc/rc.*. Maybe even in pam. Unlikely, but I would check.
3. At the shutdown stage. Also search for startup-system scripts.

Answer 3

I've never encountered similar problems in Xen, but in ESXi, dom0 settings are stored in a "peculiar" way. The /etc directory is packaged into a tarball and this tarball expands on top of / when loaded. Accordingly, whatever you do with the LiveCD, the root password will still be different.
MB in your case something similar is available?