Using Physical Key for SSH, Git, Github For More Security

Normally, when using SSH (including SSH with Git), you generate a private and public key.  The public key is what you give to others (e.g. Github).  The private key should be kept secure and not be shared with anyone.  I don't like keeping my private keys on my laptop because mobile devices have a higher chance of being lost, stolen, or unknowingly accessed.  One solution is use a physical security key to store the private key that is plugged in to the laptop when needed.

To set this up requires having a security key such as the Yubikey from Yubico.  Then it is a matter of generating a key pair with SSH:

> ssh-keygen -t ecdsa-sk  # -t ed25519-sk is also an option but not always supported

This will generate the private key on the security key.  The generated id_ecdsa_sk file in the SSH directory is just a reference to the security key instead of the normal private key.  The id_ecdsa_sk.pub is the public key that you would share.  Whenever ssh needs to authenticate, the key will blink and with a tap of the key you'll be good to go!

For each computer that you want to use the key, you'll need to copy the reference key file to the SSH directory.

Installing Windows 11 without WIFI/Network Connection

 When installing Windows 11, it assumes you have a network connection and doesn't let you proceed with the installation.  To bypass this, press Shift+F10 to open a terminal and type:

oobe\bypassnro

The laptop will restart and when it reaches the network connection page there will be a new option for no network that will allow you to continue the installation.

Windows and Linux On a Single Drive and Installing Linux First

I previously posted on how to dual boot between Windows and Linux with each on them on separate disks, but what if you only had one storage device?  This is also possible can be a bit more messy because Windows and Linux must share the same boot partition (the part of the storage with the instructions on how to boot the OS).

The common convention is the install Windows first and then install Linux.  Windows has a "you don't need any other OS" mentality so when it gets installed it doesn't care if you have another OS, it will change the boot sequence to boot itself and you'll need to go into the UEFI menu to boot into Linux.  Linux distributions, on the other hands, comes with a boot loader that offers a menu of all the OS so that you can choose which OS to boot.  So the common convention is to

1. Install Windows
2. Resize the storage partition to make room for Linux to install.
3. Install Linux

What you end up with is that when you boot up, you'll see the Linux boot manager with the options to pick either Linux or Windows.

What happens when you install Linux first and then Windows?  Since Windows doesn't have a boot manager, it will just tell your system to boot directly into Windows.  To restore the Linux boot manager on older systems (BIOS-based), you'll need to use your Linux recovery disk and restore the boot manager (Windows mostly likely did NOT delete your Linux disk unless you installed windows on top of where you installed Linux).  

The general process is pretty similar:

1. Create a partition for Linux and Windows (just like Windows create a new partition from an existing one later)
2. Install Linux
3. Install Windows
4. Change the boot order back to Linux through the UEFI menu or efibootmgr tool (for UEFI systems) or use the Linux recovery disk (for BIOS)

On newer UEFI systems, the boot manager pointing to all the OS is still there in the boot partition but Windows only just changed it to boot its section.   You can generally change this back by going into your motherboard's UEFI menu on or on Linux you can use the efibootmgr tool to make the change.

Changing Fedora's GRUB Menu's Resolution

After installing Fedora on a laptop with a 2256 x 1504 resolution screen, the GRUB boot menu screen became too small to read.  To change the resolution, I needed to edit /etc/default/grub and replace the GRUB_TERMINAL_VALUE and add GRUB_GFXMODE with the desired resolution:

#GRUB_TERMINAL_OUTPUT="console"
GRUB_TERMINAL_OUTPUT="gfxterm"
GRUB_GFXMODE=800x600

Then commit the changes to GRUB with:

> sudo grub2-mkconfig -o /boot/grub2/grub.cfg

Determining Screw Length For Interior Walls

 

When driving screws into interior walls it's important to avoid driving into wires or pipes.  Wires and pipes going through studs should normally be going through a 1" diameter hole that is centered on the stud.

Interior drywall are typically 1/2" so a maximum screw length to avoid hitting something would be 1/2" + 1 1/4" = 1 3/4".  For a cabinet back that is 3/4" that would mean 1 3/4" + 3/4" = 2 1/2".

Object Backing	Maximum Screw Length	1" Into Stud
0	1.75	1.5
0.25	2	1.75
0.5	2.25	2
0.75	2.5	2.25
1	2.75	2.5
Drywall	0.5
Stud	1.25

Raspberry Pi Downloads Public Key

Raspberry Pi public key for https://downloads.raspberrypi.org

> gpg --keyserver hkps://keyserver.ubuntu.com --recv-key 54C3DD610D9D1B4AF82A37758738CD6B956F460C

Verifying the downloaded files with the GPG signatures that should be in the same location as the file itself.

> gpg --verify abc.xyz.sig abc.xyz

Enabling Japanese/Chinese (international) Input on Fedora

