X86/cpu: SGX disabled by BIOS

General Linux Question
1

Hi all, :wave:

yesterday I helped my friend Margret with her laptop. It´s a Medion Akoya E3223. You can see a HW probe of it here.

It´s been working perfectly well ever since I put Linux Lite 6.4 on it and its built-in SSD makes the device very fast indeed.

So I performed the usual update routine on it and it seemed to have worked well. As a new kernel was part of the updates I rebooted the laptop and suddenly things got weird. :neutral_face:

First it looked like boot failed. This message however, appeared on the screen for a tiny period of time:

x86/cpu: SGX disabled by BIOS

This was definitively new. It hadn´t appeared at any time before the update.

I switched the device off and tried to perform a cold start with the same result. No boot, it seemed.
I also tried some older kernels. Nothing would help. :thinking:

I let it sit for a while and suddenly - after exactly 5 minutes - the laptop booted after all. I noticed that just by coincidence. :astonished:

Some tries later I could verify the laptop still boots but only after a delay of 5 minutes. That´s intolerable, especially in view of the fast SSD.

Of course I looked at the BIOS, or rather UEFI settings. Nothing seems to have changed. And I certainly didn´t perform any changes myself.
Plus: there seems to be no setting for SGX whatsoever.

Of course we´d like the laptop to behave itself again.

Can anybody help :question:

Many greetings from Rosika :slightly_smiling_face:

1 Like
2

Can you try a clean boot to a usb of the original version that worked ?

If thats fine reinstall

If not the bios setting screen shot may help track down the issue

1 Like
3
1 Like
4

Hi Paul, :wave:

thanks a lot for your replies. :heart:

I´m sorry, I don´t quite understand.
Do you mean I should see if the live version (install media) of Linux Lite works with the laptop?

On the site the link to which you provided they suggest adding “nosgx” as a kernel boot parameter.
I forgot to mention that I tried that as well. But it didn´t help at all - unless I misspelled it. That´s always a possibility.

What I don´t quite get is: why would a system update change BIOS (or rather UEFI) settings :question:

… and doing it in a way that no changes can be perceived visually. :thinking:

Many greetings from Rosika :slightly_smiling_face:

1 Like
5

Sorry i was not clear in my suggestion

Original live usb try booting from that and if ok then try install.

But if the bios has changed that may not happen.

Some bios options allow to reset to factory default when you select f10 save and exit f8 or f7 occasionally is restore to default

But why it canges dont know

1 Like
6

A “Live USB” boot test would be good. If there is no 5-minute delay in booting, then it’s something in software. If there is still a delay, then it’s something in the EFI/BIOS I would think.

3 Likes
7

Hi Rosika,
The message may be irrelevant.
The BIOS may have always disabled SGX.
Something else may be slowing the boot.
As @pdecker says, booting the old version from usb drive may help diagnose
Also,
did you look at dmesg… there may be further messages after the above.

@callpaul.eu seems to be saying the new install may have altered BIOS settings.
I have never encountered that. It would be unusual for that to happen, but I cant rule it out.

Can you try a different kernel in the new system? It may be a kernel bug.

Happy hunting
Neville

2 Likes
8

Hi all, :wave:

thank you very much for your replies and suggestions. :heart:

@callpaul.eu :

I see.
So you´d suggest trying out the original install medium and if it poses no problems then re-install Linux Lite?

Uh, I´d like to avoid that if at all possible. That would be an immense and time-consuming task. Backing up all relevant personal data and then putting them back on the system etc. :thinking:

But during my next visit to Margret I´ll certainly try booting from the USB-stick, provided she can find it in the first place. :wink:

Thanks a lot, Paul.

@pdecker :

Yes, software has changed to some extent because I performed an update. Just a normal update that is:

sudo apt update
sudo apt upgrade

Nothing unusual about it. Something triggered by that update must have introduced that delay. I don´t like that. :neutral_face:

@nevj :

