Centos: Boot halts with: Probing EDD (edd=off to disable)
Researching this it can be fixed by adding “edd=off” at the boot. However, running in VMWare I can’t get to the console in the split second needed to interrupt the boot process.
Debian: This one boots to completion. At this point trying to connect via a browser gives ‘ERR_CONNECTION_REFUSED’. The server does respond to a ping.
Trying to login via a console was also problematic. It didn’t accept the admin/Nethesis,1234 combination. It did accept root/Nethesis,1234 and then immediately asked to change the password. Except after giving the old/new/new passwords it took me back to a login where it would only accept root/Nethesis,1234 again and asking me to change it again. Wash, rinse, repeat.
Rocky: This also stopped at the Probing EDD.
There was one other quirk I noticed, but this might be VMWare playing up. I could add any of the images to a profile and save it, but then any additional attempts to edit the profile failed, saying it couldn’t find the disk. So every time I needed to edit, I had to delete the disk, save, and the add again along with the change I was trying to make.
You might add a comment to the Images section to let folks know they are all IDE based. Or better still, provide OVF or OVA files.
Not a good idea - those are more or less VMWare propreitary formats…
The world uses ISO!
Check if you have enabled promisious mode on the used NIC in your VMWare. VMWare needs this set, Proxmox uses this out of the box. NethServer uses this (at least in 7x) for the AD…
Sure–as an installer. If you want a disk image of an installed and running VM–boot it up and it runs–ISO isn’t the format. And OVF, if it’s prepared properly, includes not only the disk image itself, but also the relevant VM configuration–which would avoid at least some of the issues noted up-topic.
No one here at the office is using VMWare
The vmdk image is just a converted qcow2 file, but probably it needs some adaptation to work correctly on WMWare.
I guess you have the same problem if you try to import the qcow image.
That’s strange: the pam configuration for resetting the password was good on Rocky.
We will need to test it again on Debian.
Maybe I didn’t wait long enough when I got this before:
Probing EDD (edd=off to disable)
I just downloaded the new Rocky image and booted it. I got interrupted just after that message appeared. When I came back, I was staring at the Rocky logon screen. BTW Is there a root password and ssh enabled for root or was a second user created.
No, it’s as you described, the images don’t fully boot except of Debian but there’s the password change loop.
Unfortunately the second user has no password and root login and password auth seems disabled due to cloud init scripts.
I think we should change that to be able to work with the image immediately.
Well, I could login via the main console using the root/Nethesis,1234 combination. It asked me to change the password which I did and this time no loop. I was able to login to root/“new password”. But only at the console. Trying to ssh in, I get:
I do see the user “rocky”, but all the usual passwords fail.
Sorry, it wasn’t clear enough.
Root login and password auth via SSH is disabled.
The user rocky has no password, so login isn’t possible.
This is all set via cloud init, see /etc/cloud/cloud.cfg
To configure sshd to be able to login with root:
In /etc/ssh/sshd_config change/add
PermitRootLogin yes
and
PasswordAuthentication yes
Restart sshd:
systemctl restart sshd
This does work until next reboot.
EDIT:
It should also be possible to set a password for user rocky to be able to login via console/SSH:
I have a running rocky linux vmdk on Vmware Esxi, the published vmware images can only run on Vmware workstation. You have to download the vmdk to the esxi storage, and use vmkftools on the host to convert the disk following this guide: Using VMWare Workstation VMDK image in ESXi | Steak’s Docs based on this vmware KB: KB1028943.
The converted vmdk can be added to a new virtual machine and booted.
btw: went to the same trouble with gaining SSH access to force permit rootlogon and allow password authenticatin (see post mrmarkuz).
I noticed something else: the rocky user and the root user seem to have public/private SSH keys that may still be active on the base system you cloned the disk images from.