This thread is dedicated to connect you with Red Hat subject matter experts who can help answer your questions regarding Red Hat remote exams. Please see the following resources for Red Hat Remote Exams below:
For questions on scheduling or redeeming your exams, please use the Red Hat Certification team comment form here.
**Our subject matters experts in the Red Hat Learning Community will not be assisting with tasks related to scheduling exams.
Found a workaround on the Intel NUK desktop.
I have *not* solved the issue. And did not find a workaround on my laptop, the Lenovo P50 running RHEL 7 that went into the boot loop. But I *did* find a solution on the Intel NUK which gave me the grub prompt.
At the grub prompt, issue these commands:
Then the machine will proceed. At one point it will offer you a choice of boot environments, and default to one, and start to boot that environment. Looks like it might be looping but no, it gets to the RH Test environment.
Anyone who runs into the same issue, your correct choice for root location might not match mine. At the initial grub prompt, run an ls. You should see a list of "devices" to choose from. The list will something like this:
(hd0) (hd0,msdos1,apple2) (hd0,msdos1,apple1) (hd1) (hd1,gpt1) (hd1,gpt2) (hd1,gpt2)
That's about what my list looked like. The listing is conceptually similar to what you'd see with an lsblk command:
deviceX, deviceXpart1, deviceXpart2, deviceY, deviceYpart1, etc.
You probably *don't* want the "device" (the hd entry without a comma-separated second parameter). You want a partition. You can figure out which by listing it:
Note the trailing slash. That accesses the "root" of that partition's filesystem. Check them until you find the one that lists "EFI". That's your Red Hat ISO. Then:
See if you can find your appropriate *.efi file. That's the path you use in the chainloader command, and the device is what you set root to.
Note my desktop had the USB as #1 in the boot order, so for me the flash drive was hd0. Your boot order might be different. Also, for some reason the Red Hat iso showed up as hd0,msdos1,apple1) , which what the heck? But grub did not like the third parameter in the set root command. It worked as I wrote it above, pretending that the "apple" parameter was not even there.
Red Hat, it's absurd that I had to do this. It was your officially distributed ISO! And it didn't boot!
Also it did not match your description of it (you say it's 4Gb but it's only 1.2 or 1.3Gb). But I wouldn't have cared about that if the think would have booted.
You guys need to fix this. Is it an issue about classic BIOS vs UEFI?? Something else about my two devices??
This is an urgent issue for anyone testing remotely.
Hi @JimHardy ,
First thank you for your feedback, it's good that you can voice your concerns, and that someone listen to them. I'm going to try helping you.
First, for the context, the Remote Exams are rather new, they were released for the first time in 4th August 2020. Not going into details, some I don't even know myself to ensure integrity, it has to be some secure environment. Red Hat switched from a testing environment using KIOSK, some sort of laptop with identical specification worldwide, to opening them on a very high amount of hardware, again worldwide. Basically most customers won't even have the same setup, the same hardware, etc... Unfortunately that means that we can expect some setup related issues at some point. Having said that, it worked properly for many customers, I passed one exam myself on a T480S from Lenovo, and I have seen positive feedback from various other configurations. In other words, many candidates were able to attend their certification exams remotely, using that newly released Remote Exam live environment.
Second, for your intel NUC setup, I would say that you found a workaround, not a solution. The customers are not expected to have to do what you did in order to make it work, that is too technical for various users. Without knowing all of your setup, it seems difficult to explain you what possibly went wrong, certainly something did.
Third, the information you have appears definitely incorrect:
"it did not match your description of it (you say it's 4Gb but it's only 1.2 or 1.3Gb)"
Nothing said the iso size is 4GB and/or 1.2GB.
Having said that, like I explained, the user should be able to verify file integrity by using checksum, something we reported and will be looked at by the team.
Let me show you again, from the official source:
Hard Drive: A hard drive with free storage capacity of at least 4 GB (for Live USB creation only).
Nothing says the iso file is 4GB. It says there should be at least 4GB free on the hard drive of the computer used to flash the .iso file.
1. Download the Remote Exam Bootable Live USB from here and save it in the local hard drive.
Again, the size is not given. As I said there is a limitation here, users should be able to verify the file integrity after it's downloaded.
Going further, I invite you to provide your feedback here, that will be directed to the relevant team:
We can also try to identify what is happening on a technical level, on a discussion basis in this forum. For example, if you can provide details of your USB key, that would be a start.
@shefeeqyr can also help, maybe there is a known issue with P50 laptops, currently not fixed?
We are not aware of any known issue with Lenovo P50s yet. I will however check if support tickets were raised by other candidates using P50s.
Publishing the checksum of each remote exam live USB image release is something that is being considered. I don't have a timeline for this at this point though.
Size of the image can vary between each releases and we have set a requirement of a USB drive of 8 GB and above. We did have a 4.2 GB image briefly, but was pulled back as it needed a bit more work.
If the steps followed in the instructions document do not produce the desired results, it could be broadly due to a) an incomplete/failed ISO to USB write process or b) Incompatibility between the candidate's hardware and the remote exam live USB.
I would totally avoid advising customers to do troubleshooting at a grub/bootloader level to resolve it for the risk of breaking something else in the process. You can try a different laptop/desktop, try to write the ISO another time, from a different computer/operating system etc. For instance, we recommend using Fedora Media Writer to create a live usb in Fedora or Windows. Fedora Media Writer returns a success message if everything went fine.
In a worse case scenario of incompatibility and lack of alternative computers, candidates have an option to switch their exam eligibility between two modalities - Remote Exam and Testing Center (conventional Kiosks at partner locations), as long as you reschedule at least 24 hours before the exam start time.
Speaking to your two broad possibilities: (a) incomplete write to the USB and (b) incompatibility between hardware and test environment.
ISO to USB write process
My laptop is running RHEL 7. I downloaded the ISO to that laptop, and ran the suggested dd command to write the ISO to the USB drive. The dd command seemed to finish successfully.
(I thought I had saved my dd output somewhere, but having trouble finding it now.)
As I mentioned in the previous comment, the checksum of the file on my laptop matches. This seems a pretty rock-solid copy process. Note that I did *NOT* pre-format the USB or anything: I just assumed the DD process would destroy whatever was there and write from the beginning.
I'll check with a different USB. I'll also try writing it from the desktop using a different method (other than dd).
Incompatible hardware / exam environment
Bluntly, this seems impossible. The laptop is already running RHEL7! It should be pretty much guaranteed to be compatible.
For the desktop: this is info that I didn't have when I first commented last night). On the desktop where I worked-around the boot issue using grub commands:
(My actual performance on the exam is another story...)
The success of the exam compatibility test, AND the exam itself, raises doubt about whether the ISO-to-USB copy was bad. How bad could it have been, if everything other than booting worked perfectly? That's a very specific and restrained write failure.
Switching between exam modalities
Switching between modalities can be difficult in the current Covid climate. I live in Maryland; the local testing center has been closed for several months. Reopening date unknown. Travel between states to a different testing facility raises other potential issues.
For some of us, remote testing is by far the most practical method, for the near future. (Which is why you guys rolled it out in the first place!) Not so easy to switch modalities.
And I don't really believe there is an incompatibility issue here. Something else is going on. Does the Sandisk Cruzer protect a partition or some sectors at its beginning? Do the dd did not start where it was supposed to?
Or is there something wrong with the ISO? Doesn't work properly with UEFI systems, or something?
I don't know where you saw some information about the iso size that led you to expect a size of 4GB. All I know is that the iso sometimes updated, and the size change a bit (well not from 1GB to 4GB). Possible the 4GB size was very early version for a pilot phase.
Checking the file integrity and ensuring the file is not corrupted, complete and the correct one is something that can be solved by checking the checksum and proper versionning. My colleague @shefeeqyr is looking into the topic.
At the moment, I tested early August, the working file was:
1267597312 (1.2G) rhrexboot.iso
The sha512 checksum was:
(you need to type: sha512sum rhrexboot.iso).
Since I tested that one, and I verified its integrity, if the file has not been updated since then, that should be the same checksum, and it should prove it's not a corrupted file).
The correct URL to download the latest version of the Remote Exam iso is here:
Anyway, what USB key are you using? I suspect the issue might be somewhere else?
My checksum matches! Thanks.
Really, this checksum info should have been provided on the download page for the ISO, as is standard practice with distribution of installers.
On reading the first reply, I realize that I had misunderstood something. I had inferred that the ISO itself was 4Gb. I guess what is actually happening is that the ISO is smaller, and it loads the ~4Gb OS onto the USB. That makes more sense. My expectation was wrong.
But it still should boot! My USB is a brand-new SanDisk Cruzer 32Gb, fresh out of the box. I'll try loading it on another USB. But I'd be surprised if the flash drive itself is the issue, esp since I was able to finish booting after performing the grub workaround.
Hi @JimHardy ,
I agree for the checksum (and even the versionning should be added). A @shefeeqyr said, it's work in progress.
I agree it should boot, if flashing the image was properly done, if the hardware is compatible and if there are no restrictions, as it could be on some corporate laptops... A lot of possible root cause!
It booted properly for many candidates, the key would be to identify why that did not work in your case.
Indeed the USB key seems decent enough, sufficient space, and probably fast enough read/write speed...
I tried to boot into the redhat remote exam environment via my usb.
I was sent to the grub> prompt.
I typed "exit".
I proceeded to enter the environment to run my compatibility test.
I hope this helps someone.
My download speed in the compatibility test says it is too slow. I have a 2.8Mbps download connection speed (as measured by speedtest.net) and I know from looking at my router IP traffic that I am the only one using my home network and registering at 2.8Mbps during the network test. Why is it still saying the download speed is too slow ?
2.8 Mbps from Speedtest.net sounds a bit unpredictable to me. Usually, speedtest picks a nearest server to test bandwidth and hence realtime results can be quite different. The download/upload test of our compatibility test looks at the speed to access Red Hat servers and hence it will be different based on distance, time of testing etc.
You can try conducting a few more iterations of this test at different times of the day to see if the failure is consistent.