Good point, Neville. I was beginning to wonder if that message would indeed have anything to do with the newly inftroduced delay in booting.

The only thing I can tell you is that I never noticed that message before.

No, I haven´t. That another point on the todo list next time. Thanks Neville.

I already did that. I tried booting with 2 different older kernels.
Unfortunately the message still persists, as does the delayed booting. :frowning_face:
So it doesn´t seem to have anything to do with the kernel itself.

I could also look at journalctl -b to look at boot logs.
And dmesg of course, like you suggested.

Let me just add another info:

Apart from the boot delay there´s been another change since the last update:

The following diagram of Margret´s laptop might help:

result-sprite
result-sprite958×1490 107 KB

(partly in German, but you´l certainly get the gist)

You may notice three LEDs (green ones in actual fact), to which the two arrows point.
The 1st one signals the on/off state of the device and the 3rd one is Num Lock.

The normal boot procedure (before the update) would be like this:
After switching on the device with the hardware button 2 LEDs were on:

  • the on/off LED
  • the Num Lock LED

… which meant that before entering the password on the login screen one had to hit Fn and F10 to switch off Num Lock.

After the update apart from the delayed boot time the following could be noticed:

Only one LED lit up (the on/off) one but not the Num Lock one :exclamation:

It was only after 5 minutes that suddenly the Num Lock one would light up and immediately after that you were presented with the login screen.

So perhaps it´s not the boot sequence itself that has been delayed but something else… :thinking: .

No idea whether if it helps at all…

Many thanks to all and many greetings from Rosika. :slightly_smiling_face:

9

I noticed a boot delay when i tried a linux lite install last week, changed to mint xfce and the boot was much quicker by a measured amount.

Thinking of your keyboard lights, i would reset the bios as think there is a modification at some stage. Yes normally the bios is not touched on install or update, but more recently i have noticed it can change, since secure boot and windows moved to the new style bios ntfs controlled. Especially regarding disk access.

1 Like
10

There may be a kernel boot parameter that is relevant to that.
and
is there anything in the BIOS relating to Num Lock?
and
have a look at the power/suspend/hibernate settings
and
I had a laptop once hibernate in the middle of the boot. It was a long time ago and all I can remember was something to do with the login daemon configuration. I will try and search

I looked, I think it is irrelevant.
The config file is /etc/systemd/logind.conf or /etc/elogind/logind.conf

1 Like
11

Hi again, :wave:

@callpaul.eu :

Hmm, perhaps things like that depend on the hardware used? I don´t know.
All I can say is that on Margret´s laptop (using an SSD) boot used to be very quick indeed.

That is most unfortunate and i don´t like it a bit. :angry:

@nevj :

O.K., but as I hadn´t changed anything either in the UEFI or in Linux´s own settings the update must have triggered the change after all.

I´m not aware of anything like that. But to be certain I´ll have to take a closer look at it next time.

Right, I´ll do that as well.

I´ll prepare a list of things I have to verify.
Thanks a lot for your help.

Many greetings from Rosika :slightly_smiling_face:

2 Likes
12

I notice morecand more a change with numloc and capsloc changes to the keyboard setting after an install or upgrade. But put it down to different configurations on keyboard layout.

As i work with different languages when i install i select the language, so french then it will ask what keyboard and there are over a dozen to choose from, then if you look at other countries that also speak french there is another great number of variations.

Makers go for a standard but they are different.

I did think apple, then french but discovered that even that is not easy.

I am sure when updates are done the keyboard mapping does not always follow through

2 Likes
13

So are you saying that when @Rosika did her upgrade, she needed to pay more attention to keyboard setup?
I can understand that if this was a fresh install, but @Rosika only did a simple update/upgrade with apt. I did not think keyboards got reset during a routine undate/upgrade?
I think both the Num lock light and the SGX message might be red herrings.
We have yet to find the culprit
I wonder is it possible to get a listing of what packages were updated in this latest upgrade? Rosika mentioned the kernel, but what else?
We are all clutching at straws. We need some info.

