Linux Cookbooks

Eric Lawler

December 24, 2019

Filed under “

I am forever losing random blog posts that explain the mysterious inner workings of Advanced Linux Components: udev, kmod, UEFI kernel mod signing, etc.

Rather than continue to accrue bookmarks that rot over time, I’m going to start writing down what I’ve learned, so I can reference it on a domain that won’t disappear in 3 years…

Installing nVidia drivers + Optimus in Fedora UEFI secure boot

Optimus is nVidia’s tech for switching loads from the lame-o built-in Intel GPUiGPU, for integrated to the beefy, discrete nVidia GPUeGPU, for, uh, not-the-intel-one in your workstation-y, game-y laptops. They have A New Thing now they call PRIME Render Offload that does High-Level Magic to render things on the beefy eGPU then feed it to the iGPU for display in the same X session.

nVidia added Linux support for PRIME in early 2019 or so, judging from the dates on internet comment threads. Fedora 31 supports all the patches to the X11 upstream natively–one of many reasons that Fedora and Arch are the only Linux distributions worth installing. And, surprisingly, RPM Fusion has a functioning kmod package for the nVidia drivers that’s new enough to support PRIME. Convenient!


  1. dnf install akmod-nvidia
  2. pgrep kmod–wait for the module to finish compiling before doing anything else, sheesh.
  3. You already added your 509 DER sign-y keysWait, you do have 509 DER sign-y keys, right? No? Then, sheesh, do this: openssl req -new -x509 -newkey rsa:2048 -keyout MOK.priv -outform DER -out MOK.der -nodes -days 36500 -subj “/CN=Eric Lawler Gave Me This Script and I Ran It Without Changing Any Values/” to the UEFI MOK, right? If not:
    1. mokutil --import your-public-key.der
    2. Give mokutil a nice password
    3. Reboot your machine
    4. Tell the lovely BIOS blue screen you want to add a new key. You should choose View key #0 to ensure that’s the one you added. Is it good through 2119? It probably should be. You don’t want your extra kernel modules to stop working next century, right?
    5. ADD THE KEY. You’ll have to enter your password from step ii (pronounced aiai).
    6. And that’s it. When you boot, you can sign things with that MOK key.
  4. Sign all the nVidia kernel modules with your DER key. You’ll have to do this every time you update the nVidia drivers or install a new kernel. Same as VirtualBox. I have a simple sh script:
KERNEL=$(uname -r)