Enabling input methods for languages other than English on Fedora requires you to manually add the language that you want yourself through the Input Method Selector tool, selecting the ibus option preference and picking the input method you want to use.  I always forget this and would go to Settings > Languages or Settings > Keyboard, but neither one of those are for adding input methods. 

My Software Developer Machine for LLM Inference

I had to assemble a new PC for LLM inference work since my existing development lacked a discrete GPU so running any local LLM was extremely slow.  My aim is a dedicated development machine running Linux and will not be use for any gaming.  I wanted to keep the budget between $1500 and $2500 and wanted it to be quiet and not take up much space.  In the end, I had to make some compromises and this is what I ended up with:

Components

Gigabyte GeForce RTX 4070 Ti Super with 16GB GPU

Traditionally, a development machine didn't need a graphics card but that's different when it comes to working with LLMs so I started with the GPU and picked the .  The two makers are Nvidia and AMD but it seems like AMD cards are less supported and would require more effort to get it working.  The general consensus is that VRAM is the most important thing for running LLMs and you'd want to try to load as much of the model into the VRAM as possible so I aimed for 12-16GB*.  I picked the Gigabyte card because its length is on the shorter side and wouldn't require as large of a case to support it.

*Rough estimating the amount of memory needed by a model is to take the number of parameters and multiply it by 2 bytes (using 16 bit parameter type = 2 bytes).  A 7B model would use 14GB, 8B use 16GB, etc.  

**"How come my GPU only have 12GB of VRAM but I can a 8B model which would use 16GB?"  You might be using a quantitized/compressed model or you're using both the GPU VRAM and system RAM.  For example, if you download the default Llama 8B parameters model from Ollama, it's quantization is 4 so it doesn't take the full 16GB of memory.   If you don't have enough VRAM, then Ollama will use both system ram and VRAM:

Loading the 27B parameter Gemma model with quantization of 4 shows that it requires 18GB of memory and Ollama loaded 82% of it into the GPU's VRAM (~14.7 GB):

> ollama ps
NAME            ID              SIZE    PROCESSOR       UNTIL              
gemma2:27b      53261bc9c192    18 GB   18%/82% CPU/GPU 4 minutes from now

Nvidia shows that 14GB of its 16GB is being used matching what Ollama says:

> nvidia-smi
...
 0   N/A  N/A      2338      C   ...unners/cuda_v12/ollama_llama_server    14020MiB 
...

AMD Ryzen 7 7700X CPU (8-core, 16-threads, 4.5GHz base, 5.5Ghz Max Boost)

A solid performer for development work with integrated graphics.  AMD's integrated graphics are pretty good and by running my windows manager and GUI through the integrated graphics allows me to save the GPU for the LLMs and not use any of the GPU's VRAM.

ASUS B650M-PLUS WIFI AM5 Motherboard 

I didn't want a fancy motherboard with RGB but I did want something that is compatible and can support modern peripheral.  

Corsair Vengeance DDR5 64GB Memory

Got the DDR5 memory for the speed and 64GB since when the VRAM isn't enough for the LLM some of it will be loaded into memory.

be quiet! Pure Rock 2 CPU Cooler

I don't plan to over clock this system and the Pure Rock is well rated for being quiet and affordable.

Corsair RM750e (2023) Power Supply

Corsair 4000D Airflow Mid-Tower ATX Case

Although I would much prefer a small form factor case, doing so limits the options for the GPU and other components so this is a compromize.  The 4000D case comes with two fans and has good airflow.  When the system doesn't get as hot, the fans don't have to work as hard and the system is quieter.

Crucial P3 Plus 2TB M.2 SSD

The 1TB was out-of-stock and the 2TB was still relatively well priced.

The total price for the system came under $1900 so I was able to stay in my budget range.

Assembly and Usage

All the components came together with no compatibility problems.  I was able to get it POST and installed a fresh copy of Fedora 40.  Wifi, sounds, video, etc. all worked on the first boot.

When I first installed Ollama, it installed with support for the AMD integrated GPU since I haven't installed the Nvidia drivers yet.  Once the drivers were installed, Ollama recognized and used the NVidia GPU.  Make sure you plug your display cable to the motherboard's video port and not the Nvidia card's ports.  If you do the latter, the window manager and everything else will use the Nvidia card by default.

You can check which GPU is used using nvidia-smi to see what is running on the Nvidia card.  For AMD:

