Tag Archives: Linux

I Guess it’s Back to Gentoo Then

Posted by in Reviews > Software

To preface this post, it was started as a draft a few months back titled “Back to Gentoo”. At the time it was obvious all was not well in Funtoo land, and for my specific use cases, it was no longer serving its purpose. In the mean time, the BDFL of Funtoo officially discontinued the Funtoo project back on July 26th, 2024 and later revised its status to “hobby mode”.

Funtoo was fun, until recently, when the wheels just fell off. Between stupid errors like new .0 releases of packages not knowing that the distributed files remove the .0 (so the source isn’t found and the build fails), and progressively worse Wayland and KDE support Funtoo is no longer fun. Oh, and Docker broke.

In my opinion, the one thing Funtoo did better was a much better profile system. Funtoo used a layered profile system which had “mixins” which you used to specify what you wanted the system to be. Using intel graphics? Use a mixin. Using KDE plasma? Use a mixin. It essentially was an abstraction of the USE flag system, which was more focused on use cases instead of low level features. The beauty being, if a package’s USE flags changed, you didn’t end up in circular dependency resolution hell quite as often.

Gentoo doesn’t have this. In Gentoo you pick a single profile (so Gentoo has a lot of profiles to handle the various configuration permutations that exist). This isn’t great, it doesn’t scale, and, honestly, it’s a mess. That said, after setting up two servers with Gentoo, I think I can get over the clunky profiles. I took the time to actually setup a distribution kernel with custom config.d overrides. Now, kernel updates are almost painless. While Funtoo had a way of doing the same thing (managed custom kernel config, build, and install), my insistence on using efistub precluded using it, so I had been using genkernel.

Next up on the migration docket are a couple of HTPCs that are not able to run Steam OS, and finally my daily driver laptop (well, if I’m being honest, it’s about time to replace the laptop anyways as the battery is starting to reach the end of its useful life).

-John Havlik

Intel Arc A380 as a Plex Media Server Transcoding Accelerator on Linux

Posted by in Guides

Previously, if one wanted hardware accelerated transcoding in one’s Plex Media Server, the options were to either use a Nvidia card, or use an Intel CPU with QuickSync (and a platform that enables the iGPU). With Intel releasing the Arc series of GPUs, a 3rd option emerged. Recently, low profile variants of both the Arc A380 and Arc A310 have become widely available, presenting a low cost, low power, and easy to fit hardware transcoding option. On the software side, not much is needed to get hardware accelerated transcoding working with the Arc A380/A310.

Drivers

First up, you will need the Intel graphics drivers in your kernel. Check your distro’s guides for how to do this (Gentoo has a fairly good wiki entry on this). One item to note, the choice of whether to compile the driver as a module or include it in the kernel depends on your setup. A general rule of thumb that has worked for me: if you use an initramfs, compile the DRM_I915 driver as a module; if you use efistub as your bootloader, build the driver into your kernel and include the firmware into the kernel image.

If you need to include the firmware into the kernel image (building the DRM_I915 driver into the kernel instead of as a module), you will need to install the linux-firmware package before compiling your kernel. Under the firmware loader settings, you’ll need to include the following firmware blobs: the dg2_dmc, dg2_guc, and dg2_huc. As of Linux 6.4.13 these are the versions the i915 driver will want: i915/dg2_dmc_ver2_08.bin i915/dg2_guc_70.bin i915/dg2_huc_gsc.bin

Userland

After rebooting with the new kernel, within the Plex Settings, under the Transcoding section, enabling hardware acceleration should be available. Additionally, the Arc A380/A310 should show up in the Hardware transcoding device dropdown. Make sure both “Use hardware acceleration when available” and “Use hardware-accelerated video encoding” are checked. For the “Hardware transcoding device” option, if you have other GPUs, you may want to select the Arc device so it is targeted. Don’t forget to press the “Save Changes” button.

While Plex is now finding the device, it still may not be able to use it just yet. If libva isn’t installed, Plex will not be able to use the Arc GPU for transcoding. For funtoo users, ensure that your profile has the gfxcard-intel mix-in (for Gentoo make sure you have intel in your VIDEO_CARDS setting in make.conf) and then install libva. At this point, hardware transcoding should work. You can double check this by using intel_gpu_top while playing a video. Another method of checking if hardware transcoding is working is through the “Now Playing” section of the Plex dashboard. If you see a (hw) next to the codec and the word Transcode in the video section, hardware transcoding is working.

