启鑫的黑板报

分类：未分类

Fedora 开启 Wake-on-LAN（WOL）远程唤醒配置教程
Wake-on-LAN（WOL，网络唤醒）是一种通过网络远程启动计算机的技术。设备即使处于关机或休眠状态，也可以通过接收特定的 Magic Packet（魔术包）被远程唤醒。

该功能常用于：
- 家庭服务器
- NAS
- 远程办公主机
- 低功耗 Linux 设备
1. 查看网卡名称
```
ip link
```
示例输出：
```
2: enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP>
```
这里的enp3s0为当前网卡名称。
```
enp3s0
```
2. 检查网卡是否支持 Wake-on-LAN

查看网卡 WOL 状态：
```
sudo ethtool <网卡名称> | grep Wake-on
```
例如：
```
sudo ethtool enp3s0 | grep Wake-on
```
输出示例：
```
Supports Wake-on: pumbg
Wake-on: d
```
Wake-on 参数说明

参数含义
d 禁用 Wake-on-LAN
p PHY 活动唤醒
u 单播数据包唤醒
m 多播数据包唤醒
b 广播数据包唤醒
a ARP 数据包唤醒
g Magic Packet 唤醒
s 安全 Magic Packet
f 特定过滤器唤醒

其中最常用的是g表示支持 Magic Packet 唤醒。

3. 查看 NetworkManager 网络连接名称

Fedora 默认使用 NetworkManager 管理网络。

查看当前连接：
```
sudo nmcli connection show
```
示例：
```
NAME                UUID                                  TYPE      DEVICE
Wired connection 1  xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx  ethernet  enp3s0
```
记住连接名称：
```
Wired connection 1
```
4. 开启 Wake-on-LAN

使用 nmcli 配置永久 WOL：
```
sudo nmcli connection modify "Wired connection 1" 802-3-ethernet.wake-on-lan magic
```
该配置在系统重启后依然有效。

5. 重新应用网络配置

立即生效：
```
sudo nmcli device reapply <网卡名称>
```
例如：
```
sudo nmcli device reapply enp3s0
```
6. 验证是否开启成功

再次检查：
```
sudo ethtool <网卡名称> | grep Wake-on
```
如果输出Wake-on: g说明 Wake-on-LAN 已成功开启。
2026年5月14日
技嘉 Z690 网卡消失找不到硬件，BIOS识别不到网卡的修复方法
我上一次被 PC 硬件折磨到动用“重装系统”这种方案，已经是很多年前了。

没想到在 2026 年，我居然会因为一个“凭空消失的网卡”，再次体验到这种古老的绝望。而最离谱的是，最后解决问题的核心工具，不是驱动，甚至不是 AI，而是一块 CR2032 电池和一把螺丝刀。

1. 事情开始于一次普通断网

电脑原本运行得稳如老狗，突然之间，网络毫无征兆地断了。

第一反应当然很普通：路由器抽风？网线松了？还是驱动崩了？毕竟这种问题平时太常见了。我按照标准流程准备顺手修好它，但很快，我发现事情完全超出了预期。

2. 板载网卡不见了

打开设备管理器，我原本以为会看到黄色感叹号或未知设备。

结果，“网络适配器”分类下空空如也。
不是报错，不是驱动异常，而是整个网卡硬件直接消失了。

那一瞬间我心里已经有点发凉：如果设备在系统底层都不存在，那这事儿重装驱动也不太能搞定。

3. 排查问题

接下来我几乎把所有能想到的常规方案全试了一遍：
- 软件层： 重启、更新驱动、Windows 网络重置。无效。
- 硬件扫描： 疯狂点击“扫描硬件改动”。无效。
- 驱动强刷： 重新安装网卡驱动
我甚至还问了几个 AI，得到的答案基本都差不多
但问题是我这里连“硬件”都没了。

我做出了那个“最后底线”的决定：重装系统。