2 Likes
14

No time during a upgrade does it ask about keyboards in my experience, but not sure if that changes.

Yes something wrong but little detail to find what, sometimes you spend hours looking and never find, hence I am tempted with clean install. But lots of work involved either way

1 Like
15

Hi @callpaul.eu and @nevj , :wave:

thanks for your replies :heart: .

Hmm, strange.
I´ve done “countless” updates on Margret´s laptop since I installed Linux Lite.
Never before had there been difficulties like that.

I see.
Well, but what can I say? It was the first time things like that happened.

To be precise: Things haven´t changed that much. It´s only the 5 minutes delay which has been introduced before the Num Lock LED lights up.
Once it does everything works as per usual.

My thoughts as well.

That may be the case, Neville.
But the fact remains that the 5 minute delay has been introduced. So somehting must have changed. :thinking:

Good idea, Neville. I´ll have to look at them during my next visit to Margret.

How can I get a list of the changes :question:

Like so:

grep installed /var/log/dpkg.log | grep '2024-08-02' | grep 'status installed'

… or is there a better command for getting the desired results :question:

Thanks to you all and many greetings from Rosika :slightly_smiling_face:

1 Like
16

Hi Rosika,
I cant think of anything better
and
dont forget dmesg
see if you can get what stage of the boot this delay happens at
ie , what was it doing immediately before the delay… was it in the kernel, or was it starting some service, or whatever?
Regards
Neville

2 Likes
17

Hi Neville, :wave:

Thanks for your evaluation.

And yes, I´ll look at dmesg.
You´re right: Looking at what the system was doing immediately before the delay should prove useful.
Thanks for mentioning it.

Many greetings from Rosika :slightly_smiling_face:

1 Like
18

Hi again, :wave:

I just performed my usual update routine on my Linux Lite system.
It went well and a subsequent reboot showed that nothing has changed as far as boot times are concerned. :+1:

So I still don´t know what triggered that phenomenon on Margret´s laptop.
Only my next visit to her might tell.

BTW:

I made it habit to look at the packages that were updated after each update/upgrade on my system.
To this end I once wrote a short script and I just have to enter the command:

/home/rosika/Desktop/Kopie_Skripte/script_für_Verwaltung_nach_update.sh; and bash -c 'cat /media/rosika/f14a27c2-0b49-4607-94ea-2e56bbf76fe1/DATEN-PARTITION/Dokumente/interne_Verwaltung3/Veränderungen_nach_neuestem_update.txt | grep "<"'

The command does two things:

  • it shows the packages that have changed in a sandboxed text editor: old and new version, for the sake of comparison
  • after shutting down the text editor: it provides an overview in the terminal of the new versions only

1kkgw
1kkgw1913×1049 378 KB

and

2kkgw
2kkgw1913×1049 175 KB

Perhaps I should do something like that on Margret´s laptop as well. :wink:

Cheers from Rosika :slightly_smiling_face:

1 Like
19

Hi @all, :wave:

yesterday I visited my friend Margret again as she needed some more help.

Of course I took a look at her laptop right away.

It still needed the extended time of 5 minutes to access the login screen.
Nothing had changed in the meantime as she never switched it on.
So what I did was apply the latest updates to the laptop, hoping that one of the new packages would set things right.

And, believe it or not, it worked. :+1:

I rebooted after the patches were applied and instead of 5 minutes it took just half a minute to get it going again, like it used to be.
Then I powered the laptop down and initiated a cold start. Again half a minute. Seems that things were fixed by the update. :smiley:

I now asked ChatGPT what it was thinking about the problem:

It sounds like one of the recent updates addressed the underlying issue, bringing the laptop’s boot time back to normal.