glxinfo | grep "OpenGL renderer" # See what the system is using
sudo lsof /dev/dri/* # Shows what is running on it.

Installing Nvidia and CUDA drivers on Fedora for Ollama

Ollama, a tool that lets you run Large Language Models (LLMs) on a local machine, supports the use of GPUs for better performance if you have a supported graphics card and corresponding drivers.  Having recently gotten an supported Nvidia card, I wanted to get it working with Ollama but found the available documentations on how to install the Nvidia and CUDA drivers confusing because there are multiple ways to install.  Depending on where you started your search for instructions, it can take you down different paths.

If you started on the Ollama install instruction page directs you to the Nvidia CUDA Toolkit Downloads page to have you add their CUDA repository to your Fedora instance.  From the repository you can install the CUDA toolkit, modules and drivers (CUDA and Nvidia).   For some reason, the repository currently are tagged for Fedora 37 and 39, but they seem to work for Fedora 40.  I'm not sure if that will always be the case or will work with future versions of Fedora.

If you first go to Nvidia's site to search for the driver, it will direct you to their drivers download page where you can download a .run script to install the Nvidia drivers (not CUDA).  This works but bypasses your package manager so I'm not sure if conflicts will arise in the future.  It also seems to be separate from what is in the CUDA repository so I'm not certain if there might be conflicts now or in the future.  As of this writing, installing the drivers from from the .run script and installing the CUDA toolkit from the repository does work, but I didn't install the Nvidia drivers from the repository.  

If you start with a web search or Fedora forums, the answer there is to install Nvidia from RPMFusion which has both the Nvidia and CUDA drivers.  This seems to be the most compatible version for Fedora.  If you're already using RPMFusion then it is really your only option since RPMFusion and Nvidia's repo are not compatible and will require you to do some DNF magic to get the two working together.  I also like this option because Ollama only needs the CUDA drivers and not the whole toolkit (I think you might be able to just grab the CUDA part from Nvidia's repo but their instruction directs you to download the whole toolkit).

Installing Nvidia and CUDA for Fedora

Here is how I installed a fresh new instance of Fedora 40 with Nvidia and CUDA drivers to work with Ollama.

I created a Fedora 40 Cinnamon Spin boot drive with the Fedora Media Writer and booted up the machine with it to do a clean install.  Once it finished with the installation, I rebooted the machine and set up a network connection so I can download updates and the drivers.

Open up a terminal and change the run level to 3 (multi-user command line --no GUI--)

sudo init 3

Because the first time you run sudo dnf update it'll probably update a whole bunch of the windowing systems and might cause your current window manager to crash, this avoids having the GUI and windowing system from running when you're doing the update.

Once in command-line mode, update the system with the latest packages and kernel:

sudo dnf update

Once it's been updated, reboot the system to be running on the latest kernel.  

sudo /sbin/reboot now

I went back into the level 3 since I'll be updating the graphics drivers but this time I did at the GRUB boot menu.  When the boot menu comes up, hit the 'e' key to edit and at the end of the linux line add the '3' and then CTRL-X to continue booting.   This change is not permanent. 

Install the developer tools needed to compile the modules:

sudo dnf groupinstall "Development Tools"

Now it's time to add the RPMFusion free and nonfree repos so Fedora knows where to download the drivers and modules.

You want to import the GPG key for the RPMFusion free and nonfree repos to verify that repo install packages are the actual ones:

sudo dnf install distribution-gpg-keys

sudo rpmkeys --import /usr/share/distribution-gpg-keys/rpmfusion/RPM-GPG-KEY-rpmfusion-free-fedora-$(rpm -E %fedora)

sudo rpmkeys --import /usr/share/distribution-gpg-keys/rpmfusion/RPM-GPG-KEY-rpmfusion-nonfree-fedora-$(rpm -E %fedora)

Add the repository to Fedora:

sudo dnf --setopt=localpkg_gpgcheck=1 install https://mirrors.rpmfusion.org/free/fedora/rpmfusion-free-release-$(rpm -E %fedora).noarch.rpm

sudo dnf --setopt=localpkg_gpgcheck=1 install https://mirrors.rpmfusion.org/free/fedora/rpmfusion-nonfree-release-$(rpm -E %fedora).noarch.rpm

Install the Nvidia drivers with:

sudo dnf install amkod-nvidia

Make sure that to give the system time to compile the modules AFTER the package install!  

Check that the amkod-nvidia is fully built with:

modinfo -F version nvidia

Install the CUDA drivers

sudo dnf install xorg-x11-drv-nvidia-cuda

Reboot the machine again and let it automatically go to the GUI (runlevel 5).

In a terminal, check that the Nvidia driver is being used:

nvidia-smi

Now you can install Ollama which should tell you that it has Nvidia GPU support at the end of the install.

Upgrading from Fedora 39 to 40

Upgraded to Fedora 40 following the normal procedure  hoping that it might resolve an annoying issue that started in April where SELinux kept alerting that dns_resolver is trying to setattr.  The issue is very similar to this bug except it's setting a different key.

The upgrade went without any problems but the same alerting continued.  It seems like it is caused when trying to mount an smb shared drive.  For these issues, I can usually wait for a few days and a fix is issued but in this case the bug remains open and the frequency of the alert seemed to have increased.  :-(