As if it mattered.

If the Lenovo forums are anything to go by, getting audio to come out of the TV when connecting a Lenovo laptop via HDMI in non-obvious for many folks, regardless of the operating system in use. Under KDE Plasma with PulseAudio, the volume control applet does not add an output device for HDMI audio as it does when connecting a USB audio device, so there is no GUI method to choose which output device to switch to Configuration pane can be used to switch the Built-in Audio profile from ‘Analog Stereo Duplex’ to ‘Digital Stereo (HDMI) Output’. That’s it, that’s all – it doesn’t auto-switch, you have to do it for yourself. The rest of this article might be of interest to command-line adherents, plus it has a couple of useful kernel config tips to ensure your HDMI support is compiled in in a usable manner.

Thanks to Thorsten’s 2017 response on this AskUbuntu post, the solution (at least for my Lenovo X1 Carbon 5th generation) is to use the pactl command line tool. This command lists the cards available on the system in order to obtain the correct card #:

pactl list

With the card # identified, the following command can be used to switch to the HDMI output (the numeric value is the card #):

pactl set-card-profile 1 output:hdmi-stereo+input:analog-stereo

The following command will switch back to the built-in speakers, or else I found that it did automatically switch back when I unplugged the HDMI cable:

pactl set-card-profile 1 output:analog-stereo+input:analog-stereo

As a final point, all this will only work if you have enabled HD Audio in your kernel settings and compiled the HD audio codecs as modules. Why? Well:

1. The X1 Carbon uses an Intel HD audio solution, which is part of the Intel integrated video chipset.
2. The Intel integrated video is supported by the i915 driver. Since this depends on a firmware blob it must be built (or, rather, it is wiser to build it) as a module rather than compiled into the kernel. As a consequence, support for the audio parts of this chipset must also be built as modules otherwise, though the kernel will compile without errors, dmesg will throw “Unable to bind the codec” errors and you’ll have no HDMI audio support at all.
3. Intel have used a range of codecs from various manufacturers in the various chipsets supported by the i915 driver, so it is simplest to compile all the codecs as modules and let udev pick the right one for you at boot time.

EQ10Q appears to be the absolute best quality equalizer available for Linux. I have tried that that comes with pulse-effects, but found that it introduced occasional audio glitches; no good for audiophile use.

EQ10Q is an LV2 plugin, so I start from the assumption that you already have JACK installed (doing so is trivial so I will not include instructions here). The following set of steps are what I used to get EQ10Q working:

1. Emerge dev-cpp/gtkmm, since eq10q depends upon it for it’s UI.
2. Download and install eq10q (do not use the ebuild available in the darkelf repo).
3. Attach the audio-overlay repo (layman -a audio-overlay).
4. Emerge media-sound/carla (requires accepting the live ebuild in package.use, plus enable the gtk2 flag because the eq10q UI uses GTK2).
5. Run carla and add /usr/local/lib/lv2 to where carla looks for LV2 plugins.

tl;dr

If you use NFS shares and/or want your workstation to have a static LAN IP and want seamless wired<->wireless LAN roaming under Gentoo/OpenRC, then dhcpcd is your go-to network manager. But not without a bit of manual tweaking..

Use Case

You have the following requirements:

• your workstation is a laptop that moves between wired and wireless connections within your LAN
• you use NFS shares that you would like auto-reconnected when roaming between connections, and auto-connected on boot regardless of the connection available at that time (at the very least, do not hang on boot due to unavailable shares)
• you require your workstation to have a static LAN IP so as to be able to reliably expose services it hosts outside the LAN (i.e. so as to forward ports from your router to it)

Solution

I don’t know if it’s just me, but network roaming under Gentoo using the default netifrc + ifplugd system is just not reliable. Maybe it’s that ifplugd isn’t oriented towards wireless connections, maybe it’s that my usual wired ethernet port is on a USB-C dock, maybe it’s the NFS shares I use, but I was continually finding myself without a path to my LAN when switching from one form of connection to another or have it lock up trying to remount shares. Having bashed my head against this for some weeks I re-read the Gentoo network management article for the millionth time, once again decided against migrating to Network Manager (and its associated systemd leanings), but for the first time noticed that it mentions in passing that the simplest network management solution is to use dhcpcd in Master mode.

