I am practicing for my upcoming RHCSA exam, however, I noticed that sometimes, after finishing a lab and rebooting the machine, it is stuck at the following message "probing edd (edd=off to disable)... ok".
This happened multiple times now, specially after doing network lab using nmcli and advanced storage lab using startis and vdo.
I have no idea how to solve that, it is just stuck, I tried setting edd=off in grub menu but that didn't help and I'm afraid the same will happen during the exam.
Any idea what this is all about ?
Although not sure why is causing the issue, try rebooting the lab machine after waiting for some time.
Also, I suggest reporting this to the support team as they will be able to assist in resolving the issue.
Please create a support ticket with the team by clicking the Support button appearing at the top left corner of the ROL portal window.
Was there any resolution? I noticed the same happening occasionally, and after a few restarts eventually, the boot process goes through.
I wonder about the chances of this happening in the exam after reboot.
That normally happens if the workstation (or servera or serverb) system cannot communicate with classroom system -- because it isn't up or because the bastion system isn't up . . . yet.
Keep in mind that the labs, especially online ones, are virtual machines (workstation, servera, serverb, bastion, classroom/utility) running inside another virtual machine (foundation0). Depending on the host hardware, it can take time for the entire thing to fully boot up.
In most cases, if you wait long enough, it will come up. Unless...
Now... In the case of Stratis and VDO, this wouldn't cause it to stop at the EDD screen because the network setting wouldn't have changed (unless you misconfigured the network settings with nmcli at the same time). What it would do is cause the system to eventually boot into emergency mode. This can take a while.
It is interesting to note that making a typo in /etc/fstab when defining the Stratis and/or VDO service(s) generally does not cause the mount -a command (which you should always use after accessing /etc/fstab, btw) to fail. The reason is that the Stratis and VDO daemons (services) are already loaded at the time you edit /etc/fstab and run mount -a; therefore, the system doesn't have to wait for them to load to perform the mount.
That's what the x-systemd.requires= bit does. It tells the system to wait until the sevice on the right side of the = is loaded before attempting to perform the mount. If there's a typo, the defined service doesn't exist and therefore it cannot be loaded. The system doesn't know it service doesn't exist and will take quite a bit of time trying to load it before giving up. The mount then fails and into emergency mode you go.
When I was first playing with Stratis and VDO, I kept typing x-system.requires= (forgetting the d in x-systemd). This caused me all kinds of headaches.
x-systemd.requires=stratisd.service (stratisd has a d)
x-systemd.requires=vdo.service (vdo does not have a d)
It would be helpful to see your nmcli command(s) and the lines you've added to /etc/fstab to configure Stratis and VDO.