Questions about getting ready for your Red Hat remote exam?

[Deanna]

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:

• Remote Exams Announcement
• Technical Documentation for "Getting ready for your Red Hat remote exam"
• Remote Exams FAQ

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. 

[JS_Learning]

Hi @AngeloRimoldi ,

We would have to be creative, respecting the rules and requirements...

https://www.redhat.com/en/resources/certification-remote-exams-FAQ 

Use of or access to the following items or any similar items within your workspace during the exam is prohibited: 

• Smart or connected devices including phones, tablets, and similar electronics. ...

That means that using a phone as an external webcam is not allowed.

Cheers,

[harjitsachar]

Hi,

Thanks for your revert. Would it be possible to get clarity, whether we can use a separate USB microphone, as this seems to be a major stumbling block for most cheap Webcams.

Regards,

Harjit Sachar

[Yuri_]

i, I'm trying to do the Compatibility Check but I can't follow the instructions. I'm stuck on the step "After connecting to the internet, close the settings window to connect to the Red Hat Individual Exam Scheduler page". When I close the settings window the screen become black and I can't do anything (I wait for 10 min just in case but it still in black window). I can't skip this screen and because of that i can't login and do the Compatibility Check. The only thing I can do is to right click into the background and select "settings" and then the settings menu become again.

Also I try to reinstall the SO in the pendrive 3 times with the Fedora Writter utility and the result is the same. I double check the internet connection is OK, so I don't have any ideia of what is happening here.
Thanks for your time.
Yuri.

[JimHardy]

I am not able to boot off of the USB.

The ISO that I downloaded is called rhrexboot.iso, and its size is only about 1.2 or 1.3Gb.  I was led to expect a size of over 4Gb?  So this is a surprise.

When I attempt to boot my laptop (Lenovo P50 running RHEL 7.8), I can get into the boot menu and the USB is available to choose.  But it won't boot off of it.  I just wind up in a boot loop: F12, boot menu, choose the USB, hit enter, blank screen, F12, boot menu, choose the USB, hit enter, blank screen, over and over.

I also have an Intl NUK as a desktop running Ubuntu.  On that machine, the USB is #1 in the boot order, so I don't have to do anything special, it tries to boot off the USB right away.  I wind up at a grub prompt.  If I enter boot, it says that there's no kernel loaded.
(This almost feels like part of the test!  :-)

How do I resolve this?  Is the 1.2 Gb ISO file that I have, the correct one?  It's from the static dot RedHat dotcom downloads/training-certification site.

[JimHardy]

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:

set root=(hd0,msdos1)
chainloader (hd0,msdos1)/EFI/BOOT/grubx64.efi
boot

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:
ls (hd0,msdos1)/

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:
ls (hd0,msdos1)/
ls (hd0,msdos1)/EFI
ls (hd0,msdos1)/EFI/BOOT

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.

[JS_Learning]

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:

https://learn.redhat.com/t5/Certification-Resources/Getting-Ready-for-your-Red-Hat-Remote-Exam/ba-p/... 

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:

https://rhtapps.redhat.com/comments/ 

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?

[shefeeqyr]

Hi @JS_Learning, @JimHardy 

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.

Regards,

Shefeeq

[JimHardy]

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:

1. I ran the exam compatibility test last night, and it passed
2. Then today Iactually  took an exam on it.  The environment worked fine.  No issues whatsoever: chat with proctor, monitor via webcam, exam loading, VM access, etc etc etc.  So that seems to completely rule out compatibility issues on the desktop.

(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?

[JS_Learning]

Hi @JimHardy,

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:

5d37b4560beb9392106d36986d95cca2670c94253bd6f9cb1681d5a0727f067c1304ec6a9d588e995e2afad9efca12983511eedf06c6b01ac89e6c67fc1530f5

(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:

https://static.redhat.com/downloads/training-certification/rhrexboot.iso 

Anyway, what USB key are you using? I suspect the issue might be somewhere else?

Cheers,

[JimHardy]

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.