Alright, let's dig into why fc-list isn't picking up your font even after installation and running fc-cache—I've dealt with similar quirky issues on minimal or custom Linux setups before. Here are the most likely culprits to check:

• Wrong installation path for the font
  Fontconfig (the system behind fc-list and fc-cache) only scans specific default directories by default: /usr/share/fonts, /usr/local/share/fonts, and ~/.fonts (or ~/.local/share/fonts on newer systems). If you dropped your font file somewhere else (like a random folder in your home directory), fc-cache won't find it automatically.
  Fix: Move the font to one of the standard directories, or run fc-cache -v /path/to/your/custom/font/directory to force a scan of that specific path. The -v flag will show you exactly which directories it's processing, so you can confirm your font path is included.

• Corrupted or unsupported font file
  Even if you "installed" the font, if the file itself is damaged or uses a format Fontconfig doesn't recognize, it won't show up. For example, some old bitmap fonts, proprietary formats, or partially downloaded files might be rejected.
  Fix: Run file /path/to/your/font-file.ttf (replace with your font's actual path/extension) to verify the file type. Look for output like TrueType font data or OpenType font data—if it says something like data or invalid, the file is corrupted. Re-download or obtain a valid copy of the font.

• Fontconfig configuration issues
  Custom or minimal blackbox systems often have stripped-down or modified Fontconfig configs. It's possible the config files (located in /etc/fonts/) are excluding your font path, have filtering rules that block the font, or are missing entirely.
  Fix: Check /etc/fonts/fonts.conf and the files in /etc/fonts/conf.d/ for lines that might restrict font scanning. For example, look for <dir> tags that don't include your font directory, or <selectfont> rules that filter out certain font types. If the config is missing, you might need to install the full fontconfig package (though if fc-list runs, it's probably installed).

• Permission problems
  If your font file or its parent directory has restrictive permissions, Fontconfig (running as your user) might not be able to read it. This is common if you installed the font as root but are running fc-list as a regular user.
  Fix: Run ls -l /path/to/your/font-file to check permissions. The file should have at least r (read) permissions for all users (e.g., 644), and the directory should have rx permissions (e.g., 755). Use chmod 644 /path/to/your/font-file and chmod 755 /path/to/font-directory to fix this, then re-run fc-cache.

• Blackbox system-specific limitations
  Some blackbox Linux environments (like embedded systems, stripped-down containers, or custom distros) don't use Fontconfig as their primary font manager. The "one font" mentioned in uname -a might be a kernel-level or system-default font tied to a different graphics stack (like DirectFB or framebuffer) that doesn't integrate with fc-list.
  Fix: Check if your system uses an alternative font system. For example, some embedded setups use fbset or custom font loading scripts instead of Fontconfig. In this case, fc-list won't detect the system font, and you might need to use tools specific to your environment to manage fonts.

Start with the first two checks (path and file integrity)—they're the most common fixes. If those don't work, move on to permissions and configs, then consider system-specific quirks.

内容的提问来源于stack exchange，提问作者Paul Taylor