You are not logged in.
Hello
Arch Linux x86_64
Host: B650 Pro RS
Kernel: Linux 6.18.3-arch1-1
CPU: AMD Ryzen 7 7700 (16) @ 5.39 GHz
GPU 1: AMD Radeon RX 6600 XT
I have an MB Asrock B650 pro RS, running their BIOS 3.5 all is perfect
If I update to the latest version 4.03, Arch shows a message at boot "EFI stub: Warning: unable to unprotect memory range"
But it boots and runs as normal
For info, secure boot is disabled, and I cleared Secure Boot keys as I saw a similar post, but that again didn't change anything
Any ideas if this is due to the kernel or the BIOS ?
I suppose it's the BIOS and not Arch, or rather the kernel, but often I always get good answers or pointers to fixing problems
For the moment, I've reflashed back to their 3.50 BIOS
I've posted the same question on the Asrock forums
Last edited by Trevor_B (2026-01-07 15:36:12)
Offline
the correct error message is "unable to unprotect memory" - please update the topic
searching with the correct error message I found this: https://github.com/torvalds/linux/blob/ … x86-stub.c - so this is an error specific to efi-stub
it's a very wild guess but from what's in that file it maybe has something to do with the general kernel address space randomization
plugging "linux efi stub unable to unprotect memory range" into google comes up with: SecureBoot, TPM, firmware bug
wild guess: asrock changed something in the newer update which doesn't play nice with boot linux via efi-stub - and linux complains about it
this is nothin arch specific but rather about how you boot and a likely faulty uefi
reporting this to asrock is general the right way (please link the topic on the asrock forums - and add a link to this topic there) - but it's unlikely asrock devs will see any importance in fixing it
my recommend: update and ignore the warning - as there'S not much you can do - as the agesa update is quite an important security update you should apply no matter if using secureboot or the (f)tpm
Offline
the correct error message is "unable to unprotect memory" - please update the topic
reporting this to asrock is general the right way (please link the topic on the asrock forums - and add a link to this topic there) - but it's unlikely asrock devs will see any importance in fixing it
my recommend: update and ignore the warning - as there'S not much you can do - as the agesa update is quite an important security update you should apply no matter if using secureboot or the (f)tpm
Hello
Typo corrected
Asrock forums done, but like you, I don't think they will do anything. I'll wait until the next BIOS update to see what happens
Thanks
Offline
It's defenetly a problem with the latest BIOS Version (4.03).
Same Problem here on an Asrock Taichi Lite X870E.
Offline
It's defenetly a problem with the latest BIOS Version (4.03).
Same Problem here on an Asrock Taichi Lite X870E.
I sent an email to Asrock Asrock_TSD@asrock.com.tw and actually received a reply
"Thank you for your email.
Our BIOS team is checking on this case, and we will contact you again if we have any new information.
All the best,
ASRock TSD"
Fingers crossed that they'll actually look into it
Offline
well - at least you didn't got the usual "we don't support linux"
Offline
It's defenetly a problem with the latest BIOS Version (4.03).
Same Problem here on an Asrock Taichi Lite X870E.
I received a version to test from Asrock this morning by mail, and it works
@Boogleix, if you want a copy, PM me
Bravo Asrock, that's dammed good customer service
Offline
sharing a rom with a different board and bios won't work (and likely declined by the flash utility)
but yea - one of the few times a board oem responded in such way to some regular linux customer
often beta version are only send to known people like LTT
Offline
Asrock released a new UEFI Version (4.04) on 16.01.2026, with the description "Optimize system compatibility."
But this doesn't fix my problem with the stub warning,
Last edited by Boogleix (2026-01-19 11:16:05)
Offline
Shame
For the moment, the B650 Pro RS is still showing 4.03 as the latest version
A newer version isn't online yet
I received feedback after my testing
"Thank you for your report. We will phase this change in our next production BIOS soon."
Maybe drop them a line, like I did
Offline
Boogleix wrote:It's defenetly a problem with the latest BIOS Version (4.03).
Same Problem here on an Asrock Taichi Lite X870E.I received a version to test from Asrock this morning by mail, and it works
@Boogleix, if you want a copy, PM me
Bravo Asrock, that's dammed good customer service
Hi could i also try the rom? I have an asrock B650 pro rs and it happens on my system too
Offline
Got the same problem with the latest bios update with a gigabyte board
Last edited by Reboot9012 (2026-01-27 15:36:38)
Offline
Got the same problem with the latest bios update with a gigabyte board
Could you say which board, this is interesting because it could be the new agesa 1.27.0.1 that is causing this issue to arise
Offline
Reboot9012 wrote:Got the same problem with the latest bios update with a gigabyte board
Could you say which board, this is interesting because it could be the new agesa 1.27.0.1 that is causing this issue to arise
It't the B850 GAMING X WIFI6E (1.x)
Offline
Got Answer from Asrock Support to.
Hallo,
laut Rückmeldung der Kollegen der BIOS Abteilung wird der Patch dafür in den nächsten BIOS mit dem neuen AGESA Code zusammen veröffentlicht.
Einen genauen Termin habe ich leider nicht, sollte aber nicht mehr all zulange dauern.
Sie könnten gerne beigefügtes BIOS 4.04.AL01 aufspielen und das Verhalten prüfen.
Wenn das neue BIOS dann erscheint sollten Sie dieses dann aufspielen.Mit freundlichen Grüßen / Kind regards
ASRock Technical Support
ASRock Europe B.V.
Bijsterhuizen 1111, 6546 AR Nijmegen, The Netherlands
Seems to fixed with the next official UEFI Update.
I will not try that beta UEFI they send me. My PC runs and its just a Warning.
Offline
honestly positively surprised to get such a feedback from one of major oem - usually the first reply is a semi-automatic "we don't supppport linux" and then you get ghosted because you're on some grey-list flagging your e-mail
so it should be taken as greatful to even get support at all
Offline
I asked gigabyte support and they just answered that they support windows thanks I guess
Last edited by Reboot9012 (2026-02-02 14:45:35)
Offline
I asked gigabyte support and they just answered that they support windows thanks I guess
exactly THAT what I expected ... welcome to Linux, I guess ...
Offline
Apparently if I'm reading this right lots of people in the gigabyte subreddit have problems with latest bios even in windows where tpm doesn't store the keys for bitlocker happens to me also it's time to downgrade and see if it works so my dual boot works properly when I have the time. Amateur hour from gigabyte zero Linux care and their bios releases unlike from msi(there is a post in their forums for the same problem here)and asrock as seen above this thread
Last edited by Reboot9012 (2026-02-05 05:04:24)
Offline
well, the reason behind "no linux" is often because most consumer products are designed specifically for and tested only with windows
if something breaks on linux it's the straight version of the aboce: the product just isn't designed for linux and hence not tested with it
this also depends if the oem has a professional branch like asrock with thier asrock rack line - these are products specifically designed for datacenters where linux is the vast majority of used OS - hence they have the expertise and staff to deal with linux
it's simply a question of money: most people use windows and even for premium parts most want to pay the lowest price
if you can outsmart your competitor by not support linux you can both cut cost and sell for less which increases the chances a consumer choses your stuff over one of your competitors
none of oem makes money from support consumers - it's pure cost without revenue - why should they waste a single penny on a handful of linux users? thier mind is likely "either deal with it or use something else"
also: the linux kernel and its drivers are full of workarounds because oems not follow the spec which linux expects
an example: the asmedia asm 1x6x pci-e/sata controllers: although port multiplication is part of the sata spec its up to the oem to write a proper firmware - which most of the low cost chinesium multi-port card oem don't - so there was an effort to workaround a long timeout on such cards which resulted in downstream ports no longer work
as i was affected i filed a report which ended up in the workaround to be reverted as the dev decided it's worth to have people affected suffer from timeouts rather than cause the hba not work at all for others
another example was for usb audio interfaces: it was just meant as code cleanup but caused several codecs to no longer work correctly so this also had to be reworked
or when amd gpus were unable to properly warm reboot
this list goes on - no imagine a big oem to deal with this across dozens of products and about millions of different kernel configurations? should they test with debian? or arch? or fedora? what about the other unix flavor BSD?
you see this spirals out of control extremely fast - for what? a few dozen linux users are happy - put simple: not worth it
Offline
Yeah nobody doubts that I sure don't expect anything because nobody uses Linux I was lurking every available source of info and found that they even broke tpm for windows some people reporting they can't use bitlocker like me or play anti cheat games maybe this tpm problem is relevant with the Linux error who knows it's kinda off topic you get the gist.I will downgrade when I get off work and test if older bios works better.Overall my point is that gigabyte seems so bad at supporting haven't found a forum or anything had to use an outdated support system unlike msi and asrock where in my surprise and yours they have answered for this Linux problem it's just a shame really but I'm not complaining but it gets worse because of the windows problem
Last edited by Reboot9012 (2026-02-05 09:07:58)
Offline
Hello,
I just wanted to add my experience, I’m using a Gigabyte X870E AORUS PRO (https://www.gigabyte.com/Motherboard/X8 … pport-Bios) with Arch Linux and systemd-boot, booting in pure UEFI mode with CSM disabled. With BIOS F9, which is based on AGESA 1.2.0.3g, I never saw any warning during boot.
After updating to BIOS F10, which introduces AMD AGESA 1.2.8.0, systemd-boot started printing the following message at boot: No EFI_MEMORY_ATTRIBUTE_PROTOCOL found, skipping NX_COMPAT support.
Nothing else changed on my system. The machine boots and runs fine. However, when I rolled back from F10 to F9, the message disappeared immediately, without touching any configuration. That makes it pretty clear (at least in my case) that this is caused by a firmware change introduced with AGESA 1.2.8.0, not by systemd or the kernel.
I also checked the BIOS settings to make sure this wasn’t related to legacy options or CSM, but everything is already set to pure UEFI and changing settings doesn’t affect the behavior. Gigabyte’s changelog for F10 doesn’t mention anything related to EFI memory attributes or NX, so this looks like an unintended side effect or regression.
For now I’m sticking with BIOS F9, since AGESA 1.2.8.0 doesn’t bring any visible benefit on my system and introduces this warning. Just wanted to share this data point in case it helps confirm that this is AGESA-related.
Offline
I downgraded and no errors anywhere but they released a new update but I'm too lazy to do it and I'm bored to downgrade again in case of errors again
Offline
Blargh, just ran into this issue myself with my Gigabyte X870E Aorus Elite mobo. It was perfectly fine on BIOS F9, but then I decided to upgrade to F11 and that's when the problems started. Screw me for attempting to be up to date on my BIOS I guess.
Anyone know if lacking NX_COMPAT support is a big enough security issue that I need to rollback? Or should I just wait this out?
EDIT: Seems like the new BIOS prevents TSME encrypted memory and SMAP from working properly. I've downgraded to F9 for now.
Last edited by UrbenLegend (2026-02-13 19:18:21)
Offline
Exactly the same error on gigabyte X670 Aorus Elite AX with uefi update F40 (or potentially F39 they released after the 10.0 CVE they had a few weeks ago, I actually never updated to that version).
Offline