Problem with RHCSA online lab machines (Probing EDD)

[bahar]

Hi,

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 ?

[Ashish_Lingayat]

Hi @bahar,

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. 

Regards,

Ashish

[kelmartins]

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.

[Tracy_Baker]

@bahar 

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...

• When using nmcli you've misconfigured the interface that needs to talk to the lab's network. In this scenario, workstation (or servera or serverb) can longer communicate with the classroom or bastion systems. The system will stop at the EDD screen every time if this is the case. In this scenario, you can use rht-vmctl reset workstation (or servera or serverb) command from a foundation0 terminal to reset the system you are working on to its default state. (Be warned... if you are working in NetLab, this may also change the root password to R3dH4t and it may also change the student user's password. We've seen this in our NetLab.)
• When using Stratis and / or VDO it is much more likely that the enrty used in /etc/fstab is incorrect -- that there is a typo when specifying the service name in the defaults for the mount.
  Statis would be: x-systemd.requires=stratisd.service
  VDO would be: x-systemd.requires=vdo.service

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.

So remember:
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.

[AndyMcIntosh]

I get the same in lab 'Resetting the 'Root Password' (RH199 ch09s07), so before nmcli, stratis or VDO are broached. Tested on workstation, servera, serverb. Hangs indefinitely. Tried edd=off on the kernel command string before the rd.break; while the 'Probing EDD' message does not appear, boot likewise hangs indefinitely. Only solution is to resart the lab environment and skip the exercise... which I know is a critical one to master.

[AndyMcIntosh]

Found relevant KB?

Adding rd.break to kernel line to reset root password blocks at Probing EDD

https://access.redhat.com/solutions/5503851

"Solution In Progress - Updated October 20 2020

Root Cause

Under Investigation"

[Chetan_Tiwary_]

I too got the same EDD probing message when I just added rd.break at the end ( without removing any console paramteres ) .

However when I removed all the console=ttyS0 parameters ( 2 parameters in total ) and then added rd.break at the end and then ctrl-x , it worked fine ( without getting any edd probing message ).

I shared this tip with others and it worked for them too. 

[BhawyyaMittal]

Thanks, it's working for me.

[JustinP]

The fix is unexpected.

So the console was hung up on the kernel on the lab hardware?! and never timed out?

Awhile ago, when EDD was taking a very long time on boot (not the training labs), and would time out after several minutes.

The reply from Red Hat was that this EDD message indicated a mismatch in performance counters in hardware vs kernel; and a WONTFIX from Red Hat because the hardware/OEM manufacturers needed to fix their end.

Good the workaround works for the labs ... just seems odd.

[Chetan_Tiwary_]

Yes it didnt time out, it just hangs there.