I recently swapped out my CPU (went from a ryzen 5 to a ryzen 7) and afterwards i was able to boot once, but after that when i tried to boot i would get an "secure boot violation) error message after inputting the luks password.
I disabled secure boot in the bios and it’s booting now, but i would like to reenable secure boot.
Is there any way to fix this, without doing a full reinstall?
Thanks in advance.
Secure Boot was never supported by manjaro in the first place.
Though its possible your implementation wasnt actually stopping the boot.
Or are you saying you set up a shim or something ?
3 Likes
I didn’t setup anything, i just installed manjaro with the official installer and secure boot has been working.
Secure boot has never been supported …
It is however possible with some firmwares to enroll and sign your own bootloader using the firmware’s built-in tool.
3 Likes
Ok, strange that i had secure boot the whole time then, without doing anything.
Is it not a security risk to leave it disabled, if manjaro doesn’t even support it?
In my opinion secure boot is not a necessity. Your system is not likely to be vulnerable.
Did you switch mainbord as well?
1 Like
No, only the CPU.
Thanks, i’ll just leave it disabled then, don’t want to go through the trouble to do a fresh install.
Are you multibooting Manjaro with Windows? If so, just a heads up: Windows may need some extra attention with Secure Boot disabled, especially Windows 11. Do some homework. Cheers.
No, i only use Manjaro
And how exactly did you figure out that “secure boot has been working”?
It’s not, because you didn’t. 
You probably have secure boot in permissive or whatever the mode is.
journalctl -b -g "Secure boot"
On some motherboards you can turn on Secure Boot and then override the execution policy to allow unsigned images. Possibly you had done that and then changing CPU reset BIOS settings to default? Or you have a MSI motherboard, where this was the default setting in previous firmware, and you also upgraded the BIOS when you changed the CPU?
I don’t like the scaremongering in this article but it does explain the details.
1 Like
Secure Boot actually doesn’t have anything to do with security. That’s just a marketing ploy.
Secure Boot is a feature of the UEFI firmware as per the UEFI specification, which is drawn up by a committee that includes Microsoft. Their influence on the UEFI committee is enormous — for instance, UEFI executables are in the same binary format as Microsoft Windows itself, and the UEFI shell uses the same command syntax as the Windows command line.
The true purpose of Secure Boot was simply to allow Microsoft to seize control of the x86-64 and aarch64 platforms, given that unlike Microsoft’s historical rival Apple, Microsoft did not produce any hardware of its own. So it was Bill Gates’ intent to, by way of Secure Boot, force the x86-64 or aarch64 platform into becoming Windows machines and cut off the “competition” from GNU/Linux and other operating systems.
Security-wise, Secure Boot has already been bypassed several times at hacking contests. So it’s not actually secure, and the Free Software Foundation prefers referring to it as “Restricted Boot”. Because that’s what it is and has always been all about — it’s another anti-competitive measure from Microsoft, and it’s intended to support the corporate proprietary software industry while cutting out the Free & Open Source Software movement.
There is nothing to gain from having Secure Boot enabled, and all the more to lose from it, because it’s a lot of unnecessary trouble to get it to work properly in any distribution. Some distributions like Ubuntu and RedHat have yielded to the scaremongering tactics from Microsoft’s lawyers, but there is no technical nor any legal need to have Secure Boot enabled, and especially not since it’s Microsoft that’s constantly breaking the law on account of copyrights, patent infringements, et al.
9 Likes
Hey, thanks for the clarification on that, i didn’t know all that.
1 Like
That’s quite the bashing you’ve given Microsoft – not that I disagree. However, you did omit mentioning that the underpinning fat32 filesystem of every ESP (aka EFI System Partition) is/was also a proprietary Microsoft format.
More fuel for the fire!
1 Like
True, that. And I could have said even more, such as the fact that the only authority that hands out Secure Boot certificates/keys is Microsoft, and that one therefore has to buy a key from them.
On the other hand, the ESP on Apple-branded computers is not vfat but hfsplus. In other words, Apple is the only computer manufacturer with a UEFI that allows for a non-Microsoft ESP filesystem format. But then again, Apple’s macOS is also an officially branded UNIX®, even though it’s the least UNIX-like of all UNIX-family operating systems — its filesystems aren’t even case-sensitive.
Just goes to show that money goes a long way… 
2 Likes
Yes, but Apple have had their own share of like-minded misgivings; for example the 32bit boot (on a 64bit platform), effectively preventing multiboot functionality; in the early days of UEFI; clear cut artificial manipulation.
2 Likes
While I respect your opinion I can’t agree that your post is a solution of OP’s question in any way. It just explains your point of view on the nature of Secure Boot and solves no problem and rather tries to persuade everyone there’s no problem at all. Still, you’re sure free to think this way, no objections, let’s just get to the point where we actually suggest a solution right.
In short, @JohnnyKarate should probably just disable SB in UEFI settings and that’s it. Since he only uses Manjaro. And intends to use Linux only. And never ever ever would download and use a cool “Rescue boot CD” from some questionable / hijacked source. And would never ever boot from random USB sticks put in his PC. If so, he’d probably better to disable SB for good.
Another option would be enrolling MOK or signing Manjaro’s bootloader with own key like described here. I also happen to have my own write-up on how to achieve “Verified Boot” on Manjaro using god damned Secure Boot and TPM – these diabolic pieces of M$ crap every “true” (c) Linux user should curse and ditch (and write about it proudly), of course.
Seems like a enormous amount of work for no useful return.
@ Aragorn is correct, Secure Boot has nothing to do with Security, even though both it and the TPM chip, which it depends on, were marketed as such. It is about control of the hardware, by one company… and they nearly succeeded.
3 Likes
Again, this topic is not about someone’s opinion – right or wrong – about the nature of Secure Boot.
You can happily think of it whatever you want – why using this thread for this?
How come? The issue discussed it this thread is a perfect example of a security mechanism triggered by the UEFI considering some random unsinged unverified and untrusted Linux distro (Manjaro) being a threat according to current UEFI settings. Change settings – and you can set Windows or anything else considered untrusted (forbidden to boot on your machine), except your distro of choice.
This is why company-backed distros like Ubuntu, Fedora and openSUSE done that for their users. I doubt they are dumb enough to ditch the vast amount of their userbase saying something that @Aragorn says. Probably a matter of business, but could be a better awareness? 
Quite simply that is how Secure Boot is marketed… So by definition anything that does not have the approved key is flagged as a Security threat.
That doesn’t make Windows or anything else a Security Threat, it merely defines them as such.
Your example merely demonstrates the real purpose of Secure Boot. Control of the Hardware.
Microsoft nearly succeeded, in taking control of x86_64 based Hardware, using that False Security ploy.
As @ Aragorn rightly points out
1 Like