博客

  • 一台用了三年多的电脑突然“猝死”,从 Z690 + i7-12700K 到 Intel Core Ultra 平台升级记录

    用了三年多的台式电脑,原本一直运行得非常稳定。作为一台平时主要用于 Linux 开发、容器、虚拟机以及日常办公的工作电脑,我一直认为它还能继续服役几年。

    没想到就在上周,它毫无征兆地发生了一次严重故障,也让我经历了一次从售后维修到平台升级,再到 Fedora 44 折腾的全过程。

    很多硬件故障和选购失误,并不是因为不懂,而是因为太相信自己的经验。

    ——不要想当然。

    写下这篇文章记录整个事件


    突然断电,两次重启后彻底无法开机

    当时我的电脑配置如下:

    • CPU:Intel Core i7-12700K
    • 主板:Gigabyte Z690 AORUS ELITE
    • 电源:长城 GX850(850W)

    当天只是正常使用电脑, 突然,电脑自动断电,并立即重新启动。

    第一次重启完成后,我还没来得及检查发生了什么,电脑又再次自动断电。

    而这一次,它再也没有亮起来。

    按下电源键,没有任何反应,机器彻底无法开机。


    送修检测,主板代理商怀疑是电源导致

    经过简单排查后,我把主板送到了主板代理商进行检测。

    主板代理商检测后的判断是:

    大概率是电源出现异常,导致主板和 CPU 同时损坏。

    当然,这只是主板代理商根据检测情况给出的经验判断,并不是最终的官方检测结论。

    幸运的是,我购买的 Gigabyte Z690 AORUS ELITE 主板仍然处于四年官方保修期内,因此主板代理商直接帮我返厂维修。

    不到一周时间,主板便维修完成。

    遗憾的是,i7-12700K 已经过了保修期,因此无法申请保修,只能自行更换。

    以前一直认为 CPU 是电脑中最不容易损坏的部件之一,没想到这次却成为了整个平台升级的直接原因。

    这也是我第一次遇到 CPU 在正常使用过程中损坏。主板代理商建议我单独更换一颗新的 LGA1700 CPU,继续使用维修后的 Z690 主板。

    不过考虑到这台电脑已经使用了三年多,即使主板维修完成,再过几个月也将结束官方保修。经过权衡之后,我最终放弃了继续升级 LGA1700 平台,而是直接更换了新平台。

    干脆升级整个平台

    既然 CPU 已经损坏,我索性决定直接升级整个平台。 之所以选择 Intel Core Ultra 平台,也是希望未来几年都不用再折腾硬件升级。

    新的配置如下:

    • CPU:Intel Core Ultra 5 250K Plus
    • 主板:Gigabyte Z890M GAMING X
    • 电源:九州风神 PF850D V2 Silver

    新的电源选择了 ATX 3.1 标准产品,也希望能在未来几年更加安心。

    装好硬件之后,我继续安装自己一直使用的 Fedora 44。

    整个安装过程都比较顺利。

    驱动、开发环境、容器以及日常软件都恢复完成。

    用了两天时间,一切运行正常。

    我以为这次升级已经结束了。

    结果,很快又发现了一个问题。


    一个容易忽略的问题:后置没有 Type-C

    用了两天后,我准备用移动硬盘把之前的数据复制回来。

    直到准备插线的时候,我才发现:

    Z890M GAMING X 后置 I/O 居然没有 USB Type-C 接口。

    现在我的移动硬盘盒基本都已经是 USB Type-C,平时也经常需要高速复制文件以及开发数据。

    对于我来说,这是一个不小的使用体验问题。

    其实,这次也算是我自己踩了一个坑。

    当时选购主板时,我主要关注的是芯片组型号。看到 Z890 属于更高定位的芯片组,而 B860 属于中端定位,就下意识认为 Z890 会更加全面,因此选择了 Z890M GAMING X。

    对于 Wi-Fi 和蓝牙,当时我并没有太在意。我的电脑一直使用有线网络,平时也很少连接蓝牙设备,所以觉得有没有这些功能区别并不大。

    至于 USB Type-C,我反而完全没有去确认。

    原因也很简单——我之前使用过的好几块主板都配备了后置 Type-C 接口,甚至十年前使用的 Intel Z170 平台主板也提供了 Type-C。因此,我下意识认为现在的新主板应该都会配备这个接口,也就没有仔细查看主板的后置 I/O 配置。

    直到真正开始使用时,我才意识到,自己的这个经验判断并不适用于所有产品。

    这次经历也提醒了我,选购主板时不能只关注芯片组定位。芯片组决定的是平台功能和扩展能力,而每天真正会频繁接触的,其实是后置接口、USB 配置、网络功能等这些看似不起眼的细节。

    有时候,一块定位稍低、但接口配置更符合自己需求的主板,反而比定位更高的产品更适合自己。

    发现这个问题后,我再次联系了主板代理商,并最终决定更换主板。


    更换为 B860M AORUS ELITE WIFI6E ICE

    经过沟通,主板代理商同意让我补差价更换主板。

    最终我加了 180 元,将主板升级为 Gigabyte B860M AORUS ELITE WIFI6E ICE

    虽然最初的原因是为了获得后置 USB4 Type-C 接口,但升级之后,我得到的不只是一个接口,而是整个平台功能上的提升,包括:

    • 后置 USB4 Type-C,更方便连接高速移动硬盘、扩展坞等设备;
    • 集成 Wi-Fi 6E,无需额外安装无线网卡;
    • 集成蓝牙,方便连接耳机、键盘、鼠标等无线设备;
    • 相比之前的主板,整体接口配置也更加丰富。

    对于我这种经常使用移动硬盘、Linux 开发环境以及各种外设的人来说,补 180 元换取 USB4、Wi-Fi 6E 和蓝牙,我觉得还是比较值得的。

    当然,硬件更换之后,也意味着系统需要重新安装。

    然而,这一次新的问题又出现了。


    Fedora 44 出现了卡顿

    在新的 B860M 平台上,我发现 Fedora 44 的表现明显不太正常。

    包括:

    • Fedora Live 启动速度明显变慢;
    • 安装程序响应比较卡;
    • 系统安装过程耗时增加;
    • 系统启动速度也比之前慢。

    目前暂时判断更像是 BIOS 设置、Intel 新平台兼容性或 Linux 内核驱动方面的问题,我还在持续排查中。 等彻底解决之后,我准备单独写一篇文章,把整个排查过程完整记录下来。


    原本以为电源已经过保

    电源使用的是长城 GX850。

    这款电源是三年多前从主板代理商那里购买的,当时主板代理商提供的是 3 年店保

    因此在电脑损坏之后,我一直认为电源已经过保了。

    后来抱着试试看的想法,我查询了长城官方的保修政策。

    结果发现:

    长城 GX850 官方提供的是 7 年质保。 这一点让我有些意外,因为购买时代理商告诉我的是 3 年店保,我之前一直以为保修已经结束了。

    于是,我直接联系了长城官方售后。

    售后确认仍然处于官方保修期限内,可以寄回进行检测。

    目前,我已经把电源邮寄到了长城售后。

    官方售后告诉我,他们会:

    • 对电源进行完整检测;
    • 根据检测结果进行维修或更换良品;
    • 最终出具一份检测报告,说明检测结果及处理方式。

    因此,这次故障最终是不是由电源引起,目前还需要等待官方检测报告。

    等收到检测结果之后,我也会继续更新这篇文章。


    后续计划

    目前还有两件事情值得继续关注:

    第一,等待长城官方售后完成检测,看看检测报告会给出怎样的结论,以及最终是维修还是更换良品。

    第二,继续排查 Fedora 44 在 Gigabyte B860M AORUS ELITE WIFI6E ICE 平台上的卡顿问题,争取找到真正原因,并整理成一篇完整的技术文章分享出来。

    等这两个问题都有了最终结果,我会继续更新,希望能够把整个事件完整记录下来,也希望这些经历能给后来者提供一些参考。

    最后的感想:不要想当然

    回头看整个过程,我发现自己犯的几个错误,其实都有一个共同点——想当然。

    我以为正常使用三年多的电脑不会突然坏,结果它真的毫无征兆地停止工作。

    我以为代理商提供三年店保,就意味着电源已经过保,后来才知道官方提供的是七年质保。

    我以为 Z890 一定比 B860 更适合自己,却忽略了真正每天都会使用的后置接口。

    我以为现在的新主板都会配备后置 USB Type-C,因为连十年前的 Z170 主板都有,所以压根没有仔细确认。

    我以为换完硬件、装好 Fedora 44,这次升级就算结束了,结果又遇到了新的兼容性问题。

    这次经历让我意识到,装机也好,升级也好,排查故障也好,都不能依赖过去的经验,更不能因为”应该会有”、”以前一直都是这样”就忽略细节。

    经验固然重要,但真正可靠的,永远是确认规格、查阅资料,以及用事实验证自己的判断。

    希望我的这次经历,也能给正在装机或者准备升级硬件的朋友提个醒:不要想当然。


  • Debian 13 修改 Hostname 主机名

    在 Debian 13 中,修改主机名(Hostname)是非常基础但重要的系统管理操作。无论是部署服务器、搭建集群,还是运行各类服务,一个规范且清晰的主机名,都有助于后续运维、监控与问题排查。

    1. 查看当前 Hostname

    在修改之前,先确认当前系统主机名及系统信息:

    hostnamectl
    

    示例输出:

    Static hostname: debian
           Icon name: computer-vm
             Chassis: vm
          Machine ID: xxxxx
             Boot ID: xxxxx
        Product UUID: xxxxx
      Virtualization: kvm
    Operating System: Debian GNU/Linux 13 (trixie)
              Kernel: Linux 6.x
        Architecture: x86-64
     Hardware Vendor: Red Hat
      Hardware Model: KVM
    

    其中 Static hostname 即当前系统的主机名。

    2. 使用 hostnamectl 修改

    例如将主机名修改为 server01

    hostnamectl set-hostname server01
    

    执行后无需重启,即可看到新的主机名已更新。

    再次确认:

    hostnamectl
    

    3. 同步修改 /etc/hosts

    修改 hostname 后需要更新 /etc/hosts,避免本地解析异常或服务报错。

    编辑文件:

    nano /etc/hosts
    

    原内容示例:

    127.0.0.1   localhost
    127.0.1.1   debian
    

    修改为:

    127.0.0.1   localhost
    127.0.1.1   server01
  • Fedora 44 编译 llama.cpp 提示 GCC 16 与 CUDA 不兼容的解决方法

    作为一个喜欢尝鲜的开发者,Fedora 激进的软件源更新速度总是让人又爱又恨。这不刚把系统升级到 Fedora 44,准备用手头的NVIDIA重新编译一份最新版的 llama.cpp 来跑大模型,结果在 CMake 配置阶段系统默认的 GCC 16 太前沿了,直接被 NVIDIA 的 nvcc 拒之门外。

    在经过一番摸索(和不想折腾多版本 GCC 的挣扎)后,我成功用最轻量的方式搞定了这个“版本不兼容”的顽疾。现将这次踩坑与验证的全过程整理成文,希望能给同样在 Linux 新版本生态里折腾本地大模型的朋友们提供一点参考。

    1. 编译llama.cpp 报错

    在 Fedora 44 系统下编译 llama.cpp 并启用 CUDA 加速时,遇到一个由于 GCC 版本过高 导致的 CMake 配置失败问题。

    当执行如下编译配置命令时:

    cmake -B build \
          -DGGML_CUDA=ON \
          -DCMAKE_BUILD_TYPE=Release \
          -DCMAKE_CUDA_ARCHITECTURES=86 \
          -DCMAKE_C_FLAGS="-march=native" \
          -DCMAKE_CXX_FLAGS="-march=native"

    CMake 会直接抛出如下错误:

    /usr/local/cuda/include/crt/host_config.h:137:2: error: #error -- unsupported GNU version! gcc versions later than 15 are not supported! The nvcc flag '-allow-unsupported-compiler' can be used to override this version check;

    原因分析:
    Fedora 的软件源更新一向激进,系统默认的 GCC 版本已经来到了 16.x。而当前的 CUDA Toolkit(即使是较新的 13.x 版本)内部的 nvcc 编译器出于稳定性考虑,硬性限制了最高只支持到 GCC 15。检测到工具链版本超前流,nvcc 主动触发了宏定义错误并终止了编译。

    2. 解决方案 强行忽略版本检查

    我不想在系统中折腾多版本 GCC 切换,可以直接在 CMake 中向 nvcc 传递 -allow-unsupported-compiler 标志来忽略版本检查

    # 1. 清理缓存
    rm -rf build
    
    # 2. 重新配置 CMake 并传入显式标志
    cmake -B build \
          -DGGML_CUDA=ON \
          -DCMAKE_BUILD_TYPE=Release \
          -DCMAKE_CUDA_ARCHITECTURES=86 \
          -DCMAKE_C_FLAGS="-march=native" \
          -DCMAKE_CXX_FLAGS="-march=native" \
          -DCMAKE_CUDA_FLAGS="-allow-unsupported-compiler"
    
    # 3. 开始多核并行编译
    cmake --build build --config Release -j$(nproc)

    3. 验证 CUDA 是否成功启用

    编译完成后,可以通过 llama.cpp 自带的工具来验证 GPU 加速是否真正生效。检查基础版本与编译器信息

    liqixin@fedora:~/dev/llama.cpp/$ ./build/bin/llama-cli --version
    version:9352 (b4c0549a4)
    built with GNU 16.1.1
  • Fedora 44 完美多媒体指南:从 ffmpeg-free 完美切换完整版 FFmpeg

    在 Fedora中,由于系统默认只自带了开源且无专利争议的“阉割版” ffmpeg-free(缺乏 H.264、H.265、AAC 等常见编解码器),要享受完整的影音体验,必须将其替换为 RPM Fusion 提供的完整版 FFmpeg

    1. 添加 RPM Fusion 仓库

    为系统添加 RPM Fusion 仓库。它包含了 Fedora 官方因政策原因无法收录的自由软件(Free)和非自由软件(Nonfree,如闭源驱动和部分专利编解码器)。

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

    2. 切换到完整版 FFmpeg

    使用 dnf swap 命令,安全地将系统自带的 ffmpeg-free 替换为 RPM Fusion 提供的、带有全套编解码器的完整版 ffmpeg。

    sudo dnf swap ffmpeg-free ffmpeg --allowerasing
  • 在 Fedora 44 上安装 NVIDIA CUDA

    在最新发布的 Fedora 44 系统上,基于 NVIDIA 官方 RPM 联网源快速搭建 CUDA 算力环境

    1. 添加 NVIDIA 官方软件源

    将 NVIDIA 为 Fedora 44 编译的官方源添加到 DNF 仓库中,并刷新本地缓存。

    # 添加 Fedora 44 专属 CUDA 软件源
    sudo dnf config-manager addrepo --from-repofile https://developer.download.nvidia.com/compute/cuda/repos/fedora44/x86_64/cuda-fedora44.repo
    
    # 清理 DNF 缓存
    sudo dnf clean all

    2. 安装 NVIDIA 驱动与 CUDA 工具包

    # 安装指定版本 Toolkit
    sudo dnf -y install cuda-toolkit-13-3
    
    # 安装专有 NVIDIA驱动
    sudo dnf -y install cuda-drivers

    配置环境变量(配置 nvcc 命令)

    安装完成后,系统默认不会将 nvcc 编译器路径加入全局变量。执行以下命令,将 CUDA 路径追加到 ~/.bashrc 中:

    cat >> ~/.bashrc << 'EOF'
    
    # NVIDIA CUDA TOOLKIT
    export PATH=/usr/local/cuda/bin:$PATH
    export LD_LIBRARY_PATH=/usr/local/cuda/lib64:$LD_LIBRARY_PATH
    EOF

    让配置立即生效

    source ~/.bashrc

    验证安装结果

    重启系统后验证 GPU 驱动状态

    # reboot 重启系统
    nvcc -V
    nvidia-smi
  • 在 Fedora 44 上部署 OpenAI Whisper

    OpenAI Whisper 是一个由 OpenAI 开源的、极其强大的语音识别(ASR)大模型,其核心功能是将人类的语音高效、精准地转化为文字。由于其完全开源,你可以将其轻松部署在本地,享受 100% 的隐私安全与零成本的转写体验。

    在 Fedora 44 系统中,配合目前业界最快的 Python 包管理工具 uv,我们可以用极短的时间、极干净的代码链,快速搭建起一套现代化的 OpenAI Whisper 语音识别环境。

    1. 安装 uv

    uv 是目前最快的 Python 包管理工具,我们可以直接通过 dnf 进行全局安装:

    sudo dnf install uv

    安装完成后验证:

    uv --version

    2. 创建并进入项目目录

    打开终端(Terminal),创建一个独立的文件夹用于存放 Whisper 项目

    mkdir openai-whisper
    cd openai-whisper

    3. 创建并激活虚拟环境

    为了保证 Python 环境的隔离与干净,我们使用 uv 来创建并激活虚拟环境

    # 使用 uv 创建虚拟环境(默认目录为 .venv)
    uv venv
    
    # 激活虚拟环境
    source .venv/bin/activate

    4. 安装openai-whisper

    GPU 显卡加速版

    如果你的机器安装了 NVIDIA 显卡与 CUDA,可安装 GPU 版本:

    # 安装 PyTorch CUDA 版本
    pip install torch torchvision --index-url https://download.pytorch.org/whl/cu132
    
    # 安装 OpenAI Whisper
    pip install -U openai-whisper

    CPU 版

    CPU 版本(无独立显卡)

    # 安装 OpenAI Whisper
    pip install -U openai-whisper

    运行

    whisper --help
    
    whisper audio.flac audio.mp3 audio.wav --model turbo