Possible Reasons the Update Worked:

  1. Kernel or Driver Fix: The update might have included a fix for a kernel issue or a driver that was causing the long boot time.
  2. Firmware or Microcode Update: Sometimes, updates include microcode or firmware patches that can resolve hardware-related issues.
  3. System Service or Configuration Correction: An update could have fixed a misconfigured service or system setting that was causing delays.

Next Steps:

  1. Monitor Performance: Keep an eye on the laptop’s performance to ensure it continues to function smoothly.
  2. Regular Updates: Continue applying updates regularly to avoid similar issues in the future.

Before applying the updates yesterday I produced a list of the updates from a week before when the problem was introduced.

After applying yesterday´s updates I did the same so it´s possible to take a look at both of them and perhaps be able to assess what might have caused the 5 minute delay by comparing the two files.

So I sent the two files to ChatGPT hoping it would be able to come up with anything useful.

File 1 was produced by the command
grep installed /var/log/dpkg.log | grep '2024-08-02'.
After that the dealy was introduced.

File 2 was created by the command
grep installed /var/log/dpkg.log | grep '2024-08-09'
after which everything was back to normal again (half a minute to reach login screen).

Here´s what ChatGPT came up with:

Here’s what I can infer from the packages that were installed during the periods when the delay was introduced and when it was resolved:

Key Observations:

  1. August 2nd Installations (When the delay was introduced):

    • Several packages related to Python 3.10 were updated: libpython3.10-minimal, python3.10-minimal, libpython3.10-stdlib, python3.10, libpython3.10, libpython3.10-dev, and python3.10-dev.
    • Updates to core libraries like libssl3, libldap-2.5-0, libpoppler-glib8, libpoppler-cpp0v5, and libpoppler118.
    • Installation of kernel updates (linux-headers-5.15.0-117, linux-image-5.15.0-117, linux-modules-5.15.0-117, linux-modules-extra-5.15.0-117, etc.).
    • Installation of google-chrome-stable, firefox, and imagemagick packages.
    • Notable update: openssl was updated.

  2. August 9th Installations (When the delay was resolved):

    • Updates to libkrb5, libgssapi-krb5, libk5crypto, and libcurl libraries.
    • Kernel update: linux-headers-5.15.0-118, linux-image-5.15.0-118, linux-modules-5.15.0-118, etc.
    • wpasupplicant and thunderbird were updated.
    • Another update for google-chrome-stable and firefox.
    • openssl was updated again.

Potential Causes of Delay:

  • Kernel Update on August 2nd: The installation of the 5.15.0-117 kernel and its related modules might have caused issues. This could be due to incompatibilities, bugs, or regressions introduced in that specific kernel version.
  • Python 3.10 Updates: The numerous updates to Python 3.10 packages could have introduced compatibility issues, especially if certain services or scripts depend on Python during boot time.
  • OpenSSL Update: The update of openssl on August 2nd could have caused delays if certain services had issues with the new version.

Resolution:

  • Kernel Update on August 9th: The update to 5.15.0-118 might have resolved the issues caused by the previous kernel update.
  • Subsequent Updates to Libraries and Applications: The further updates to libraries (libkrb5, libcurl, etc.) and applications (chrome, firefox, etc.) might have resolved underlying compatibility issues.

Recommendations:

  • Monitor Further Updates: Keep an eye on any future updates to the kernel, Python, and OpenSSL. If delays reoccur, it might be related to similar updates.
  • Review Kernel Logs: Examine the system logs (/var/log/syslog and /var/log/kern.log) during the delay period for any errors or warnings related to the boot process.
  • Test Kernels: If the issue reoccurs, you might want to try booting into a different kernel version (using the GRUB menu) to see if the delay persists.

Well, I just wanted to inform you about the latest development. :wink:

I´m glad Margret´s laptop works like it used to again, and so is she.

Many thanks for your help and many greetings from Rosika :slightly_smiling_face:

BTW:

Margret sends her regards to you all.

5 Likes
20

Thanks for letting us know more. Appreciate that.

Just goes to prove that python is a slippy snake in the grass.

1 Like