So then, I uninstalled ifplugd and the netifrc services in favour of dhcpcd. The latter is admirably install-and-forget, but will not assign a static address to any interface by default. Whilst it can support static IP assignment, in order to use it one needs to specify the configuration for every local interface else confusing badness will transpire¹. The approach I chose instead is to use DHCP and apply IP reservation at the DHCP server to maintain a predictable address. Explanation of how to do that is beyond the scope of this article (I don’t know what DHCP server you’re using).

Okay, so now we have a system that will pick up an IP address as it roams from wired to wireless connections and back. Mount-at-boot NFS mounts will not handle this cleanly at all though, so the second part of the magic is to do away with static mounts in /etc/fstab entirely, in favour of using autofs to mount them on demand. Installation and configuration is documented admirably at the Gentoo site, so I will not duplicate that here.

That’s all there is to it! It seems trivial in retrospect, but I put up with all manner of half-working solutions on the way here, so I thought it worth documenting anyway.

1. If you have multiple local ethernet ports it’ll assign the same address to all of them regardless of whether they’re even up, resulting in bizarre routing problems. The worst of these issues is that down interfaces receive a metric of 0, that is to say the most preferred, meaning that LAN routing fails because it tries to use interfaces that aren’t up!↩︎

Blending together the Gentoo Kernel Upgrade Guide with the excellent Gentoo/ZFS/NVME SSD installation articles by Guy Robot I synthesized the following set of steps, which I am well pleased to say went without a hitch first time :o) Please note this is an upgrade article only and assumes you already have a working system that boots ZFS. If you’re starting from scratch please follow Guy Robot’s articles linked above.
If you’re already there and genuinely only want to upgrade your kernel then please read on..

1. Obviously enough, start with updating the relevant packages (sys-kernel/linux-firmware, sys-kernel/gentoo-sources, sys-fs/zfs, sys-fs/zfs-kmod; note that since v0.8 ZFS no longer relies upon sys-kernel/spl so this can be unmerged). In my case I just went for a complete emerge update @world:
   

   emaint -a sync
   emerge –update –deep –changed-use –keep-going @world

2. Ensure that the file /etc/portage/savedconfig/sys-kernel/linux-firmware points to (or is) a file containing the list of only the firmware blobs to compile into the kernel (the remainder should be commented out or deleted). If you are not doing so already, I recommend setting the savedconfig USE variable for the sys-kernel/linux-firmware package so that future emerges retain your config; your set of required firmware is not likely to change from one kernel build to the next.
3. The /usr/src/linux symlink points to the kernel source package directory. This needs to be updated to point to the location we wish to use for this build. Emerging the gentoo-sources package with USE=symlink would do this for us automatically, but there are other packages out there that need to know where to find our current source, so it’s best that we manage this manually. The Gentoo way is to use the eselect command:
   

   eselect kernel list
   eselect kernel set <the index number of the new source dir>

4. We’ll now do some work in the kernel dir. Change into it explicitly to ensure picking the new location of the symlink:
   

   cd /usr/src/linux

5. Copy the currently-running kernel’s config to the new kernel’s source dir to use it as a basis:
   

   cp /boot/kernels/<currently-running kernel dir>/config /usr/src/linux/.config

6. We already have the NVME support enabled from the original install (see Guy Robot’s article for details), so next we need to update the config to match the new kernel version (i.e. bring in options that are new since the last time we built it). In the past I have used make olddefconfig to do this, which supposedly keeps your existing settings and selects sane defaults for any new settings but I got burned badly by it once, so now I use:
   

   make oldconfig

   which instead prompts you to select values for any new settings that exist in the new kernel version and not in your old one; with a bit of searching it’s possible to work out what the right option should be for your hardware.

7. Processor manufacturers periodically release microcode patches to fix bugs. Gentoo includes several methods to identify which ones apply to your processor and to build them into the kernel. The generic instructions are here and the Intel-specific procedure is here, the final steps of which involve using…
8. …the graphical kernel config tool – maybe in browsing through it you’ll additionally find options you now want to enable, or perhaps disable:
   

   make menuconfig

   And do remember to save your changes before quitting the tool.

9. Right, we’re ready to build the kernel. The time this takes is very variable. It seems that small changes in config mean small build times; I have had it take between a couple of minutes to around 1 hour on my Intel i7-7600U. Set the -j parameter to the number of processor cores you have plus one:
   

   make -j5