备份数据、制作镜像、格式化、重装 Windows。折腾了近一个小时后，我满怀期待地进入桌面点开设备管理器——网卡依然不存在。

我以为硬件可能彻底烧了，但我没死心决定在试试看

4. 真正让我破防的是 BIOS

我重启进入 BIOS

BIOS里也找不到网卡

我尝试了重置BIOS默认设置，还是不行

5. 物理办法

既然软件层已经彻底无解，我开始了最原始的物理操作：
1. 彻底断电： 关机，拔掉电源线
2. 物理复位： 拆机，扣下主板上的 CR2032 纽扣电池。
3. 强制放电： 用螺丝刀短接 CLR_CMOS 跳线针脚约 10-15 秒。
4. 复活仪式： 等待片刻，装回电池，插电，开机。
6. 结局：奇迹发生了

重新开机进入 BIOS，熟悉的 LAN 信息重新出现了。进入系统后，网卡秒回，网络秒通。

一切像什么都没发生过一样。但我很清楚，这不是“修好了”，而是通过物理手段，把一个卡死的硬件状态强行从底层重置了。

这次经历让我意识到，现在的 PC 故障越来越像一种“赛博玄学”。我花了大量时间去折腾逻辑、重装系统，最后真正解决问题的，却是一把螺丝刀和一次彻底的放电。
2026年5月12日
Docker 磁盘爆满实录：我以为镜像删干净了，结果系统还是报 No Space
执行了 docker rmi，为什么磁盘空间还是 100% 占用？记录了一次服务器磁盘爆满的排查过程，深度解析 Docker 分层存储与构建缓存，并分享真正有效的深度清理命令。

在日常开发和运维中，我习惯于用一个简单的命令来清理 Docker 镜像：
```
docker rmi <IMAGE_ID>
```
删除不再使用的镜像，释放磁盘空间，逻辑看似完美。直到有一天，我的服务器直接弹出令人绝望的红字：

No space left on device

我删光了所有能删的镜像，为什么磁盘还是满的？

1. 现象：镜像删了，空间没回？

当我意识到磁盘报警时，第一反应是检查 Docker 的占用情况：
```
docker images  # 查看镜像列表
df -h          # 查看系统磁盘状况
```
诡异的现象出现了：
- docker images 列表里只剩下几个业务镜像，加起来不到 2GB。
- 但 /var/lib/docker 目录依然占用了 40GB+。
这时候我才意识到：看到的“镜像”，并不代表 Docker 占用的全部空间。

2. 分析原因：为什么 docker rmi 会失效？

理解这个问题，必须看清 Docker 的底层存储机制。Docker 镜像并非一个独立的文件，而是像乐高积木一样层层堆叠的（Layer-based Filesystem）。

2.1 镜像层（Layers）的“幽灵”

当你用 docker rmi 删除一个镜像时，Docker 只会尝试删除该镜像特有的层。如果某些层被其他镜像引用，或者是构建过程中的中间层，它们就会留在磁盘上，变成无法通过 rmi 直接删除的“幽灵空间”。

2.2 虚悬镜像（Dangling Images）

在多次执行 docker build 后，旧的镜像会失去标签（Tag），变成 <none>:<none>。这些镜像往往不会出现在你常规的清理视线里，但依然实打实地占据空间。

2.3 构建缓存（Build Cache）

这是最隐形的“空间杀手”。特别是开启了 BuildKit 后，Docker 会产生大量的构建缓存。这些缓存完全不会显示在 docker images 列表中，却是磁盘爆满的元凶之一。

3. 真正救命的命令：docker image prune

当我发现手动删除（rmi）无能为力后，我使用了 Docker 官方提供的“深度清理”命令：
```
docker image prune -a
```
这条命令到底做了什么？
1. 所有未被容器使用的镜像（即使它有 Tag）。
2. 所有虚悬镜像（Dangling Images）。
3. 所有孤立的镜像层。
⚠️ 安全提示： 只要你的业务容器正在运行，它所依赖的镜像就是安全的，不会被 prune 误删。但对于已经停止（Exited）的容器，其对应的镜像可能会被判定为“未使用”而被清理。

