I’ve been loving my new desktop setup for about ~four months now. I also think it’s pretty nifty that this system has only booted anaconda and containers! The integrated graphics were pretty impressive, but the simple, occasional CAD work I do quickly exposed the weakness in this area. I also want a setup that can offload some AI models to the GPU. I had heard that it’s painful to buy a GPU right now – that’s an understatement. As I write this, NVIDIA is in the middle of releasing the 50xx series and scalpers are working hard to buy them all. Anyway, I settled on a cheaper one from Amazon, until the stars align for me to get something like the 5090.

If you’ve ever used Linux with a “team green” GPU, you’ve no doubt run into the fun world of drivers on Linux. We’ve known that using image mode & bootc would be a powerful tool for managing dependencies like this, but this is the first time I had the opportunity to get hands-on. This post will walk through some of the possible scenarios for handling GPU drivers on Fedora, CentOS Stream, & RHEL when building bootc images.

Continue reading “GPU Drivers & bootable containers (bootc)”

A few days ago an electrical storm took out my trusty APU 1d. At first I thought that it was only the power supply that died, but the WAN NIC is not recognized ~80% of the time. I thought I could simply just use the OPT1 port instead, but no. Randomly the WAN port will reappear and wreak havoc with the system and basically stop all traffic on my network until it would again randomly disappear. It was an amazing piece of equipment, as was my trusty Alix 2d3 before it. ….even though I love these systems, it’s time to move on.

I wanted to try OPNSence instead of pfSense for this install. The only real hiccup I ran into moving over was around DHCP support for HTTP Boot. The pfSense team added a UI option for this not too long ago and it’s been super helpful for some of the Red Hat related provisioning testing I’ve put together. Anyway, my RFE was justifiably declined due to the deprecation of ISC dhcpd. No worries because it was pointed out that it’s super simple to add dhcp configuration drop-ins manually.

Adding dhcpd config outside of the UI

The project documentation does a great job of outlining how to do this. Basically just SSH to the system, create a file under: /usr/local/etc/dhcpd.opnsense.d/ and paste in the following w/ the correct IP & path for your environment:

class "httpclients" {
option vendor-class-identifier "HTTPClient";
match if substring (option vendor-class-identifier, 0, 10) = "HTTPClient";
filename "http://[webserverip]/path-to-efi-nbp";
}

That’s it! Once this file has been written, just reload/restart the DHCP server and the config will take effect. If you’re using a RHEL or Red Hat derived distro you’ll want to load the shim for grub as the NBP (network boot program). This is typically /EFI/BOOT/BOOTX64.EFI on the boot media. If you want to move out of the stone ages w/ PXE/TFTP, HTTP booting straight from the firmware is awesome. Basically, just copy the boot media to a web server, modify the grub menu as needed (you’ll likely need to adjust the kernel & initrd paths to align w/ your web server path), and finally pass the desired NBP. If you’re coming from the PXE world, there’s a good chance you’re using pxelinux.0 or some flavor of ipxe, that will get replaced with grub. Easy peasy!

Raised garden beds are fantastic because they drain well, are relatively easy to build, and are capable of producing an impressive yield of food. Amanda and I have built a couple of these based on the Pioneer Woman’s blog post on this subject. These worked really well for us, but we wanted to step up our garden and needed to solve two problems: 1) more space 2) protect against rabbits and our crazy dog. Other geographies will need different adaptations to protect against different pesky critters, for example burrowing animals. The design shown here should lend itself fairly well to various types of adaptations. If you come up with something neat please share it with us!

Continue reading “Rabbit-proof Raised Garden Bed”

About a year ago I started working with HTTP boot. It’s great that we no longer need a TFTP server for network booting, but there are also a few less than ideal challenges with the newer method. The biggest one is lack of documentation and simple configuration with DHCP servers. There are some examples available for the isc-dhcp-server used in many Linux/Unix systems, but if you’re using something like Ubiquiti or pfSense, good luck! It’s been a while since I’ve looked at an enterprise IPAM setup, but I fully expect support to be lacking there as well.

I opened a bug on this issue and was really impressed with how quickly the team jumped on it. Now if you’re running the 2.6.0 release, which is the latest as I write this, it’s pretty simple to get this up and running. Basically they added a field for UEFI HTTPBoot. It sounds simple enough right?

But adding it wasn’t working on either of my systems. I did a little packet sniffing and compared the response I was getting from my pfSense system vs a working dhcpd config in RHEL. In short, pfSense wasn’t sending option vendor-class-identifier “HTTPClient” with the response so my systems weren’t responding to the URL. Luckily it’s super simple to add this in the UI. Basically just add an additional option w/ the number 60, Type Text, and HTTPClient in the Value section. As seen here:

And that’s pretty much it. My network now offers up both PXE and HTTP boot to clients and it works really well. Hopefully this will help someone until this option is provided by default when the “UEFI HTTPBoot URL” is used.

Now all that’s left is to come up with a menu system that’s as powerful as syslinux that works with HTTP Boot. To date, I’ve only used GRUB and ……it really makes me miss the menu system from syslinux. It’s superior in every way IMO.