Arch Linux on the Framework Laptop 16

Yep, that’s a fair question. The answer is I’m not really sure, but it sounded like something that should be switched on. I’m not that familiar with the more involved aspects and features of the BIOS these days.

My drive is encrypted and I’m hoping to get to the point that I can use the fingerprint reader to unlock it on boot, instead of having to type in the pass phrase every time, and I’ve got the vague notion in my head that secure boot needs to be enabled for the TPM stuff (something else I’m not familiar with) to work, which I will probably need.

Or something like that.

That’s the problem, nowadays the word “security” is way overused, so you really need to do you own research instead of blindly believing what you have been told.

My understanding is that secure boot protects a device against running malicious code during boot, before other protective measures can be taken. Whether or not this matters will depend on your threat model.

I leave it off.

Ideally? Yes. Realistically? Probably not worth the effort.

This is accurate. The point of Secure Boot is that all of the boot items (like initramfs and grub configurations, etc) have to be signed by a key that is trusted within the UEFI configuration. If any of the boot item signatures don’t pass validation, then the boot will fail out.

Not only would you need to configure the UEFI system to enable Secure Boot, you also have to create a key-pair, mark it trusted, sign all of those files, and ensure that the BIOS/UEFI system is protected with a strong password. Not doing all of these things reduces the benefit of this protection. Its not a protection if one can just go disable it because you didn’t secure your BIOS login…

While I don’t think most people are going to be hit by something that Secure Boot would prevent, it really is up to you and what your particular threat landscape is. If you’re just a person with a laptop, it’s likely not worth the effort… If your a CEO working at a company worth millions/billions, then yes, it’s absolutely worth the extra layer of defense; having your system popped at that level is WAY more impactful than having an IT guy enable these features for you.

Everything in security is about layers, risk and threat models. It’s up to you to determine what you’re willing to do, and what level of risk you’re willing to accept.

I think full-disk encryption is more important than secure boot (in this example). It can’t be bypassed in BIOS and it’s more likely you’ll forget your laptop somewhere where FDE can help to prevent data-loss.

If you do want to enable Secure Boot, the Arch Wiki has a good primer on the topic (I know it was linked already), but you may need to more googling to get all of the way through the process. It’s not easy, and you’ll have to maintain the process as new kernel updates are released as you have to keep signing all of the boot files. I think there’s a suggestion for a pacman hook that can help in this.

Fair call, y’all. Thank-you for the feedback. Not going to stress about secure boot.

Secure Boot is really not that good and essentially forces you to use Windows or Ubuntu. In fact that’s it’s sole purpose.

1 Like

Firefox fails to use a dedicated GPU :frowning:

When I run Firefox, it usually works fine using an integrated GPU. Both 3D render and video decoding are working fine, but if I try to run it with “DRI_PRIME=1”, I get the next error:

$ DRI_PRIME=1 firefox
[GFX1-]: glxtest: ManageChildProcess failed
[GFX1-]: No GPUs detected via PCI

And it starts to use the CPU to decode video :melting_face:

Does anyone know what the issue maybe?

P.S. Steam games and Minecraft uses dGPU with “DRI_PRIME=1” no problem

You are probably the ONLY person who wants this. Firefox is my most used program when on battery and waking the dGPU for it is a complete waste.

This seems to work for me:


Interesting though. The dGPU will still go to sleep when not actively using firefox. Then when switching back to firefox, there is a 2 second delay where firefox is unresponsive while it waits for the dGPU to wake up again. Not ideal.

Minecraft does not use it for me with only DRI_PRIME=1, not sure how you are getting that to work. But the above works for Minecraft for me, not that it needs the dGPU.

Did not work for me :frowning:
It looks like there is an issue with the latest EG/Wayland. OBS is also crashing if using “DRI_PRIME”: OBS Studio began to crash after egl-wayland 1.1.14 was released · Issue #118 · NVIDIA/egl-wayland · GitHub


not that it needs the dGPU.

gamescope + Shaders + 4k :wink:

Did you enable hardware acceleration in Firefox per the Arch wiki?

Yes. The Hardware accel works fine on iGPU.

There was a major bug in the recent egl-wayland package on Arch. But Arch should have rolled it back few days ago, so if you haven’t updated try to update and see if you see a “new” package for egl-wayland.