执行后，我的服务器磁盘占用瞬间从 100% 降到了 15%。

4. 进阶技巧：如何精准定位与排查？

在盲目清理之前，我建议先用以下命令定位 Docker 的真实磁盘占用：
```
docker system df
```
输出会清晰地展示四类数据的占用分布：
- Images: 镜像
- Containers: 容器（包括日志和可写层）
- Local Volumes: 本地卷
- Build Cache: 构建缓存
如果 image prune 仍不足以释放空间，可以使用终极命令：
```
# 清理一切：停止的容器、未使用的网络、未使用的镜像和卷
docker system prune -a --volumes
```
2026年3月4日
通过组策略彻底关闭 Windows 11 小组件 (Widgets)
Windows 11 任务栏左侧的“小组件”（Widgets）功能虽然可以提供天气和资讯，但经常会在后台运行并占用一定的系统资源。如果你不需要这些推送内容，希望系统更加轻量、干净，可以通过 Windows 自带的组策略功能将其完全关闭。

操作步骤

1. 打开组策略编辑器

按键盘上的 Win + R 快捷键打开运行窗口，输入以下命令然后按回车：
```
gpedit.msc
```
这会打开“本地组策略编辑器” (Local Group Policy Editor) 窗口。

2. 定位到小组件策略

在左侧的导航树状列表中，依次展开以下路径：
```
Computer Configuration (计算机配置)
↳ Administrative Templates (管理模板)
　↳ Windows Components (Windows 组件)
　　↳ Widgets (小组件)
```
3. 打开策略设置

在右侧的策略列表中，找到名为 Allow widgets (允许小组件) 的选项，并双击打开它。

4. 禁用小组件

在弹出的配置窗口中，将左上角的选项从“未配置”或“已启用”更改为：
```
Disabled (已禁用)
```
5. 应用并保存

点击窗口右下角的 Apply (应用)，然后点击 OK (确定) 关闭该窗口。

6. 强制更新策略

为了让设置尽快生效，可以强制刷新一下系统策略：

按 Win + R 打开运行，输入 cmd 后按 Ctrl + Shift + Enter（以管理员身份运行命令提示符）。
输入以下命令并回车：
```
gpupdate /force
```
等待屏幕提示“计算机策略更新成功”。
2026年2月24日
Fedora Workstation 43 初始化设置卡住，Next 按钮无响应的通用修复方案
问题描述

在完成 Fedora Workstation 43 的安装后，系统会进入首次开机初始化设置（Initial Setup）流程。在 Privacy（隐私设置） 页面点击 Next（下一步） 时发现按钮毫无反应，系统处于假死状态，导致无法正常进入桌面。

这通常是由于内核在初始化阶段与特定的显示硬件（尤其是部分 NVIDIA 显卡或集成显卡）存在兼容性问题，导致图形界面渲染挂起。

解决方案：使用 VESA 模式强制初始化

通过在引导时临时禁用显卡硬件加速，使用 VESA 模式（纯软件渲染）可以顺利绕过此卡顿。

1. 重启并进入编辑模式

强制重启你的电脑。在看到 GRUB 引导菜单（选择 Fedora 内核版本的倒计时界面）时，立即按下键盘上的 e 键进入编辑模式。

2. 修改内核启动参数

在出现的代码页中，找到以 linux 开头的行（通常位于倒数第 3 或第 4 行）。
1. 将光标移动到该行的末尾。
2. 先输入一个空格。
3. 手动输入以下参数：
  inst.xdriver=vesa nomodeset
3. 启动并完成设置

按下 Ctrl + X 启动系统。此时系统会以低分辨率模式启动，初始化页面的 Next 按钮现在可以正常点击了。

进入桌面后的后续处理

