Showing posts with label Linux. Show all posts
Showing posts with label Linux. Show all posts

Sunday, July 12, 2026

Fedora 44

A couple of weeks I installed Fedora 44 but not as an upgrade like I normally do.  I had to do a clean  install because btrfs indicated there was a problem with the file system.  It became noticeable when a system backup was happening and it kept running into errors.  At one point, the whole system went into read-only mode (which is what btrfs will do when it runs into an issue).  

On reboot, everything "seemed" okay and the hardware checks didn't reveal any issue with the drive.  However, the logs and btrfs' health check indicated an error.  The suggestion was that it was safest to reformat the partition and reinstall everything and that's what I eventually did.

Fedora 44 worked without any problems and it was a quick install to get everything up-and-running again.  It gave me a chance to rework my install scripts and update them.  One package (golang-github-nvidia-container-toolkit) that was available in Fedora 43 for enabling Nvidia GPU access to containers was not available for Fedora 44.  It seems like to get it approved for Fedora 44 so because of that I didn't try do upgrade the other machines.  I'll see if the package will eventually get into the Fedora core package so I don't have to add the Copr repo just for that.

Sunday, July 5, 2026

ComfyUI in a Container

Setting up ComfyUI in a Podman container on Fedora Linux with a Nvidia GPU.

Prepare Persistent Directories

Create directories on your host machine to store your models, custom nodes, outputs, and user data. This ensures your configurations and large model files survive container restarts and updates.

mkdir -p ~/comfyui/{models,custom_nodes,output,user}

Create the Container Image

We will build a custom image based on Debian (python:3.11-slim).

Note: We explicitly include the GNU C-compilers (gcc, g++) via apt. This is required because the Triton library (used by PyTorch) needs to dynamically compile GPU kernels when ComfyUI starts. Without them, Triton will throw a 0 active drivers error.

Create a file named Containerfile in your current directory with the following contents:

# Use a slim Python 3.11 image as the base (Debian-based)
FROM python:3.11-slim

WORKDIR /app

