RedHat Case Comment Thread part 3 - RHCE clearly states that if the BIOS bug warning was given that it is a BIOS and some good tips on working around RHEL:
Most recent comment: On 2015-03-03 14:40:19, ************ commented: "Good Afternoon,
Regarding the BIOS bugs, if its reported as a BIOS bug, it really is a BIOS bug. Remember that hardware manufacturers tend to use a lot of the same hardware, just with different firmware that has things turned on/off here and there. A perfect example is AMD where a large number of the CPUs are physically identical, but with different microcode to change the core configuration, etc. This saves on manufacturing costs because of the simplification of tooling.
I'm not saying that it is or is not a bug, however we see something that should work in the driver but is not in the BIOS, hence us reporting this as a BIOS bug.
I've heard of viruses that get down into the superblock of a disk, however those are very rare, and very advanced. I doubt that you managed to buy machines from different vendors with the same virus out of the box. I'm not saying that this is impossible, but it's unlikely.
I do know that Windows 8 likes to dig down in the BIOS, particularly on Intel based systems with IPMI. I've had people ask me to downgrade brand new windows 8 PCs/laptops to Windows 7, and they simply would not boot to ANYTHING but the hard drive with Windows 8 on it, and I've done everything from reflashing the BIOS after turning secure boot off to outright replacing the hard drive. You aren't the only one who's seen this.
Regarding the encrypted disk, the disk password is not necessarily the root or privileged user password. If you dont set a password for the disk when you configure encryption, you'll have to wipe the volume. The disk password and other passwords are not shared or linked. If you change the root password, you have not changed the disk password and vice versa. If you dont set a password or key to decrypt the volume, you'll never open the volume again without wiping the volume entirely. Also, do not encrypt /boot. You'll never boot the system, with or without a password.
If you wish to use different media, you can download it from https://access.redhat.com/downloads. You can verify the ISO file before even burning it to disk by comparing the hash of the downloaded file to the one that we provide on the web page.
Disable secure boot from the BIOS. I understand the purpose of this system is for learning and secure boot will only get in your way. I also don't recommend encrypting the primary volume on a system meant for learning. It creates unnecessary overhead, and you should learn how to use LUKS on a non-critical volume beforehand because, when done improperly, you will lock yourself out of the machine, forcing you to reload. You should also never attempt to encrypt a mounted volume.
Getting past lost passwords: - Disk encryption: You can't. - GRUB passwords: depends on if you encrypted it or not. - Plaintext: Boot to rescue mode using the install media, mount /boot and read the /boot/grub/grub.conf file - Encrypted: Boot to rescue mode, chroot to the installed environment, mount /boot and reinstall GRUB without a password - RHEL 6: boot to runlevel 1 by adding the number 1 to the end of the kernel line in the GRUB menu. Change the root password with the 'passwd' command when you are presented with a prompt. After changing the password, reboot - RHEL 7: https://access.redhat.com/solutions/918283
Let us know if you have any questions or need any clarification of the above and have a great day!
Best Regards,
**************, RHCE Technical Support Engineer Red Hat Inc. Global Support Services - North America"
Thanks ********
This has been very helpful. I'll reach out if none of these recommendations work and would consider case/questions to be solved at this point.
Enjoy your week and thanks again!