成功进入桌面后，由于我们使用了 nomodeset，系统分辨率会很低且操作有延迟。请务必执行以下步骤恢复正常：
1. 更新系统： 打开终端，运行 sudo dnf update。
2. 安装驱动： 检查并安装适合你显卡的驱动程序（如 NVIDIA 专有驱动）。
3. 正常重启： 驱动安装完成后，直接重启电脑，无需再手动输入任何参数，系统将恢复满血性能。
2026年2月5日
常用网速测试网站推荐
平时折腾网络环境，测速是必不可少的环节。分享我最常用的在线测速工具。

1. Google Fiber Speedtest
- 特点： Google 一贯的极简主义，只保留最核心的“下载、上传、Ping”三个数值。
- 适用： 快速看一眼下载/上传速度，没有各种花哨图表
- 地址： https://fiber.google.com/speedtest/
2. Speedtest by Ookla
- 特点： 全球公认的标杆工具，服务器节点全球最全。
- 适用： 能够自动匹配离你最近的运营商服务器，测出物理链路的理论最大值。
- 地址： https://www.speedtest.net
3. Cloudflare Speed Test
- 特点： Cloudflare 作为全球最大的 CDN 厂商之一，其测速不仅仅关注带宽。
- 优势： 除了速度，还测试抖动（Jitter）和丢包率（Packet Loss），这对于在线会议和电竞至关重要。
- 地址： https://speed.cloudflare.com
4. Fast.com (by Netflix)
- 特点：打开网页即测，无需点击任何按钮。
- 优势： 走的是 Netflix 的服务器，能真实反映你看流媒体时的网络性能。
- 地址： https://fast.com
2026年1月21日

参数	含义
d	禁用 Wake-on-LAN
p	PHY 活动唤醒
u	单播数据包唤醒
m	多播数据包唤醒
b	广播数据包唤醒
a	ARP 数据包唤醒
g	Magic Packet 唤醒
s	安全 Magic Packet
f	特定过滤器唤醒

分类： 未分类

Fedora 开启 Wake-on-LAN（WOL）远程唤醒配置教程

1. 查看网卡名称

2. 检查网卡是否支持 Wake-on-LAN

Wake-on 参数说明

3. 查看 NetworkManager 网络连接名称

4. 开启 Wake-on-LAN

5. 重新应用网络配置

6. 验证是否开启成功

技嘉 Z690 网卡消失找不到硬件，BIOS识别不到网卡的修复方法

1. 事情开始于一次普通断网

2. 板载网卡不见了

3. 排查问题

4. 真正让我破防的是 BIOS

5. 物理办法

6. 结局：奇迹发生了

Docker 磁盘爆满实录：我以为镜像删干净了，结果系统还是报 No Space

1. 现象：镜像删了，空间没回？

2. 分析原因：为什么 docker rmi 会失效？

2.1 镜像层（Layers）的“幽灵”

2.2 虚悬镜像（Dangling Images）

2.3 构建缓存（Build Cache）

3. 真正救命的命令：docker image prune

这条命令到底做了什么？

4. 进阶技巧：如何精准定位与排查？

通过组策略彻底关闭 Windows 11 小组件 (Widgets)

操作步骤

1. 打开组策略编辑器

2. 定位到小组件策略

3. 打开策略设置

4. 禁用小组件

5. 应用并保存

6. 强制更新策略

Fedora Workstation 43 初始化设置卡住，Next 按钮无响应的通用修复方案

问题描述

解决方案：使用 VESA 模式强制初始化

1. 重启并进入编辑模式

2. 修改内核启动参数

3. 启动并完成设置

进入桌面后的后续处理

常用网速测试网站推荐

1. Google Fiber Speedtest

2. Speedtest by Ookla

3. Cloudflare Speed Test

4. Fast.com (by Netflix)

分类：未分类

2. 分析原因：为什么 `docker rmi` 会失效？

3. 真正救命的命令：`docker image prune`