So the Linux journey has been long and fun, but I’ve gotta take a break from tinkering for a while for work. I’m down to my last few problem points and would love some assistance:
- I want to know if there is any way at all to reduce and ideally eliminate the screen flickering that happens when rEFInd initially boots? My screen flashes gray three times before rEFInd shows up and I’ve tried adding & removing linux from the use_graphics_for option and mess with resolutions to no avail.
- Is there anyway I can get an encrypted Garuda system to work with Secure Boot? I’ve gotten rEFInd and OpenSUSE Tumbleweed to work, but no lock with Garuda despite attempting all of the MOK enrollment and shim copying.
- Please for the love of god tell me there’s a way to Miracast / screen mirror / wireless display! I’ve tried gnome-network-displays and miraclecast on both distros, X11 & Wayland, native FireTV & Microsoft Display Adapter all to no avail.
- Finally, I know this is a broken record, but if anybody anywhere has gotten a KVM program like Synergy / Barrier / Input-Leap / rkvm / nikau to work with a Linux Wayland Server and MacOS client, help a brother out.
Any help is greatly appreciated!
That’s your firmware and/or rEFInd’s fault. Tweaking flags for the Linux kernel will do nothing here.
Intel iGPUs can do flicker-free boot from the bootloader on.
What do you need secure boot for?
Probably to ensure their system isn’t tampered with? Depending on who you hang with, that may be in your threat model.
Secure boot is only one small link in a chain of things that need to be working in order to have a system that is only halfway resistant against evil maids.
If you’re running Garuda, the rest of the chain is not present in any way.
Secure boot + encryption is enough for evil maids. They already said they had an encrypted system.
Secure boot + encryption willy happily boot the maid’s initrd.
No, because either the initrd is signed, built into a signed unified kerbel image, or it’s encrypted like on my setup (where everything but the grubx64.efi binary is encrypted and that binary is signed).
You mean, like, there’s some more setup you need to do in order to build some actual resistance against evil maids; making secure boot a small part of a greater link?
Also, I still wouldn’t count such a setup as “half-way resistant against evil maids” as, in a setup like you describe, it’s almost trivial for an evil maid to go into firmware to disable secure boot and install their own bootloader instead of yours.
Well, they don’t seem to be replying to this post, so I guess we will never know if they have a BIOS password or even are signing or encrypting their initrd.
I still can’t figure out how to tag people from eternity (infinity for lemmy).