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.
AFAICS, this is a HP BIOS/UEFI feature on top of “Secure Boot” and “Trusted Platform Computing”.
Yes, it is. I found a parameter “Enhanced HP Firmware runtime intrusion protection and detection” was checked. So going where angels fear to tred, I unchecked it with the successful result described above. I imagine some Leap component tracks the system hardware / software status and notifies the UEFI mocrocode if there’s a suspicious change. (I notice a “UEFITool” package is included in Yast but not installed by default.)
This is probably a good idea for large, stable corporate servers, but it can be a problem for small self-managed development systems.
But one other UEFI parameter “Allow BIOS updates using a network” was also checked. It seems the BIOS can download network updates (how? using Xorg-X11 network calls?) from ‘hp.com’ independently of the resident O/S. The BIOS allows a complete IP4 / IP6 network subsystem to be defined and tested.
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. 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. Should it be re-enabled?
If this seems like a live issue I’ll open a new topic.
Correct – modern UEFI BIOS has enough firmware space to accommodate an Ethernet driver – the BIOS has knowledge of the Mainboard’s Ethernet hardware –
Theoretically, the BIOS can also access the WLAN (WiFi) hardware but, much more information will have to be provided by the system’s administrator on a per Mainboard basis …
For the case of an Ethernet cable it’s quite easy –
The BIOS issues a DHCP request –
The LAN’s Router supplies an IP address for the Mainboard –
The BIOS sets up an IP connection to the IP address of the Mainboard’s manufacturer –
The BIOS automagically downloads the newest BIOS firmware image if, it hasn’t already been installed on the concerned Mainboard.
Yes, one can view modern UEFI BIOS as being microcode but, from my not so humble point of view, it ain’t …
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 …
Ditto for other Mainboard components which have microcode associated with them …
For 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.
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 …
Since mid-90s BIOS/UEFI contains CPU microcode. The normal way is that manufactures of mainboards provide microcode updates for their products. As some cheap manufactures doesn’t provide such updates, also the respective OS provides microcode updates. Both microcode “sources” get loaded at computer startup from the BIOS flash device into the CPU.
Leading mainboard manufactures update their microcode in the UEFI bios several times a year…
Question:
Does this mean that, the microcode provided by the “ucode-amd” and “ucode-intel” packages, stored in ‘/lib/firmware/amd-ucode/’ and ‘/lib/firmware/intel-ucode/’, was loaded into BIOS when the respective package was installed?
Sorry it was unclear. The microcode from BIOS get loaded from the BIOS flash memory, and the OS loads its own microcode into the CPU. Both at computer start. But the most actual version “wins”.
You can imagine the microcode updates from the OS and the BIOS as a kind of patch to the original set of microcode stored in the BIOS or CPU. There is some information that some CPUs already bring their own microcode in an special ROM area. The BIOS and OS patches the original microcode then…
The github page for intel-ucode has some good explanations:
Correct – modern UEFI BIOS has enough firmware space to accommodate an Ethernet driver – the BIOS has knowledge of the Mainboard’s Ethernet hardware –
Theoretically, the BIOS can also access the WLAN (WiFi) hardware but, much more information will have to be provided by the system’s administrator on a per Mainboard basis …
For the case of an Ethernet cable it’s quite easy –
The BIOS issues a DHCP request –
This probably isn’t the place for an in-depth architectural discussion and it isn’t really relevant to my main problem anyway, but I’m more concerned about the security aspects. I know these functions can always be “proved” to be watertight, but network updates to microde managing the O/S boot security is risky IMHO.
And it seems almost unnecessary given most systems now are loaded from main memory anyway. It’s not as though we have rotating storage which must be loaded into RAM.
When it leads to problems such as those I’m trying to fix at the moment, it may well reduce security.
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.
I’m afraid to say I’m not there yet. My Partner shut down the system without logging out first, then when I logged in soon afterwards the problem recurred. I suspect the “start a new session” login parameter is involved; my account has it set (new session) but her account still has it unset (the default). It’s probably the difference in system state at boot time which triggers the boot problem.
At this point I do need a reliable system, so I’m going to have to revert to the old master-boot-record method. I’d appreciate advice on the best way, given I have a nicely configured system and I’d prefer not to have to start from scratch?
Or, we’ll have to admit that, current HP hardware can cause unexpected issues when executing Linux as the OS …
Yes… and it occurs to me that the following details may be relevant.
As mentioned early in this discussion, Leap 15.4 was installed on an HP Desktop with Windows-11 pre-installed. 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. 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.
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.
I can think of various ways of fixing this during installation, but they all involve checking the microcode and what’s present on disk.
In the mean time, I think my neatest solution is to revert to MBR boot process.
Would you or another expert like to comment on the above guess as to cause, and the most economical way to move to MBR boots from UEFI/whatever? (I believe UEFI is backwards compatible with MBR, but I’m way out of my depth here and I don’t know whether that would fix it reliably.)
Re my previous note, and having read a little more about UEFI, I think I’d go back to MBR only if absolutely necessary. I’ll have a closer look at the detailed GRUB configuration, and also see if I can find what’s in the Windows containers. If it’s signature information for some Leap 15.4 programs loaded into the EFI System Partition, then deleting the container obviously wouldn’t be good! Apparently Microsoft is the Signature Authority (?).
But as I remarked, I’m way out of my depth. It might be quicker to just backup everything and reinstall Leap as a UEFI/GPT booted system without all the extra bells & whistles.
If, you can live without Microsoft licenses, what happens if, you erase the drive in the HP box (the Rescue System on the installation DVD is the cleanest way to do this) and then, reinstall openSUSE Leap?
No, I don’t need a Microsoft licence as I’ve been running OpenSUSE since V9, and had intended the Leap 15.4 installation to completely reformat the hard drive.
However it failed on the first attempt with a diagnostic indicating it couldn’t delete “MDcontainer”, which sounds as though it refers to a Moby-Docker-container or possibly a Microsoft-Docker-container; if so, one would expect it to be well protected. (I didn’t write the name down at the time so that’s from memory, but I’m pretty sure it’s correct).
I then deleted all hard-drive partitions using Gparted with no error diagnostic, and Leap installation ran without error on a second attempt. All trace of the pre-installed Windows 11 system should have effectively disappeared. I listed the partition layout after installation and I’ll check it again, but unfortunately I won’t be able to do so for a day or two.
My understanding of this architecture is that it’s essentially only the configuration of a virtual system using Moby Tools which is open-source, the underlying framework which maps the hardware interface (and may also provide more high-level functions, depending on the virtual system) is proprietary to Docker.
I’ll also uncheck the UEFI Safe Boot flag (as well as the HP SureStart enhancement) to see if that removes the blank screen. It’s obviously not an acceptable solution, but it should confirm the environment in which it occurs. Results to be posted in a few days…
Almost the same but, not quite, as writing zeros (or random integers) to the first few hundred blocks on the drive – to really get rid of all partition information on a drive, you really have to overwrite the first blocks on the drive – better, up to and including the first super-block on the thing.
When I returned this morning I was unable to reproduce the problem during several likely scenarios which would otherwise have failed, so I think I should probably put it on hold until I obtain some consistent and meaningful information or decide it’s been fixed (see below).
Regular online updates have continued to be installed since opening the original post, including several which might be relevant or may have changed the symptoms. This morning before beginning testing, these updates (among many others) were successful according to the YaST2 package history:
lilbopenssl1_1
openssl-1_1
grub2
grub2-i386-pc (!!)
grub2-i386-pc-extras
xorg-x11-server
xorg-x11-server-extra
Given that lot, perhaps it’s not surprising the “blank screen” problem has disappeared. However there were some problems with this update session.
Both xorg-x11-server updates are still shown as outstanding in the online-update list, apparently because they depend on the openssl updates which are also shown as outstanding. (This despite being logged as installed by YaST2.)
Evidently the openssl update procedure wants to update from version 1.1.1I-150400.7.28.1 to …7.31.2 but that later version is already installed so it gives up, then the X11-server updates fail as a result. This version dependency has resulted in some other update glitches too, but I’ve been assuming “openssl” versions are backwards compatible.
Should I upgrade the x11-server packages manually with YaSTand ignore the dependencies?
The only thing I can see related to OpenSSL with a version number of 7.* is “python3-pyOpenSSL - Python wrapper module around the OpenSSL library”
The YaST Updater module is raising the issues you’re mentioning because, the X-Org Server patch has to make sure that, a related OpenSSL patch has been re-installed to ensure that, post patch installation procedures are correctly executed and, that, all the related changes needed to related system scripts and settings have been made correctly.
Simply, push the button and, let the patch and update procedures execute.
Yes, I tried upgrading openssl manually when I returned here on Thursday, but that failed. Why? I suspect some internal database of installed packages and the version of each has become out-of-sync with reality. Originally openssl version 1.1.1I-150400.7.25.1 was installed, I then “upgraded” it to …150400.7.28.1 with YaST, and again to …150400.7.31.2 this morning.
After this morning’s effort I had to revert to a snapshot in order to get a workable system of any sort, and I may make it the default boot image until I recreate the system.
I’m happy to pursue this if it achieves anything generally useful, but I’m becoming concerned at the amount of everyone’s time it’s consuming. This morning I managed to backup all the user data, so unless you suggest otherwise, I’ll completely reinstall and update the O/S from a DVD, having first written zeroes or a random pattern to the entire static RAM.
I’m also not confident that all the automatic updates have been properly installed given the version issues.
Are you happy for me to recreate the system and destroy the evidence given the amount of time you’ve both put into it?
I have 32 15.4 installations, a similar number of TW, and 15 15.5 (so far). Patches and deltarpm are not in my vocabulary. I never use anything but zypper for updates, and these dependency issues you’re encountering, in my recollection (which isn’t all that good), simply do not happen. There may occasionally be mirror issues that clear up after a few hours, but they don’t cause breakage:
# zypper se -si openssl1_1 | grep date
i | libopenssl1_1 | package | 1.1.1l-150400.7.28.1 | x86_64 | UpdateSLE
erlangen is my main machine. I am using it as a reference installation for other users with poor or zero knowledge of Linux. Their machines are upgraded or updated automatically using systemd services. Typically they talk to their acquaintances: “My numerous and frequent Windows problems are gone. I have no idea what Linux does. It simply works”. This is confirmed by the low number of calls I get from those users.
Last issue was with LibreOffice: LibreOffice Writer would deny editing documents. Moving the configuration folder fixed this annoyance.
