Happily! The big ones here were: Radare and Cutter, vscodium (not because I want it, work does), the collection of wireless tools (don't need them currently but plan to learn how to use them). I'm sure there will be others but haven't had much more than a week to mess around with it. Are you building a distro (A devuan based distro like this would be really slick)??

Another TIL! Thanks red...

So initially aptitude responded with 'hplip' so it was removed and then after another run, it came back with the following:

user@userpc:~# aptitude why avahi-daemon 
i   task-cinnamon-desktop Depends    task-desktop
i A task-desktop          Recommends avahi-daemon

So looks like cinnamon has some sort of dependency on avahi-daemon in beowulf?

I've been converting new installs to it but definitely not going back to switch MBR systems to UEFI unless absolutely necessary. Mainly just because of not wanting to switch the partitioning over.

In contrast to ToxicExMachina, I've enjoyed UEFI, there's a bunch of nice things about it (Secure Boot, efibootmgr, doing away with MBR partitions, etc), To each their own though. If you have a spare machine, try a new install and see what you think. You probably won't notice many differences until you start messing with the boot components (Grub mainly, haha).

To my understanding; If you hadn't been able to pull the package lists (apt update), then apt-cache wouldn't have had anything to search. Once you corrected the clock, I bet you ran and apt update which would've pulled down all the package lists and now apt-cache has stuff to search.

I had this problem earlier last week but was using Ceres. Screen freeze was random and unpredictable. Would be fine for only 2 minutes one boot and then it would be fine for hours the next boot. Ever since installing the nVidia proprietary driver the system has been stable and running for almost a week with no freezes. Machine is a HP Z420 with a Quadro K2000.

Since you mentioned that Windows also had the problem though, I'd be more inclined to think that you have a possible hardware issue. The card swap might be worth it to keep yourself from going crazy trying to find a software fix for a hardware issue....

Thanks HoaS, I did get it working today.

I was reading the CONFIG_EXTRA_FIRMWARE_DIR as a temporary place to hold firmware until it was compiled into the kernel but it seems that's not the purpose of that parameter. Seems that the configuration parameter simply states where within the root file-system the microcode resides and then the kernel loads it from that path on startup? I was naively assuming that the firmware was actually built into the kernel and then loaded from within the kernel itself rather than from an external source like initramfs or rootfs. Is that assessment correct?

Update just in case anyone else ever runs into this issue as well.

Looking closer at the repo kernel it looks like the ACS Override patch is applied. So all that was needed was applying the ACS override patch as well as utilizing the pcie_acs_override boot parameter. While not an ideal situation due to the potential security issues, it doesn't seem to concern any of the major distro's?? Arch, Debian, CentOS, RHEL, Ubuntu, etc all seem to provide this patch within their kernel build.

ACS override worked but is a bad idea. Looks like upgrading to a slightly newer kernel and utilizing CONFIG_PCI_MMCONFIG=y accomplished the same thing without the need for the ACS override patch.

Well good news the Toshiba worked! Was able to EFI-stub load without an initramfs and secure boot enabled. I'm hoping to repeat the steps on the HP workstation and see if I can get different results. Was shocked at how much simpler the Toshiba was than HP. Was able to do everything except toggle Secure Boot on in the Bios from within the CLI.