Hello,
today I had to reinstall grub with grub-install command. Everything went great until i wanted use secure boot (need it because dual boot with Windows). I dont know why but previously I didnt use -s flag so I dont have sbctl list-files output. I signed everything that in my opinion is needed to successfully secure boot, but grub is booting only to rescue mode with prompt: “prohibited by secure boot policy”. Probably there is somewhere file that isn’t signed, but I cant figure which one. There is list with signed files that I did after grub reinstall:
sudo sbctl list-files ✔
/boot/memtest86+/memtest.efi
Signed: ✓ Signed
/boot/vmlinuz-6.12-x86_64
Signed: ✓ Signed
/usr/lib/systemd/boot/efi/systemd-bootx64.efi
Signed: ✓ Signed
/boot/efi/EFI/GRUB/grubx64.efi
Signed: ✓ Signed
/boot/efi/EFI/Manjaro/grubx64.efi
Signed: ✓ Signed
/boot/efi/EFI/boot/bootx64.efi
Signed: ✓ Signed
/boot/grub/x86_64-efi/core.efi
Signed: ✓ Signed
/boot/grub/x86_64-efi/grub.efi
Signed: ✓ Signed
sbctl status
Installed: ✓ sbctl is installed
Owner GUID: 12345678-1234-1234-1234-123456789012
Setup Mode: ✓ Disabled
Secure Boot: ✗ Disabled
Vendor Keys: microsoft
Firmware: ‼ Your firmware has known quirks
- FQ0001: Defaults to executing on Secure Boot policy violation (CRITICAL)
https://github.com/Foxboron/sbctl/wiki/FQ0001
sbctl verify
Verifying file database and EFI images in /boot/efi...
✓ /boot/grub/x86_64-efi/core.efi is signed
✓ /boot/grub/x86_64-efi/grub.efi is signed
✓ /boot/memtest86+/memtest.efi is signed
✓ /boot/vmlinuz-6.12-x86_64 is signed
✓ /usr/lib/systemd/boot/efi/systemd-bootx64.efi is signed
✓ /boot/efi/EFI/GRUB/grubx64.efi is signed
✓ /boot/efi/EFI/Manjaro/grubx64.efi is signed
✓ /boot/efi/EFI/boot/bootx64.efi is signed
Yes, i followed it but nothing works.
I will check it, but previously i didnt have to use any script/gits and everything was perfect
Secure Boot is not supported in Manjaro, regardless of the fact that several people here have managed to get it to work — the Arch Wiki has detailed information about the subject.
I would rephrase that - Secure Boot is not supported OOB - but given that tools exist in the official repo, and relevant instructions exist - one could say it is supported - but it is a manual operation that requires an experienced user.
I followed your guide, boot from main.efi went straight to LUKS password. After password I get this error:
ERROR: Root device mounted successfully, but /sbin/init doest not exists.
Bailing out, you are on your own. Good luck.
sh: can't access tty; job control turned off
Switched back to GRUB boot, tried to bruteforce sign every single file in /boot and /boot/efi. Even with that secure boot isnt working. Without it everything works perfect.
I tired it one more time, step by step reading every single letter in every line. Same output. Only one different thing is that i dont have loader file in the /boot/efi:
ls /boot/efi
EFI main.efi 'System Volume Information'
I can also give You my /boot/efi/EFI:
ls /boot/efi/EFI
boot GRUB Manjaro
I dont know why before grub reinstall it simply works. After that it cant. Every single file in the /boot is signed (if it can be).
I will specify more details, maybe someone could help me:
I have two SSDs, one with Windows and second one with Manjaro. I need secure boot because second user is playing games on Windows that require secure boot. I need GRUB menu to simply choose which OS should be boot. Manjaro have 3 partitions : /boot, /boot/efi and LUKS (need to have /boot and /boot/efi to make GRUB menu appear before LUKS password, otherwise second user cant have to know my password before choosing Windows in menu).
lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
nvme1n1 259:0 0 953,9G 0 disk
├─nvme1n1p1 259:1 0 300M 0 part /boot/efi
├─nvme1n1p2 259:2 0 700M 0 part /boot
└─nvme1n1p3 259:3 0 952,9G 0 part
└─luks-f3b1a7c9-2e4f-4d8a-b6e2-91c5f7d2a1b3 254:0 0 952,9G 0 crypt /home
/var/log
/var/cache
/
nvme0n1 259:4 0 953,9G 0 disk
├─nvme0n1p1 259:5 0 100M 0 part
├─nvme0n1p2 259:6 0 16M 0 part
├─nvme0n1p3 259:7 0 389,8G 0 part
├─nvme0n1p4 259:8 0 751M 0 part
└─nvme0n1p5 259:9 0 563,2G 0 part
I am using sbctl and everything was great until after one update i had to reinstall grub. Now i cant do anything with secure boot, because grub is in rescue mode with error “prohibited by secure boot policy”.
What are most necessary file for grub? Maybe i should check them out and sign them. Already tried bruteforce sign everything in /boot and /boot/efi.
The partition layout looks like a bios/gpt layout… specifically the 16M partition caught my attention.
Using full disk encryption with the installer results in the grub menu being inside the the container.
This will generate a situation where you cannot boot windows without unlocking your Manjaro installation.
Just realised I somehow missed this point - you actually did created an unencrypted boot partition
In such situation - the most convenient switch between OS is to use the system firmware boot override e.g. F7 or F12 - look at your system manual.
You can use limine boot loader - but that is outside my knowledge.
Another option is rEFInd to boot either your custom EFI-stub or Windows
I will have to look deeper into what could have changed and what I may need to update in the guide.
I have digged a bit - I think your issue is caused by booting in compatibility mode…
//EDIT 2025-08-16T13:26:00Z
I want to blame myself for not spotting this - I know why it fails - the guide assumes there is a root= directive in /etc/default/grub because the default Manjaro installation used when writing the guide contained such directive.
Your Manjaro installation is encrypted - you will have to amend for your specific use case.
My laptops with fully encrypted root has no bootloader but boot the main.efi directly.
In the link provided in this comment you can find the script I use to setup a laptop with luks2 and argon2id which is much faster than LUKS1 which must be used when grub is used to unlock the container.
Because your system is encrypted you will likely need to define a /etc/crypttab.initramfs pointing to the LUKS container - this is an example from the above mentioned script
system /dev/disk/by-partlabel/cryptsystem none timeout=120
You will need to amend your kernel cmdline by pulling the active cmdline
My point — which is the official position of the Manjaro Team — is that we don’t offer support for it, and that the responsibility is therefore on the hands of the user.
The presence of the tools for enabling and maintaining Secure Boot in the Manjaro repositories is only a consequence of the fact that, with the exception of the Manjaro-specific tools and our custom packages — e.g. our kernels — everything in our repositories comes straight from the Arch repositories.
I have done the following out of curiosity - could it be done - at all?
The goal was to identify what need to be changed to be able to achieve what you are trying to do.
I have created a system configuration similar to your setup using a laptop with two disks.
I installed a Windows 10 on first disk - then proceeded to create an encrypted Manjaro installation on the second disk using Calamares - selecting btrfs and swap to file.
While I do have some experience in doing this from scratch I have never tried to convert a Manjaro Linux encrypted setup - but I did - and it works ..
I made notes on the changes - I can share them if there is interest ..
Thanks a lot. As soon as I will come back to home I will try your solution.
To be honest it can be done with only sbctl - no changing files or anything. Before that disaster with grub reinstall it worked perfect - with secure boot, GRUB selection and no need to uncrypt LUKS ( while selected windows it was booting straight to windows). I cant figure out how I made it (spent probably 5h+ to debug everything), but it worked. There was probably something more sign or there was some little change in one of the config files, that i cant remember. But i will try your guide as soon as possible. Thanks a lot!
BTW, is secure boot necessary on Linux, or is it perhaps overkill? Are there really attacks on/from the bootloader, or is it just academic mumbo jumbo?
Yes - the unencrypted boot partition make that possible.
I see a full disk encryption with LUKS as a serious attempt to protect data.
Whether Secure Boot is necessary - that depends on your threat assessment.
Linux is as vulnerable to boot chain attacks as Windows - but it requires physical access or a very sophisticated targeted fishing campaign.
Linux is less vulnerable to malware - but it can be done - again it may require physical access or an ignorant user.
Depending on the actual malware - in case of a real root infection - there is only one way - replace the solid state disk or in case of spinning disk repeated overwrites with random patterns.
Secure Boot is not secure — it has already been compromised several times — but it is the marketing name for an anti-competitive Microsoft strategy introduced into the design of the UEFI specification — Microsoft is on the UEFI Committee — when Microsoft was under the leadership of Steve Ballmer.
The intent was to hijack the x86-64 and aarch64 architectures and completely bind them under Microsoft’s control, given that Microsoft — unlike its old rival Apple — did not offer any hardware of their own.
They called it Secure Boot — and likewise, Microsoft is also involved with the TPM Committee — but the Free Software Foundation more appropriately calls it Restrictive Boot, because that’s exactly what it is.
A few GNU/Linux distributions have adopted Secure Boot — e.g. RedHat (and its various derivatives), (open)SUSE and Ubuntu — and some of RedHat’s developers were even attempting to include it in the upstream kernel, which instantly prompted Linus Torvalds to post another one of his (in)famous rants on the kernel mailing list.
Long story short, Secure Boot is as much a requirement for GNU/Linux as that a parachute would be a requirement for operating a lawnmower.
