Uefitool microcode5/18/2023 ![]() ![]() ![]() In the mean time, I think my neatest solution is to revert to MBR boot process. I can think of various ways of fixing this during installation, but they all involve checking the microcode and what’s present on disk. Is it possible that the whole “UEFI / SureBoot / HP SureStart enhancements / Microsoft-Linux container subsystem / Leap15.4 O/S” jungle has resulted in this problem because there’s no container? In other words, is there a UEFI microcode dependency on the MS container subsystem? A good description of how it all hangs together is available here: The Leap 15.4 installation then ran smoothly to completion, and the system has been running well since except for the current problem, which is something of a show-stopper. However the installation failed when it couldn’t delete the Windows container structures (files? partition?) so I used GParted to delete (from memory) all the existing partitions and started again. I chose to have a separate /home partition but let the installation process decide partition sizes such that the entire static “hard drive” was used. Yes… and it occurs to me that the following details may be relevant.Īs mentioned early in this discussion, Leap 15.4 was installed on an HP Desktop with Windows-11 pre-installed. Or, we’ll have to admit that, current HP hardware can cause unexpected issues when executing Linux as the OS … If, the new BIOS introduces new features then, when the Operating System boots, it’ll take advantage of the new features, if and when, that OS supports the new BIOS features ….Ditto for other Mainboard components which have microcode associated with them …įor the case of BIOS – UEFI or not – if, the BIOS can automatically at boot time query the Mainboard’s manufacturer for BIOS updates and, download them, then, the system will have to be rebooted anyway to load the new BIOS version – which is independent of any Operating System running on the concerned Mainboard.CPU microcode is loaded by the Operating System being booted – CPU microcode is updated by means of Operating System patches and updates – which is why certain patches and updates require a system reboot – to reload the CPU’s microcode ….Yes, one can view modern UEFI BIOS as being microcode but, from my not so humble point of view, it ain’t … ![]() If this seems like a live issue I’ll open a new topic. I can see the old version-incompatibility problem arising again but at a really basic level where it’s largely out of O/S control. Having the system-boot microcode download updates which may conflict with O/S updates, and are certainly not tested with it, does not seem like a good idea to me, so I disabled it. ![]() The BIOS allows a complete IP4 / IP6 network subsystem to be defined and tested. It seems the BIOS can download network updates (how? using Xorg-X11 network calls?) from ‘ hp.com’ independently of the resident O/S. This is probably a good idea for large, stable corporate servers, but it can be a problem for small self-managed development systems.īut one other UEFI parameter “Allow BIOS updates using a network” was also checked. (I notice a “UEFITool” package is included in Yast but not installed by default.) I imagine some Leap component tracks the system hardware / software status and notifies the UEFI mocrocode if there’s a suspicious change. So going where angels fear to tred, I unchecked it with the successful result described above. I found a parameter “Enhanced HP Firmware runtime intrusion protection and detection” was checked. The good news is that I think we’ve nailed it! I didn’t have time to post a note yesterday, but the system now seems to be quite solid: it responded perfectly when I logged in to my own account, switched user to root, deleted a package, shut down the system without logging out either account, and then logged in again.ĪFAICS, this is a HP BIOS/UEFI feature on top of “ Secure Boot” and “ Trusted Platform Computing”. ![]()
0 Comments
Leave a Reply. |