# Install system dependencies (including C compilers for Triton and OpenGL for OpenCV)
RUN apt-get update && apt-get install -y \
    git \
    libgl1 \
    libglib2.0-0 \
    gcc \
    g++ \
    && rm -rf /var/lib/apt/lists/*

# Clone the latest ComfyUI repository
RUN git clone https://github.com/comfyanonymous/ComfyUI.git .

# Install PyTorch with CUDA 13.0 support (Required for RTX 50-series)
RUN pip install --no-cache-dir torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu130

# Install standard ComfyUI dependencies
RUN pip install --no-cache-dir -r requirements.txt

EXPOSE 8188

# Bind to 0.0.0.0 so the host network can access the web interface
CMD ["python", "main.py", "--listen", "0.0.0.0"]

Build the image using Podman:

podman build -t comfyui-nvidia .

Deploy the Container

Run the container using the configuration below.

Critical Fedora-Specific Flags to Note:

  • --security-opt label=disable: This disables SELinux separation specifically for this container, preventing SELinux from blocking the execution of the injected Nvidia driver binaries (libcuda.so).
  • :Z (on volume mounts): Instructs Podman to label the mounted host directories with a private unconfined SELinux context, allowing the container read/write access.
podman run -d \
  --name comfyui \
  --security-opt label=disable \
  --device nvidia.com/gpu=all \
  -p 8188:8188 \
  -v ~/comfyui/models:/app/models:Z \
  -v ~/comfyui/custom_nodes:/app/custom_nodes:Z \
  -v ~/comfyui/output:/app/output:Z \
  -v ~/comfyui/user:/app/user:Z \
  localhost/comfyui-nvidia

Automate Firewall for Remote Access (Optional)

If you want to access ComfyUI from another device on your network, you must open port 8188 in Fedora's firewall. Instead of leaving the port open permanently, you can use a wrapper script that temporarily opens it when ComfyUI starts, and securely closes it when the container stops.

Create a file named start_comfyui.sh:

#!/bin/bash

echo "Opening firewall port 8188..."
sudo firewall-cmd --add-port=8188/tcp

echo "Starting ComfyUI container..."
# The --attach flag keeps the script running until the container is stopped
podman start --attach comfyui

echo "Container stopped. Closing firewall port..."
sudo firewall-cmd --remove-port=8188/tcp

Make the script executable and run it whenever you want to start your server for remote access:

chmod +x start_comfyui.sh
./start_comfyui.sh

Access and Day-to-Day Management

Once deployed, you can access the ComfyUI web interface by opening your browser and navigating to:
http://localhost:8188 (or your machine's local IP address if accessing from another device on the network).

Useful Podman Commands

  • Check Startup Logs: Monitor the initialization process or kernel compilations:
    podman logs -f comfyui
  • Stop the Server:
    podman stop comfyui
  • Start the Server:
    podman start comfyui
  • Clean up Disk Space: After rebuilding images (e.g., updating ComfyUI in the future), run this to delete dangling, unnamed images and recover gigabytes of storage space:
    podman image prune

Friday, July 3, 2026

How to Create a Windows 11 Bootable USB on Fedora Linux (Without Third-Party Apps)

 Microsoft's Media Creation Tool is only for Windows so what happens if you're on Linux?  I didn't want to download another third party tool when I don't need to.  Fedora (and most Linux) had all the tools needed in the distribution to do this. 

This article tells you how to do it manually but I'm lazy and wanted a script to do it and it is now available on Github.

Monday, May 4, 2026

Chrome and Fedora Crashes With Multi-Monitor Setup

 I've noticed with more frequency that after waking from sleep, Chrome or some of its tabs will crash.  It can happen immediately or shortly after.  A kernel crash or system freeze  happens less frequently but is more disruptive when they happen.


This is happening on my main system that has 3 monitors (2 are 120Hz), an AMD CPU with integrated graphics and a discrete Nvidia GPU.  The monitors are connected to the motherboard (1 HDMI and 2 DisplayPort that are daisy-chained) rather than to the discrete graphics so I can preserve as much VRAM for LLM inference.

Initially, I though the culprit was the Nvidia driver since the most common responses on the Internet mention them.  The next most common response was to turn off hardware acceleration in Chrome. 

chrome://gpu revealed that the iGPU was only being allocated 512MB of memory which not enough with a multi-monitor setup.  This was being automatically set in the BIOS so I changed the UMA Frame Buffer Size (Found under NB Configuration)  to 1GB.

Next, Chrome showed it knew there are two graphics option so this tells it to almost use the integrated graphics.  

google-chrome-stable --disable-gpu-driver-bug-workarounds --gpu-testing-vendor-id=<vendor id> --gpu-testing-device-id=<device id>

There are some settings for the Nvidia card that might also improve stability.  Edit /etc/modprobe.d/nvidia.conf and add the following settings might improve stability but might also slow waking up:

options nvidia "NVreg_PreserveVideoMemoryAllocations=1"
options nvidia "NVreg_TemporaryFilePath=/var/tmp"
options nvidia "NVreg_EnableS0ixPowerManagement=1"
options nvidia "NVreg_PreserveVideoMemoryAllocations=1"

To make sure the system leverage these values:

sudo dracut -f 
sudo reboot

Tip: Restart the Cinnamon process without losing your open windows by pressing Alt + F2, typing r, and hitting Enter

Sunday, April 19, 2026

Fedora 42 to 43

 Time to do another upgrade of Fedora (from 42 to 43).  I didn't find any immediate issue with the upgrade so nothing to report.

Friday, March 21, 2025

Running Kokoro-82M Text-to-Speech on Fedora with Nivdia GPU with Podman

I got interested in Kokoro, a new text-to-speech model that only uses 82 million parameters but is one of the top models on the TTS leaderboard.  I wanted to run it locally and a quick way to try it is to use Kokoro-FastAPI which comes in a Docker container.  The README on Kokoro-FastAPI’s github has instructions using Docker (with or without GPU), but I’m using Podman so I need to do some setup on Fedora to enable Podman access the GPU.

The instructions on the Podman and Nvidia site have you set up an Nvidia Repository to get the container kit that enables Podman to access the GPU, but in my previous post on installing Nvidia and CUDA drivers on Fedora I mentioned that there can be dependency conflicts.  I wasn't sure if the Nvidia container kit might also cause problems, but fortunately, you can just install the packages from Fedora's repo and avoid possible headaches: 

sudo dnf install golang-github-nvidia-container-toolkit

Assuming that you already installed Podman (if not, follow the Fedora doc on installing Docker and/or Podman) and you have an GPU, you can download and run:

docker run --device nvidia.com/gpu=all -p 8880:8880 ghcr.io/remsky/kokoro-fastapi-gpu:v0.2.2

If SELinux blocks Podman from accessing the GPU, you can follow Podman's instruction about giving permission for containers to access the GPU: 

sudo setsebool -P container_use_devices true

Then run the `docker run ...` command above and it should start.

This a quick way to give Kokoro a try.  I'll probably try to run it next with Go by using the onnxruntime to load the Kokoro-Onnx model.

Sunday, January 26, 2025

Upgrading from Fedora 40 to 41

 Decided it's time to upgrade from Fedora 40 to 41 and it was a smooth upgrade.  Will update if I run into any issues, but I've already been running 41 on a laptop for a couple of months so I know that 41 works for what I need and this time it was to upgrade systems that was already running an earlier version.

Wednesday, January 1, 2025

Powerline Error in VIM with Git

On Fedora 41, opening a Go file that is checked into Git results an error message that flashes briefly before VIM shows the file.  I'm not sure what is the exact cause but it went away when I uninstalled powerline and reinstalled it.   When uninstalling just powerline, it also uninstalled VIM for some reason the re-install was actually `dnf install vim powerline`.

Friday, December 13, 2024

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


Friday, November 8, 2024

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

Tuesday, October 22, 2024

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 (im-chooser) 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. 

*** Update 3/2024 ***

The above method stopped working on Fedora 41 (Cinnamon).  It seems like the Input Method Selector (im-chooser) isn't able to talk to ibus so it won't start the ibus-daemon.  A more direct way to is to run the ibus-setup and ibus-daemon yourself.

First, add to your .bashrc the following lines:

export GTK_IM_MODULE=ibus
export XMODIFIERS=@im=ibus
export QT_IM_MODULE=ibus

Then the following commands can be used:

ibus-setup

Lets you set up the languages, short-cut keys, etc.

ibus-daemon -d

Starts the daemon in the background.

There's another system called fcitx that can be used instead of ibus.  

Friday, September 27, 2024

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.

Saturday, September 21, 2024

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"
sudo dnf group install development-tools # dnf5

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 akmod-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.

Thursday, May 30, 2024

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.  :-(


Saturday, April 13, 2024

Upgrading Fedora 38 to Fedora 39

 Even though Fedora 40 is coming out in a few days (or because of it), it was time to upgrade from 38 to 39.  

No immediately noticeable problem.  It downloaded the packages, installed and rebooted with no problems. 

One reason is that my Fedora 38 ran into problems with NUT being able to load the driver to the UPS.  This seemed to be because Fedora 38 had upgraded the NUT packages and there's an issue.  I noticed that Fedora 39 actually uses the previous package version and when the system came up after the upgrade, NUT was working again.

Friday, April 12, 2024

Remembering Multi-Monitor Layout on Linux

Problem

I currently have the three monitors daisy-chained so the PC is connect to one monitor through USB-C DisplayPort and then daisy-chained to the other through standard DisplayPort cables.  This set up has a problem when the PC suspends or restarts.  Sometimes the first display gets no signals from the PC (thus none of the others does either) or just the last display gets no signals.  In either case, turning off-and-on will bring up all the displays (which I'm guessing allows the PC and monitor to do their handshake properly), but the layout of the displays are forgotten.  

Diagnoses

There seems to be two problems:  

  1. One is that that when the system comes up that the monitor is not able communicate with it causing it to not wake up.  This could be some kind of race condition, but I'm not certain.
  2. The display output names gets changed where Monitor A is sometimes referred to as DisplayPort-4 and another time it can be named DisplayPort-1.  The info I've found seems to point to this being caused by the video drivers who is responsible for setting the output names (e.g. DisplayPort-1, DP-1, etc.).

Solution(s)

I don't have a solution for #1, but the solution/workaround for #2 can mitigates it.

Linux uses the RandR (Resize and Rotate X Windows Extension) and the xrandr tool can be used but the parameters becomes long when there's multiple monitors, different rotations and positions that are relative to each other.  Another tool that helps is arandr which is a GUI front-end to xrandr that has a feature to save layout into a script that can be run.  Once you have your layout setup, it can export it to a script that you can re-run, but I ran into two problems:

  1. It doesn't capture the order of the displays (which is on the right, middle and left) so while all three might be in the right rotation, they are not in the right order.
  2. The name of the display sometimes changes (e.g. a display might once be called DisplayPort-1 get tuned into DisplayPort-4) and then the script also doesn't work.
Finally, I found a tool called autorandr which will finger print the display so that even though the name changes, it still knows which monitor is which.  It can also save different profiles such as a laptop with no external monitor and another one with one external monitor which it will then recognize and load the appropriate profile automatically.  On Fedora, installing the autorandr package will install /usr/lib/udev/rules.d/40-monitor-hotplug.rules which tells it to run autorandr. 

Since the issue I'm having is that the output names change, I needed to tell autorandr to use the fingerprint signature which is done with the '--match-edid' flag.   One option is to modify the udev rule with this flag (remember to use systemd-delta to check future differences with the distribution package version) or manually run autorandr with the flag.   I did the latter (/usr/bin/autorandr -c --default default) since I'm still testing to see if it does what I hope it'll do.

Friday, December 22, 2023

Upgrading to Fedora 38

Upgraded from Fedora 37 to 38 following the standard instructions.  There were no errors indicated during the upgrade.  The packages was downloaded, installed and the system rebooted.   When I came back to the machine after the upgrade and got to the login screen, my USB mouse was functioning sporadically.  I could still log in with the keyboard but it felt slow and Fedora had a warning that something didn't load correctly.

I powered down the system and then turned in back on (the usual if the hardware isn't working first give it a "kick") and everything seemed to be working normally.  It might be because my mouse is connected to the desktop through the monitor's USB input?

Once I was back on, I did a 

sudo dnf update

to see if I was current and it gave the following error

Problem 1: cannot install the best update candidate for package libheif-freeworld-1.15.1-4.fc38.x86_64
  - nothing provides libheif(x86-64) = 1.17.5 needed by libheif-freeworld-1.17.5-1.fc38.x86_64 from rpmfusion-free-updates
 Problem 2: problem with installed package libheif-freeworld-1.15.1-4.fc38.x86_64
  - package libheif-freeworld-1.15.1-4.fc38.x86_64 from @System requires libheif(x86-64) = 1.15.1, but none of the providers can be installed
  - package libheif-freeworld-1.15.1-4.fc38.x86_64 from rpmfusion-free requires libheif(x86-64) = 1.15.1, but none of the providers can be installed
  - cannot install both libheif-1.16.2-2.fc38.x86_64 from updates and libheif-1.15.1-2.fc38.x86_64 from @System
  - cannot install both libheif-1.16.2-2.fc38.x86_64 from updates and libheif-1.15.1-2.fc38.x86_64 from fedora
  - cannot install the best update candidate for package libheif-1.15.1-2.fc38.x86_64
  - nothing provides libheif(x86-64) = 1.17.5 needed by libheif-freeworld-1.17.5-1.fc38.x86_64 from rpmfusion-free-updates
================================================================================
 Package             Arch     Version            Repository                Size
================================================================================
Skipping packages with conflicts:
(add '--best --allowerasing' to command line to force their upgrade):
 libheif             x86_64   1.16.2-2.fc38      updates                  298 k
Skipping packages with broken dependencies:
 libheif-freeworld   x86_64   1.17.5-1.fc38      rpmfusion-free-updates    59 k

Transaction Summary
================================================================================
Skip  2 Packages

Nothing to do.
Complete!
The output's suggestion of using --best and --allowerasing didn't work so search yielded two threads about this issue from months ago:
  • https://discussion.fedoraproject.org/t/unknown-update-error-with-libheif/81302
  • https://discussion.fedoraproject.org/t/rpmfusion-free-updates-libheif-freeworld-and-libheif-version-conflict/82240/7
Although the threads implied that it's been resolved and people had proposed different workarounds the simplest solution for me was simply to remove libheif-freeworld package:

sudo dnf remove libheif-freeworld

This seemed to resolve the issue.

The above threads indicated that a fix was submitted but it might now be broken again since when I searched for the various package versions on Fedora and rpmfusion, the working versions of the packages weren't there:

sudo dnf search --showduplicates libheif
Maybe it's the timing of my upgrade that ran into this problem.  Fortunately, it was a quick and easy fix but sadly I can't say that this was a completely seamless upgrade.

Monday, January 16, 2023

Setting Up Fedora Linux With Cyberpower UPS

These are my notes on how I set up my Fedora Linux desktop to listen to a Cyberpower UPS to known when to shutdown when there is a power outage.  This is only for one machine connected directly to the UPS through usb and doesn't cover when there are multiple machines that needs to be shutdown.

The simplest way to configure your Linux system to work with a Cyberpower UPS is probably to use Cyberpower's PowerPanel for Linux software, but I didn't use it since I wanted to see if I can use non-proprietary software.  Instead, I used the open-source Network UPS Tools (NUT) but it required a bit of manual work to get it configured.

All I want to do is to have my PC shutdown a few minutes after the power go out of the house so I bought a Cyberpower UPS and use the direct USB connection for it to communicate with the PC.

Once connected, check that Linux can see the UPS:

# lsusb

You should see the UPS listed among the list of USB devices.

Install the NUT software:

# sudo dnf install nut nut-client

This will install NUT and there are 5 key configuration files to be aware of:

  1. ups.conf - settings for UPS driver
  2. upsd.conf - settings for UPS daemon
  3. upsd.users - access control file for the UPS daemon
  4. upsmon.conf - settings for the UPS monitoring daemon
  5. upssched.conf - settings for scheduler daemon

Once NUT is installed, you can use one of its tools to identify the UPS and it will give you info that you can use in the config files:

# sudo nut-scanner -U

Add the information to the /etc/ups/ups.conf

[cps1500avr]
        driver = "usbhid-ups"
        port = "auto"
        vendorid = "0764"
        productid = "0501"
        product = "ST Series"
        vendor = "CPS"
   

The cps1500avr can be anything you want.  It is the name you'll be using to identify the UPS.  "usbhid-ups" is the driver for Cyberpower UPS.  All of this info came from the nut-scanner.

Add a udev rule, /etc/udev/rules.d/50-usp.rules,  so that Linux understand the UPS:

SUBSYSTEM=="usb", ATTR{idVendor}=="0764", ATTR{idProduct}=="0501", GROUP="nut" TAG+="systemd", ENV{SYSTEMD_WANTS}+="nut-server.service nut-monitor.service"

The TAG+ part is something I found on this blog for an issue with the system service not seeing the UPS and thus not able to start when the system starts up. 

Reload the UDEV rule:

# sudo udevadm control --reload-rules
# sudo udevadm trigger

Test that the driver can start and then start/enable the service:

# sudo upsdrvctl start
# sudo systemctl start nut-driver-enumerator.service
# sudo systemctl enable nut-driver-enumerator.service

Now we need to add the NUT user that will be used to monitor the UPS to /etc/ups/upsd.users

[nutmon]
        password = <password>
        uspmon primary
        action = SET
        instcmds = ALL

"nutmon" can be anything you like and then you can start the server and ask it to print out the UPS info that it sees.

# sudo systemctl start nut-server.service
# sudo systemctl enable nut-server.service
# upsc cps1500avr

Edit /etc/ups/upsmon.conf by adding:

MONITOR cps1500avr@localhost 1 nutmon  <password> primary

Start and enable the monitoring service

# sudo systemctl start nut-monitor.service
# sudo system enable nut-monitor.service

Finally, we need to tell NUT what to do when certain events happens such as when the battery is low or when it notices that the power is out.  Edit /etc/ups/upssched.conf (thanks to this article for the example)

# Gives the script to run the commands for various signals
CMDSCRIPT /usr/bin/upssched-cmd

PIPEFN /var/lib/ups/upssched.pipe
LOCKFN /var/lib/ups/upssched.lock

# Send alerts immediately on change in line power
AT ONBATT * EXECUTE onbatt
AT ONLINE * EXECUTE onpower

# (Optional) Silence the beeper after 2 minutes
AT ONBATT * START-TIMER mute_beeper 120
AT ONLINE * CANCEL-TIMER mute_beeper

# Shutdown after 5  minutes on battery (5 * 60 = 300)
AT ONBATT * START-TIMER onbatt_shutdown 300

# Cancel timer if power's restored
AT ONLINE * CANCEL-TIMER onbatt_shutdown

# Battery replacement indicated by cron'd quick test
AT REPLBATT * EXECUTE replace_batt

Then edit the command script you put in (in my case it is /usr/bin/upssched-cmd):

UPS_USERNAME="nutmon"
UPS_PASSWORD="<password>"
UPS_LINK="cps1500avr@localhost"


case $1 in
    onbatt)
        # make sure beeper is enabled
        upscmd -u ${UPS_USERNAME} -p ${UPS_PASSWORD} ${UPS_LINK} beeper.enable
        # alert
        message="Power outage, on battery"
        logger -t upssched-cmd "$message"
        ;;
    onpower)
        message="Power restored"
        logger -t upssched-cmd "$message"
        ;;
    mute_beeper)
         message="(2) minute limit exceeded, muting beeper"
         upscmd -u ${UPS_USERNAME} -p ${UPS_PASSWORD} ${UPS_LINK} beeper.mute
         ;;
    onbatt_shutdown)
        message="Triggering shutdown after (5) minutes on battery"
        logger -t upssched-cmd "$message"
        /sbin/upsmon -c fsd
        ;;
    replace_batt)
        message="Quick self-test indicates battery requires replacement"
        logger -t upssched-cmd "$message"
        ;;
    *)
        logger -t upssched-cmd "Unrecognized command: $1"
        ;;
esac
Test that it will shutdown by sending it the same shutdown signal from the UPS:
sudo upsmon -c fsd

If all goes well, get the service to start on boot:

# sudo systemctl enable nut.target
# sudo systemctl enable nut-driver.target

From now on, if the power outtage lasts more then 5 minutes (i.e. the UPS is running on battery), your system will shut down.  You'll need to manually turn the system back on when the power returns.

Notes

  • I'm not sure if something automatically started and enabled the specific driver (nut-driver@cps1500avr.service) or if I did it and just forgot to note it down.
  • This article from the Archlinux wiki described a problem that sounds like the same problem that the UDEV TAG part addresses but uses a different approach.

Saturday, January 7, 2023

Kernel 6.0.16 (and 6.0.1.17?) Causes Freeze (and how to keep previous kernels)

Update 4: Kernel 6.0.18 works!

Update 3: According to users on Reddit, 6.0.17 still exhibit the problem.  One user said that 6.0.18 has the fix.

Update 2: Decided to remove the back kernel package using the dnf remove command in the previous update rather then dnf history since I only wanted to remove the kernel.  That removed the .16 kernel from the boot loader and had the .15 as the default.

sudo dnf remove $(rpm -qa | grep ^kernel | grep 16-300)

Update:  Seems like others are also affected by the same issue with a suggestion on how to remove and block the 6.0.16 kernel.  

Find and remove  6.0.16 kernel packages:

sudo dnf remove $(rpm -qa | grep ^kernel | grep 16)


Blacklist the 6.0.16 packages from getting installed again by editing /etc/dnf/dnf.conf

# Bad packages
excludepkgs=kernel*-6.0.16-300.fc37.x86_64

Tracking bugs on Fedora:


---------------------------------------------------------------------------

Today I did a typical update of my Fedora system which included a new kernel (kernel-6.0.16-300.fc37.x86_64), but when I rebooted and logged in the system will freeze.  This might be the first time (or at least it's been a long time) that I've had a Fedora upgrade not be seamless.

Fortunately, when Fedora upgrades the kernel, it keeps copies of the previous two versions so switching back simply requires watching for the GRUB boot loading screen and picking the previous kernel.  Just make sure you do this before the system automatically boots to the latest version.

I was able to determine the freeze is caused by the kernel since booting the previous kernel showed no problems after logging in.  Knowing that I have at least one working kernel, I had two choices.  Uninstall the latest kernel or keep using the old one and wait to see if any future updates fixes the problem.

I've not uninstalled a kernel on Fedora before and was unsure what would happen.  I could also simply try to revert the entire update, but that still leaves the same question.  Using dnf, you can review what was done by:

sudo dnf history

To see the details of a specific transaction, use the ID that the history command gives and use:

sudo dnf history info <id>

With dnf, you can chose to undo or rollback a transaction.  Undo will do the opposite of what was done (e.g. uninstall or reinstall the packages) of the specific reaction while rollback will undo everything between the between the transaction and the current system.

Since I didn't want to do either since this involved the kernel, I decided to just keep rebooting to the previous kernel even though it is inconvenient and hope that it gets a fix for whatever is causing the problem.

Protecting the Previous Kernel

What if it took a few more kernel updates before the problem gets fixed and the working kernel gets removed during the update?

The versionlock plugin will lock and keep the kernel on the system.

sudo dnf install python3-dnf-plugins-extras-versionlock
sudo dnf versionlock add kernel-6.0.15-300.fc37.x86_64
The delete option will let you remove the lock:
sudo dnf versionlock delete kernel-6.0.15-300.fc37.x86_64