10. I’m honestly not certain that it’s necessary to rebuild ZFS against the new kernel sources, but since we are about to rebuild the ZFS kernel module it seems prudent:
    

    emerge sys-fs/zfs

11. Rebuild the kernel modules (zfs-kmod and any others you’re using) against the new sources:
    

    emerge @module-rebuild

12. Install the kernel and modules (they aren’t actually used until we reconfigure grub to know about them, so not to worry):
    

    make modules_install
    make install

13. The modules get installed to /lib/modules/<kernel version>, and the kernel and it’s ancilliary files will be installed to /boot. For neatness and the ability to roll back in case of problems we will keep the existing kernel alongside the new, so create subdirs in the form /boot/kernels/<kernel version dir> and move/rename vmlinuz, config and System.map from /boot to there.
14. Now we need to build an init ramdisk that’ll import our ZFS pools at boot time. First step here is to use Fearedbliss’ tool to create one that is Gentoo/ZFS-friendly (N.B. I’m assuming you’ve already added the necessary Portage overlay to your repos.conf, as explained in Guy Robot’s article)
    

    emerge bliss-initramfs

    Since v8.1.0, this tool is configured via command-line options plus a settings file at /etc/bliss-initramfs/settings.json. If you are using the systemd init then you can go right ahead, but if you’re using OpenRC then edit the settings to change udevProvider to /sbin/udevd. The command line is as follows in either case:

    bliss-initramfs -k <new kernel version>

    When it has finished, copy the resulting initrd-<kernel version> file from /usr/src/linux to /boot/kernels/<kernel version dir>/initrd

15. We now need to edit the configuration within the init ramdisk to have it mount our zpools explicitly. Folllow the instructions in Guy Robot’s article starting from “We now need to modify the initramfs.” and up until “Now you have a custom initramfs…” :o)
16. Next we need to let grub know about our new kernel so we can select it at boot. Edit /boot/grub/grub.cfg to set the timeout to 3 (temporarily until we’re happy with the new kernel) and add a menu item like the below, updating the kernel version number appropriately:
    

    menuentry “Gentoo – 4.19.52-gentoo-FC.01” {
    linux /@/kernels/4.19.52-gentoo-FC.01/vmlinuz root=rpool/ROOT/gentoo resume=/dev/nvme0n1p3 by=id elevator=noop quiet logo.nologo refresh
    initrd /@/kernels/4.19.52-gentoo-FC.01/initrd
    }

17. Take a deep breath and test your work:
    

    reboot

18. The ‘refresh’ option at the end of the grub menu entry should be used just once – it forces ZFS to purge its cache. We want to have this happen in between one version of the module and another, but not at every reboot, so go back in and edit grub.cfg to remove this option.
19. Once you are happy with your new kernel, you will want to ensure it’s source code sticks around because some other packages depend on it when building. To prevent it being unmerged when new versions are released, preserve the gentoo-sources package version by adding it to @world:
    

    emerge –noreplace sys-kernel/gentoo-sources:<version>

20. You can then do the opposite for the ‘outgoing’ kernel, so that at the next emerge @world it will be removed:
    

    emerge –deselect =sys-kernel/gentoo-sources-<version>

21. You’ll need to edit grub.cfg one more time to remove the menu entry for the old kernel version and set timeout back to 0 so that you don’t see the menu on booting.
22. Finally, delete the old kernel’s subfolders under /boot/kernels and /usr/src. You’re done! Enjoy new kernel goodness :)

tl;dr

If you have multiple network interfaces and cannot guarantee that all will always be up, but have other services that depend upon network availability, set rc_depend_strict=”NO” in /etc/rc.conf.

I habitually use a wireless network at home and tether my cellphone whilst out and about. I was finding that the VPN service refused to start when I switch network, complaining that the non-started network was not available. By default, Gentoo openvpn’s rc init script has a depend on ‘net’, which I had assumed was interpreted as ‘any network interface’, but in fact by default in OpenRC this identifier is interpreted as all network interfaces. To change this behaviour edit /etc/rc.conf and set rc_depend_strict=”NO”. Simple as that – net will now be interpreted as any interface instead of all interfaces.