Tag Archives: Funtoo

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

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.

Fix Linux Boot Halting on “Run /init as init process”

Posted by in Guides

In the process of removing the remaining SandForce controller based SSDs from service, the opportunity to completely refresh the Funtoo install on the XPS 15 9530 was taken. Part of this was to try to figure out why recently sddm would not start until a bit of keyboard mashing occurred (literally pushing the enter key a dozen times in a row caused sddm to start, waiting was simply not enough).

The install was fairly painless—most problems tend to be involve getting the proper device drivers compiled into the kernel. Given there was already a known good kernel config, that was used for the building the kernel on the new install. However, on the first boot off of the new SSD, the boot process halted at:

[2.754164] Freeing unused kernel image memory: 1020K
[2.756196] Write protecting the kernel read-only data: 20480k
[2.758698] Freeing unused kernel image memory: 1980K
[2.760892] Freeing unused kernel image memory: 620K
[2.764980] Run /sbin/init as init process

The init system (OpenRC), for some reason, did not actually kick off. Plugging in a USB device confirmed that the kernel itself was still running. Thus, it was not something simple such as the root device being inaccessible (that causes a kernel panic). But, in this state, the system was not usable (no login prompt).

After a bit of sleuthing and stumbling, a solution was found. The following was added to the kernel config:

CONFIG_DEVTMPFS_MOUNT=y

After rebuilding the kernel and rebooting, the system finally booted completely. Still, this is a little unnerving. This machine never needed this setting before. Additionally, I have not needed this setting on any other machine.

Tagged: ,
Updated: