is excellent news, and I encourage the initiative, there is still a small problem that makes it unusable in some cases, there is no “sudo” program in it (and I assume the corresponding config) which makes it impossible to pass in root.
OP should clarify what the actual question is, so we don’t have to guess. The only thing we know is:
there is no “sudo” program in it
This does not tell us anything about how this image was installed, or what configuration was passed upon installation. The solution to “there is no sudo” is simple: install sudo. Clearly this isn’t enough but we have no idea why.
If you use cloud-init for example, as discussed here, you can pass the hashed root password.
You seem to be under the impression that getting root on a cloud image is “impossible” which is far from true, but it’s hard to give any useful input if you provide no information on how you’re using the image.
The team know about the fact sudo is missing and it will be fixed. There is a post on this forum about it already when someone asked, as well as in mattermost. Post: Rocky 8.6 GenericCloud - no sudo?
When cloud images are used with OpenStack or whatever, it’s pretty much a disk image that is used as a template, and connecting to the instance, depending on what it is tends to be the distribution name - so a user such as rocky, ubuntu, debian, centos etc depending on the image. The user’s ssh key is injected during the creation of an instance, for example under openstack into that particular user. Therefore after connection, sudo is required to get to the root user with the use of sudo su or other sudo commands.
There is also the option to inject passwords during the instance creation process, this is possible in OpenStack as I have done it. Therefore, you can use that method temporarily or just wait for the cloud image to be updated and including sudo.
Potentially also you can modify the image yourself creating a VM under KVM with Virt-Manager or whatever, and then install sudo in it. However, you will then need to use the cloud-init/sysprep stuff to sort that image out before uploading it and using it with for example Openstack.
The easy way would be just to wait until the team fixes the image.
Yes, I know well how to handle the problem, but for images used in openstack context, having sudo allows to have a default behavior (without contextualization). This is the case for the different images provided for the different providers.
As I said, the team is working on fixing it. So great, glad that you know how to handle it, at least you can survive in the meantime, until the image is updated by the team.
Yes of course, the meaning of my message was only to identify this little problem by bringing my grain of sand. I thank you for all the effort of the Rocky team and the associated community.