Note that getting hardware transcoding working with Plex Media Server only required the Intel graphics Linux kernel driver, some firmware blobs, and libva. X server, Wayland, a window manager, and desktop environment were not needed or installed.

-John Havlik

Fixing the ‘btrfs block device size is smaller than total_bytes in device item’ Error

Posted by in Guides

Recently, I ran into a problem with an old SSD formatted with btrfs. The filesystem refused to mount. Checking dmesg I had an error stating that "the device total_bytes should be at most NUMBER1 but found NUBMER2", where NUMBER1 is less than NUMBER2.

The solution is to use the relatively new fix-device-size feature in btrfs rescue. This was added sometime after 2022, likely in Linux 6.3 (the patch to add this feature was submitted in the kernel developer mailing list in mid-2022). At the moment, I can confirm that 6.4.13 has this feature. Syntax wise, the command is:

btrfs rescue fix-device-size <device>

Just replace <device> with the /dev/ path to the device you are having issues mounting due to the size missmatch. This should work for most cases where the total_bytes for the device is only ‘slightly’ larger than the actual device size.

-John Havlik

Notes on LUKS + EFISTUB

Posted by in Guides

Running off of an encrypted root filesystem has been one of those things that never seemed to float to the top of the todo list. However, back in December (2018, this article lived in the drafts bin for quite some time), it finally made it to the top of the todo list. At the time, one was preparing the Dell XPS 15 9550 to replace the Ideapad s405 for travel. Encrypting everything seemed prudent for a travel laptop.

As of the writing of this article, LUKS is the standard way of encrypting a filesystem in Linux. Generally, a boot loader is used to kick off an initramfs which loads the basics (need LVM, dm-crypt, and LUKS) and prompts for the passphrase for decrypting the root filesystem. If you’re fine with running a boot loader, most guides will get you going with LUKS quite quickly.

However, running a full boot loader on UEFI systems feels archaic. There is just something about using the kernel’s built-in EFISTUB that feels more elegant. And, this is where things divert from the bog-standard path. Typically, when using the EFISTUB, one does not bother with an initramfs (compile the kernel for you known hardware set and you’re good to go). However, an initramfs is integral to having an encrypted root partition.

initramfs Woes

The first problem started with trying to get a working initramfs. Since one had not used an initramfs with EFISTUB previously, there were a few hurdles to overcome. Initially, one tried to use an external initramfs. However, the 9550 does not allow/pass UEFI parameters nicely, and using the built-in kernel command line to specify an external initrfamfs in the EFI boot partition did not work. So, the initramfs needs to be built into the kernel for the XPS15 9550. This lead to a second problem.

Initially, the initramfs that genkernel builds was tried. Unfortunately, it appears this is (as of late 2018) broken/not-suitable for situations where the initramfs needs to be bundled into the kernel. Luckily, betterinitramfs can be bundled into the kernel.

Naturally, there is one gotcha to keep in mind regarding betterinitramfs. As distributed, betterinitramfs does not populate /dev/disk/by-uuid et al. as it does not provide udev (or eudev). The end result is real root needs to be specified using /dev/BLOCKDEVICENAME rather than using PARTUUID.

Conclusion

While the setup of using EFISTUB with an LUKS encrypted root partition is a little esoteric, it is possible to get working. There are a bunch of UEFI related pitfalls waiting to snare you—different platforms will have a different mix of issues. Then again, all UEFI systems should be able to use the initramfs embedded in the kernel when using the EFISTUB boot loader. Regardless, this path is not advised for those learning about/using LUKS for the first time.

-John Havlik

U2F and Firefox on Funtoo

Posted by in General

U2F is pretty neat. It can be used locally on a machine for authentication and for two factor authentication on websites. There are even plugins for using it on WordPress powered websites. At the time this article was written, Firefox does not enable U2F by default. Though, that looks to be changing with Firefox 68.

Enable U2F in Firefox

Enabling U2F in Firefox is fairly straightforward. In the URL bar enter: about:config. Then search for u2f. There should be an entry: security.webauth.u2f, set it to true.

Install pam_u2f

However, simply enabling U2F in Firefox is not enough for a U2F device to work. To get everything working, pam_u2f needs to be installed. On Funtoo, this is quite simple:

emerge -av pam_u2f

After installing pam_u2f, Firefox should now be able to query your U2F key.