1. This is with systemd-boot, which I switched to because it’s easier to use a unified kernel image with, but it should work just fine with grub as well. The last step will sign everything that needs to be signed, including grub and the kernel images.
2. You only need to trigger a re-sign if you update grub using grub-install. If you just change the grub config, you don’t need to re-sign it because the config is loaded once the signed grub is already booted. This is another reason why I went with systemd-boot and unified kernel images, because I work with sensitive data and maybe I’m a bit too paranoid, and don’t want anyone to be able to tamper with my boot in any way. This is also possible with grub and using an encrypted boot partition, but systemd + UKI + full system encryption was just easier. If you’re not worried about evil maid attacks and just want secure boot, grub will work with no additional setup.
3. No issues with the pacman hook, it triggers every time there’s a kernel update or nvidia update, and since I’m using mkinitcpio and UKI, the signing is usually already done by mkinitcpio before the pacman hook is ran, so the pacman hook doesn’t really ever do anything. It’s all done in the mkinitcpio hook.

As for bricking your motherboard, this only happens if your motherboard or any other component uses the microsoft vendor keys as part of the boot sequence, and it’s only really a hard brick if it’s your motherboard that uses it. If it’s any other component, you can remove it and readd the microsoft keys and it’ll work again when you add the component back.

And the key part here is replacing the platform keys. If you just always use the -m flag on sbctl enroll-keys, you’ll enroll both your own keys and microsoft’s, meaning no replacing necessary. If you always use -m, there’s no real risk really, because you’ll always add the microsoft keys that your hardware might need. Plus, if you’re dual booting with windows, you need the -m to have windows secure boot work, anyway.

If you’re extra paranoid, you can also add the -f option which should also include all the keys that your motherboard comes with by default, if it contains more than just microsoft’s keys, but this shouldn’t really be necessary.

I’m saying this as someone who has a self-signed key + kernel + bootloader + dual boot with windows. I have Arch and I dual boot windows, and the setup was literally three commands.

Enable secure boot setup mode and then do the following:

sbctl create-keys to create the keys

sbctl enroll-keys -m to enroll the keys to BIOS, including microsoft keys

sbctl verify | sed -E 's|^.* (/.+) is not signed$|sbctl sign -s "\1"|e' to sign everything that needs to be signed.

And everything is signed automatically on an update with a pacman hook that comes by default when installing sbctl.

That wiki entry lists all the possible ways to do it, for all combinations of bootloaders and secure boot tools. You only need one of them, for example 3.1.4. which is what I just described.

game-performance is CachyOS’ script to set the power profile to performance while the game is running and restore it to what it was before when the game closes.

game-performance is CachyOS’ script to set the power profile to performance while the game is running and restore it to what it was before when the game closes.

Edit: Also, here’s the Arch wiki page for prime-run.

Because Linux is a monolithic kernel. What that means, essentially, is that it contains all the drivers and everything else, unlike windows which uses a microkernel. The advantages of a monolithic kernel are, for instance, that you don’t need to install drivers manually, and you don’t have to depend on potentially malicious websites to host those drivers. Additionally, if any kernel ABI changes for one reason or the other, say there is a refactor to fix a vulnerability, whoever does the refactor would also refactor the driver code because that is in the kernel, and the kernel won’t compile if there’s an error in the drivers. This way, the driver is always updated, and you don’t have a situation where you have really old drivers that no longer work.

The disadvantage of a monolithic kernel is that there’s a lot more code that you have to take care of, and the kernel has a lot more responsibilities as opposed to a microkernel.

You just go into Settings > System > Developer options > Linux development environment, and enable it.

I updated to LineageOS 22.2 yesterday. It has the option, I enabled it and it works. I’m on a Pixel 8, tho. Might have something to do with it.

Sorry, my bad, I forgot that the setup script isn’t part of the default repo and is something I added in my own fork. But yeah, if there’s no systemd, it’s no use.

I can whip up a quick script that should work, I’ll test it out on my own hardware, and post it here for you sometime tomorrow.

You should definitely try with the systemd-gadgets I linked earlier. It makes all the configuration really easy, you just need to enable the relevant services, so in your case usbgadget-func-uvc.service and gadget-start.service. You also need to copy them beforehand to /etc/systemd/system, including gadget-init.service, and you need to copy gadget to /etc/default/gadget, and the scripts gadget-start.sh and gadget-init.sh to /etc/systemd/scripts. Edit /etc/default/gadget to edit the configs and names of the gadget, and then start gadget-start.service. No need to enable gadget-init.service, it’s called as a dependency from other services.

There’s an install script in the repo that you can use as well, setup.sh, and a PKGBUILD so you can create an Arch package. After installing with either method, just change /etc/default/gadget, enable the uvc and gadget start services, and then just start the gadget start service.

Hey, if you ever create that, give me a shoutout, I’d love to see it.

No, unfortunately not :/

That’s just the “name” of the configuration, for instance in my USB ethernet gadget I use both c.1 and c.2 as config names, and not a.1.

Yeah, it’s a bit weird that it works like that. I’ll be honest, in the last three or four years that I’ve been tinkering with USB gadgets, I’ve never noticed that those symlinks you create should be broken until you mentioned it. I just kinda took it for granted that it works (probably because I never had issues with this part of the process).

I’ve got some experience with Linux USB gadgets, and can confirm that the docs definitely aren’t wrong, as I’ve used them myself to write gadgets using the same symlink commands that the docs mention and that OP used here.

I’ve got a working USB ethernet gadget and MTP gadget for the Steam Deck that make the same link that should be broken, and here’s a repo that implements every USB gadget with almost every gadget making the same symlink, one directory up from where OP does it. I’ve tested all the gadgets from that repo and they all work, and because they work, I’ve forked the repo here for future use in the above mentioned Steam Deck plugin.

I can pretty confidently say that it’s not a broken symlink. I’m not 100% sure why this doesn’t work for OP, but I think it’s most likely an issue with not loading the correct driver for the UVC function.

No, this is ConfigFS, the linux kernel’s special filesystem for configuring kernel stuff, and for some reason that I don’t really know, it doesn’t matter if the symlink is relative or not. The kernel documentation even creates a relative symlink from the same directory as OP did here.

Hmm, not sure then. It seems correct to me. Check out this repo, it has systemd services for all the USB gadgets, you can run uvc very easily with this: https://github.com/BigfootACA/systemd-gadget

I can write specific instructions how to get this working later today, if you’ll need them.

Normally, you’d be right, but this special filesystem doesn’t care about that. I’ve done similar with different gadgets so many times, always with relativr symlinks, sometimes directly from the root of the special filesystem, sometimes from the gadgets own subdirectory, and it just works.

Hey, you need to also modprobe usb_f_uvc at the beggining, right after modprobe libcomposite

SUSE Linux Enterprise exists since 2000.

I mean, SUSE Linux Enterprise, the distro on which OpenSUSE Leap is based, has been developed by SUSE since 2000. It’s newest version, 15, is used in IBM’s Watson and HP’s Frontier supercomputers. I’d say it’s enterprise ready.