echo 'Signing kernel modules for nvidia...'
for i in /usr/lib/modules/$KERNEL/extra/nvidia/*ko; do
  echo "...signing $i"
  sudo /usr/src/kernels/$KERNEL/scripts/sign-file sha256 my-private-key.priv my-public-key.der "$i";
echo 'Starting kernel modules'
sudo modprobe -v nvidia

…except that, of course, the kernel modules can’t start while nouveau is loaded. So reboot one more time after the first install to be running with nVidia’s drivers.

How to use it?

To use your laptop’s beefy nVidia GPU, append this environment string to whatever you’re running: __NV_PRIME_RENDER_OFFLOAD=1 __GLX_VENDOR_LIBRARY_NAME=nvidia [program]

Steam launchers can be modified like so: __NV_PRIME_RENDER_OFFLOAD=1 __GLX_VENDOR_LIBRARY_NAME=nvidia %command%

Signing VirtualBox drivers

  1. Add a new MOK as in the nVidia instructions above.
  2. Find your driver:
    • updatedb && locate vboxdrv …or
    • modinfo -n vboxdrv
  3. Sign it. (This is the path from the RPM Fusion repo.)
KERNEL=$(uname -r)

echo 'Signing kernel modules for VirtualBox...'
for i in /lib/modules/$KERNEL/extra/VirtualBox/*ko; do
  echo "...signing $i"
  sudo /usr/src/kernels/$KERNEL/scripts/sign-file sha256 my-private-key.priv my-public-key.der "$i";
echo 'Starting kernel modules'
sudo modprobe -v vboxdrv

Remapping caps lock to backspace, 2019 edition

This one’s a real mess, but I’m too lazy to type it out now. I’m trusting that this dangling appendage will embarrass shame me into completing it, since the new Ask Fedora is absolutely, 100% useless and all the old Ask Fedora content (now rebranded as will vanish soon, including Ahmad Samir’s ridiculously useful answer to my udev question from 2013.

tldr? Dig into the udev Readmes/usr/lib/udev/hwdb.d/60-keyboard.hwdb hiding on your system to learn all the udev utilities to run and monitor output while poking keys on your keyboard. Then you’ll suss out the manufacturer specific serial numbers/device IDs you can use to run rules or straight-up remap the hardware, as I do.

Some of the the data for identifying keyboards is hidden in the evtest command’s output. The generic USB keyboard rules are:

evdev:name:<input device name>:phys:<phys>:ev:<ev>:dmi:bvn*:bvr*:bd*:svn<vendor>:pn*

When you start evtest and choose your keyboard, you’ll see this printed:

Input driver version is 1.0.1
Input device ID: bus 0x11 vendor 0x1 product 0x1 version 0xab41
Input device name: "AT Translated Set 2 keyboard"

Which you can translate to: evdev:input:b0011v0001p0001eAB41

AT KeyboardsHonestly, I’m not sure what this type of input device is. PS/2? The laptop keyboard is an AT device. can be identified using the data from modalias:

[root@kohlenstoff ~]# cat /sys/class/dmi/id/modalias

Here is my cookbook, for the next computer I purchase. Plop this in /lib/udev/hwdb.d/90-custom-keyboard.hwdb, in Linux kernel 5.X+ and this will cause the kernel to translate all slaps of the caps lock key, useless invention that it is, as a backspace key to every single application on your system: In X and Wayland and Virtual Terminals alike.

# Dell XPS 15
# Exact match: evdev:input:b0011v0001p0001eAB41*
# All Dell keyboards:

# generic Logitech

# Microsoft Sculpt Ergo Keyboard

# Microsoft Natural Ergonomic Keyboard 4000

Don’t Panic

When you upgrade your system, these rules will appear to stop working. Before you grind your molars to dust and embark on an hour-long update to this blog post, just remember that systemd updates its rules on a schedule that is vague.

Post-update to systemd / your OS, follow the instructions given in the 60-keyboard rules file to remind Linux that Caps Lock is dead to you:

[root@kohlenstoff ~]# systemd-hwdb update
[root@kohlenstoff ~]# udevadm trigger --verbose --sysname-match="event*"
[long list of events that changed printed here]
^-- welcome back, double backspace!

Merry Christmas.

Finalized at 5:51 PM. Tidied up on October 26, 2020 @ 10:53 AM.

Tagged with reference and how-to.

On Tough Conversations

Eric Lawler

October 16, 2019

Filed under “

CTOs at sunset “CTOs at Sunset” - October 11, 2019. This looked better on my phone. It doesn’t have a shallow-enough depth of field when focused on infinity for the shot I was trying to create.

I had the opportunity to attend my third 0111 Conference last week. This year’s emphasis was on creating a retreat-like atmosphere where CTOs and engineering leaders can let their metaphorical hair down and share their challenges and strategies for overcoming those challenges with their deeply-empathetic peers.

The final day had us break into small groups to go through an abbreviated version of Brené Brown’s Dare to Lead training. Leona de Vinne, a leadership coach and emotional intelligence consultant, facilitated the day’s events.

The group I was part of included a diverse collection of CTOs: Among others, there was 7CTO’s Growth CTO of the Year, Mr. Scott Williams of CDBaby (they still exist!), to a serial-entrepreneur-CTO, to a code-slinging, React-loving development agency founder, to… me, whatever I amServant-leader, jack-of-all-trades startup CTO on sabbatical?.

Mrs. Brown’s research led her to create a detailed list of 10 cultural issues caused by a lack of vulnerability, which the Dare to Lead book and training seeks to correct through both theory and practice. The #1 issue caused by “armoring up” and refusing to be vulnerable with your coworkers? Avoiding tough conversations! Other issues included spending unreasonable amounts of time managing problematic behaviors (#2), having a culture of shame and blame (#6), and not learning and growing due to perfectionism and fear (#10).

We had a chance to walk the room and use sticky notes to cast 3 votes on iconic corporate “flipcharts” labeled with each of the 10 reasons–which of the 10 reasons most resonated with us? Unsurprisingly, the top reason from Mrs. Brown’s research was far-and-away the winner with this crowd of CTOs. #1 was absolutely covered in stickies–43, to be precise–from a group of 70-odd people.

Each group was then assigned a cultural issue, with the instructions to, you know, just go ahead and solve the problem. Come up with some strategies to fix these problems identified across companies, cultures, and continents. No big deal, right? And, of course, our table was assigned the #1 problem: How do you stop avoiding tough conversations?

I was designated note-takerI’m definitely not a pen snob and brought my daily drivers to the conference, fully Nipponsei kit: A Midori A5 notebook, Uni Jetstream Alpha soft-grip pen with 0.7mm Uni/Mitusbishi Jetstream ink. and tasked with compiling my group’s whirling thoughts into something cohesive. After getting it all down on paper, I was asked to distill the fruit of a 20-minute discussion into a mere two sentence soundbite for the other conference attendees. Hardly room to expound on the problem. 😒

Without even more belabored introductions, here’s my notes from the group’s discussion. This is a mix of strategies to take the sting out of tough conversations and create space and context for them to happen:

  • Creating a psychologically safe space to hold tough conversations encourages people to share their true feelings–creating vulnerability and letting you resolve root issues.
  • Working to empower the “quietest voice” can make it easier to hold productive tough conversations, ensuring more introverted employees have their needs met.
  • Anonymous employee feedback can provide direction towards what tough conversations we’re avoiding: What’s being swept under the rug or ignored?
  • Separating facts from feelings, such as by having blameless post-mortems after experiencing problems, aids in creating a safe space to hold tough conversations.
  • The CEO has to model having tough conversations. If this isn’t permeating the top of your org chart, you’re unlikely to see it happening between peers at the lowest levels.
  • The RACIThis is an excellent tool, by the way. It stands for Responsible, Accountable, Consulted, and Informed. It’s used in product management to make sure everyone’s on the same page in terms of who’s responsible for what business processes and product development areas. Going over the RACI sheet with the senior leadership team, for the first time, is often painful. framework/exercise aids in peer-related tough conversations: Addressing perceived conflicts in who’s responsible for what.
  • Similarly, having codified values/characteristics/traits/DNA for the company crates an accountability framework for conversations concerning violations of those principles. They give you a common language to aid in having a fact-oriented conversation, removing the feeling that this is a personal attack.
  • Not permitting long delays between a principle’s violation and the ensuing tough conversation reduces the stress of having to hold that conversation. Reinforcing good communication practices (see Radical Candor for a treatise on this) aids this effort.
  • And, I’m not sure what you could do with this one, but bold, Slack-obsessed cultures could consider adding a #tough-conversations channel. But if you’re willing to use that, it sounds as if you don’t have issues with vulnerability and humility in your organization. 🤔

Given more than the 20 or so minutes we had to brainstorm, there’s obviously a lot more strategies for creating more (healthy) vulnerability in an organization, and ensuring that those tough conversations our human nature drives us to avoid happen.

What have I missed? As ever, feel free to contact me and let me know what’s worked for you.