Why whatever do you mean? I think it makes total sense for Windows 11 to require your motherboard have a TPM 2.0 chip (for your own safety, of course!) and that it will not install on any laptop in the future that does not have a high-def front-facing camera starting in January 1, 2023.
Because even though most laptops have built-in webcams, and even though Microsoft can “recommend”, or “highly encourage” purchasing a laptop with a high-def front-facing camera, or even “unlock” extra security features that necessitate a camera… there’s nothing suspicious or creepy about making a high-def front-facing camera a publicly stated hard requirement.
Oh, hi NSA! We were just having an innoculus discussion. Don’t mind us.
Yep. This one and sbupdate-git from AUR are very convenient tools that drastically reduce the hassle of managing custom Secure Boot keys. I use the latter but this one looks very promising too.
Does it work with Dual boot? I don’t think sbctl is currently entitled to work with Dual boot as I have to delete Microsoft Keys from BIOS, before working with Manjaro SB.
You don’t have to delete MS keys, but you need to manually backup stock vendor-provided keys (PK, KEK, db and dbx), then create your own PK, KEK and db keys, then concatenate your db and KEK with vendor db and KEK you saved before, sign resulting files with PK (for compound KEK) and KEK (for compound db) and then enroll one by one starting from dbx and db, then KEK and the last one is PK while in Secure Boot setup mode (entered when one clears SB keys in UEFI settings). https://wiki.gentoo.org/wiki/User:Sakaki/Sakaki’s_EFI_Install_Guide/Configuring_Secure_Boot#Saving_Current_Keystore_Values.2C_and_Creating_New_Keys
After that, sbupdate will take care of the rest.
There’s other thing you can try. Just sign Windows bootloader with your current key. It is located in $esp/EFI/Microsoft/bootmgfw.efi. So it will make Windows boot without MS keys enrolled in UEFI.
You need to manually backup stock vendor-provided keys (PK, KEK, db and dbx), then create your own PK, KEK and db keys, then concatenate your db and KEK with vendor db and KEK you saved before, sign resulting files with PK (for compound KEK) and KEK (for compound db) and then enroll one by one starting from dbx and db, then KEK and the last one is PK while in Secure Boot setup mode (entered when one clears SB keys in UEFI settings).
I tried really hard, step by step, taking hours and never succeed booting Manjaro in a dual-boot Windows environment with Secure Boot enabled.
What bothers me is that Debian, OpenSuse, Ubuntu, Fedora can do it out of the box. As far I could read, Fedora developed its own way and it is not paying MS for the keys. I really doubt the others are paying. But I’m not sure.
There’s nothing wrong in using any of those distros if you really need Secure Boot. All of them are still GNU/Linux after all. Manjaro is a small and mostly community-driven distro which kinda cannot afford (it can but cannot lol) messing with such a niche stuff as Secure Boot. Partially because corporate / server use cases of Manjaro are little to nothing, partially due to vast ignorance of home Linux users on the essence of Secure Boot, who would refuse to accept things like paying “MS” even if it’s not MS actually and as if non-participating would make them rootkit-proof.
Since you didn’t describe your exact issue, I cannot suggest anything that would be of help.
I can only wildguess:
First, make sure to install grub this way and sign it with your db.key. Also sign your kernel.
In case of grub/shim issues try booting without bootloader using only kernel. Create a new NVRAM boot entry with something like sudo efibootmgr -c -d /dev/sda -p 1 -L "Manjaro 5.14" -l /vmlinuz-5.14-x86_64 -u ' ro quiet initrd=\intel-ucode.img initrd=\initramfs-5.14-x86_64.img apparmor=1 security=apparmor audit=0' -v and try booting it directly.
In case of problems related to enrolling of PK/KEK/db/dbx, consider using KeyTool.efi (from efitools package). Many BIOSes have no means to manipulate keys and many systems do not allow efi-updatevar to do its job so the only way to do what you want might be KeyTool.
Another reason could be your BIOS is bugged and/or old, and in such a case you have no option other than using Fedora’s or Ubuntu’s shim – and that’s if you’re lucky to have BIOS that allows such workaround. There are cases when there’s no even that way, and that’s a reason to consider a better MOBO/laptop vendor if Secure Boot is absolutely necessary.
They all do pay. And the payee is not MS but a certificate authority founded by MS. If you live in a democratic country, consider this analogy: you pay taxes to your government but you do not fund your ministers directly, there’s a budget that is being discussed and established on a regular basis.
Hello everyone, I only post this.
I have a dual boot with Manjaro and Windows 11. Previously I had the dual boot with windows 10, the only thing I do is update thought their assistant and that’s all.
I’m on a HP X360 convertible 14-cd0xx, and this work smoothly with Manjaro Gnome 21.1.4
Used Windows 11 Installation Assistant to upgrade to Win 11 on Lenovo Yoga 720. It’s a little quirky at times, widgets are all but useless and do not retain configurations. Performance seems slightly slower than Win10 for now. I don’t yet see a compelling reason for anyone to upgrade, at least not on a system similar to mine–i5 8th generation; 8GB; SSD; Intel 630 graphics. This system “qualified” for Win 11.
The installation was done with SB enabled but I disabled it afterwards. Win 11 boots without error messages with SB disabled. I don’t know how it might behave with the next update. MS appears to be hesitant with its Win 11 policies.
@XoirDrioX What does this mean? Can it boot with secure boot on?
Some UEFI like Lenovo has nothing different between secure boot on/off, but others like Surface show a annoying red lock sign which is VERY UGLY if you turn Secure Boot off
No.
You can’t just enable Secure Boot and have a bootable Manjaro. There’s no easy way to have both Windows and Manjaro working with Secure Boot enabled. That being said, there is a difficult and long way to do it though.
But there is no red lock sign on Windows 11 for me if Secure Boot was off for a long time in my Desktop PC.
I know Windows 11 only needs TPM 2.0 chip.
I suspect that Windows key was already preinstalled in Secure Boot in your device, that is why the red lock sign appears when Secure Boot is turned off with the existing key.
Maybe delete this Window key in Secure Boot, then no more red sign, but better not try (it can break Windows 11)
Interesting. Does this red stripe and lock thingie show up when you boot Manjaro? Or only when booting Windows? If the latter then sorry there’s no place for discussing Windows-specific issues on Manjaro forum.
But if the former then it is most likely provided by UEFI firmware.
I’m currently writing a comprehensive tutorial on enabling Secure Boot and making use of TPM to unlock encrypted system partition on boot to provide BitLocker-like experience in Manjaro, but it is going to be huge and probably make you suffer even more since it involves a lot of manual fiddling with configs and other error-prone shenanigans so you’ll have to choose between unfortunate absence of deed and dangerous actions that, in event of mistake, may result in extra hour(s) of recovery. I’m wicked and I know it
You should probably contact the manufacturer to “fix” their firmware
Most likely Micro$oft will tell you that’s it’s purse blasphemy to disable SB and install linux on it though
protect the boot chain. Works fantastic in Windows, kills off unverified drivers, any tampering triggers Bitlocker recovery. Secure boot is 100% needed for work environment. Work computer at home must be on par with pro workstation where SB saturation is close to 100% (for both Windows and Linux). And with covid, SB is needed even more than ever before.
I had Manjaro, and I had to turn off SB temporarily each time, and later type Bitlocker recovery key each time. Got tired of it, really.
We were just having an innoculus discussion. Don’t mind us.
