最近将小新 Pad Pro 2021 的 GSI 系统升级到了 Android 16，突然发现蓝牙耳机没有声音了。
一番搜索、排查后发现是因为 A2DP 被禁用了。参考这里的修改思路，我更新了一下之前制作的 Magisk Module，让蓝牙音频恢复了工作。
刷入上面的模块后，在系统设置/开发者选项中，你应该能看到“Disable Bluetooth A2DP hardware offload”选项变得可以交互了，取消这个选项后重启设备，蓝牙音频就可以正常从耳机输出了。
除了修复蓝牙没有声音的问题外，还移除了之前的 Patch，现在基于 PHH 的 GSI 镜像已经没有之前遇到的亮度、磁吸盖相关的问题~
在看了很多期神秘园后，周末我临时起意，出发前往成都附近的一个比较小众的徒步路线——金堂二道坪环线。这条线路全长 8 公里左右，最高海拔 913 米，爬升高度也不超过 400 米；另外，线路入口处有卖零食水果饮料的摊位，沿途一路也有垃圾桶，属于比较成熟的徒步线路了。
徒步线路下载： https://www.2bulu.com/track/track_detail.htm?trackId=JJ1+IEMHxDTp/R2KBg5Tzw==
从我家里骑摩托车到徒步起点大概有 70KM 路程，经过两小时的骑行后，终于到达了徒步起点。下车后，一股塑料烧焦的味道引起了我的注意，检查了一圈后，我发现车子的机油盖没拧紧，机油沿途撒了一地。
取出机油标尺一看，剩下的机油量不到标尺的最小刻度。在这么恶劣的情况下，车子还是把我驼上了山，真是相当不容易啊 😂
为了不耽误爬山时间，我赶紧联系了附近的几个摩托车修理店，幸好有一家叫做风林机车俱乐部的店表示愿意送油上山。但在给店家发送我的定位信息时，我发现我的微信竟然被限制添加好友，申请解除限制的过程中，一直提示人脸核身不通过，真是屋漏偏逢连夜雨。我只好通过短信发送了高德地图的地点链接，并且跟店家解释我这边的情况。在此处问候张小龙的母亲
费用上，机油 130 元外加人工费 40 元。想到当下没有更好的选择，只好接受了这个选项。
在等待店家赶过来的这段时间，我简单的思考了一下经济学原理，试图为这 170 块的机油寻找一个合理的解释。附近其他店家没法送油上山，而我又缺少机油（资源有限）且赶时间徒步（时间有限），所以就只能接受比我平时保养摩托车更贵的价格——我上次保养只花了90块。
就算考虑其他的替代选项：闪购过于耗时且没有匹配型号的机油，而找货拉拉在时间成本、金钱成本上有太多不确定性。比较之下，这 170 块确实也是时间最短且最具有确定性的选择。想到这里，
心里差不多放下了「血亏」170 的负担——今天的主要目标是完成徒步计划，不能因为这些耽误了享受徒步的心情。
很快店家就送来了机油，不过瓶身没有任何壳牌之类的标志，长得一副淘宝外贸尾单货的样子。我确认并接受了被迫接受高价杂牌机油的事实。不过还好没几分钟就处理好了车子的意外状况，我的徒步终于开始了！
我选择的线路是从开照寺出发，经三学禅院、矮子店最后回到起点。三学禅院之前都是水泥路，不过台阶较多，很快就让人气喘吁吁，一看心率 152，背上也汗湿了。我预感这件在骑行过程中能抗风保暖的外套在徒步过程中会阻碍身体散热，影响行进，就赶紧将它脱下塞进背包里。
按照计划，我应该在 12 点出发，16 点完成环线徒步，这样就可以在天黑前到家，由于修车耽误了一些时间，我一路马不停蹄，整条步道上，我不断的超越其他的徒步者。中途也没怎么停下来看风景，只是偶尔停下，吃些零食补充一下水分。
我感觉到这是另一种全神贯注地徒步体验，就像坐在电脑前聚精会神地敲代码一样，我的脑中只有下一步应该如何踏出，潜意识中只剩下现在是否需要停下避免心率过快或者补充一些能量。这大概就是徒步过程中的心流体验，在这种全身心高度协调的情况下，思维沿着道路延伸，人在路上，就会不自觉地向终点运动。
原计划 4 小时的徒步在车子故障后被修改为 3 小时，最后不知不觉地用 2 小时完成了，这可能是今年以来，最轻松顺畅的走路体验了～
准备返程之前，我上淘宝确认了一下机油的具体型号，居然真是要卖 130 块的机油（Bonner 全合成 10W40），看来是我之前用的机油都太低端了 😅 ，以至于完全不认识这个牌子。车子也是幸运地用上了高端货。
在上篇文章优化了博客网站的性能过后，我对页面加载速度仍感到不太满意，Cloudflare 显示大部分页面仍需要等待接近 2 秒才能完成响应。一想到我之前在 cPanel 上执行了一些比较重的操作，网页的加载速度就会下降，所以可能之前的 Host Provider 并没有给我分配多少资源来折腾，这大概率就是网页访问速度慢的重要原因之一。
为了验证这个观点，我尝试在 Homelab 中的 N100 主机上部署了一个 WordPress，并将博客网站复制了一份到这台服务器上。我发现在缺少 Cloudflare 缓存的情况下，就算是通过 Cloudflare Connector 从公网访问家庭内网中的网站都比我线上的博客网站要快 😂。
确认了是 Host Provider 的性能问题后，我决定将博客网站迁移到我的一台 VPS 上，那么这篇文章的重点终于开始了。
我的 Word Press 实例一开始就是通过 Host Provider 建立的，之前在不同的 Provider 之间迁移时，主要也是通过管理面板上提供的一键迁移功能完成操作。但我没想到的是，这些一键迁移功能所涉及的插件都是付费的，之前之所以能顺畅的使用，大概率是 Host Provider 已经为这些功能付过了钱。
虽然插件市场中也有免费的备份恢复插件，但要么是备份出来之后不让恢复，要么是恢复备份会出错， 更离谱的是有些插件备份出来的数据竟然是加密的。
不过好在管理面板提供了一个简单的 Full Backup 功能，可以将 WordPress 目录连同整个数据库 Dump 一起打包。
在我的 VPS 上，出于方便我一直没安装任何面板，唯一的管理工具是 CapRover ，你将其简单的理解为自部署版 heroku。他自带的 WordPress 的部署模板，只要简单替换一下变量，就可以快速启动一个 WordPress 容器：
在这里，需要注意的 WordPress 的 Docker 镜像默认不包含 WP-CLI，需要使用 6.9.0-cli 标签才能部署带 WP-CLI 的镜像。
由于 CapRover 的限制，部署好的 WordPress 只能通过 CapRover 的 Nginx 网关访问，而 Nginx 网关已经处理了 TLS，所以转发到 WordPress 的流量只有 HTTP。
如果你从零使用 Docker 创建 WordPress 实例，上述的情况不会影响你，但如果使用从其他地方复制过来的 WordPress 实例，就会遇到无限重定向的问题。具体表现为访问 /wp-admin 时，会响应当前重定向到当前 URL 。这时，就需要在 wp-config.php 的最顶部，添加下面的代码：
if (strpos($_SERVER['HTTP_X_FORWARDED_PROTO'], 'https') !== false)
$_SERVER['HTTPS']='on';
else
$_SERVER['HTTPS']='off';上面就是迁移博客过程中比较大的坑点了，其实就算花 $9.9 买一个一键迁移插件可能也无法避开。但如果我在原来的 Provider 上加钱升级配置，可能也就不需要这次的迁移了。根据基本的经济学原理，我今天下午工作的价值就是下一档配置的 3 年订阅费，大概 $300，又省到钱了~
昨天收到了 Google Search Console 的提醒，我的博客网站有部分网页响应速度太慢了，影响用户体验。性能差我很早就有体会，不过当时将其归咎于我本地的网络环境没配置好。现在连 Google 都抱怨我的博客网站慢，那就不太可能是我的网络环境问题了。
当我们从地址栏输入网址并按下回车后，哪些地方最容易出现性能问题？电脑网卡、家庭路由器、社区网关、服务器网卡还是应用程序代码？
由于 Google 的报告，我快速排除了服务器网卡之前的选项，范围缩小到了服务器网卡问题跟应用程序代码慢之间。我在网上找到了一个 WordPress 插件 Code Profiler ，可以用来分析处理请求过程中的插件执行耗时。
我随机抽取了一篇很少被访问的博文，加上了禁用缓存的查询参数后，插件性能分析结果如下：
可以看到整个请求完成时间接近 1s，其中的 Jetpack 耗时接近 300ms。喷气背包可能在反向喷气。
根据这篇文章的介绍，我关闭了所有的 Jetpack 模块，但对响应速度没有太多影响。只有在彻底关闭 Jetpack 后，请求响应时间降到了 500ms 以内。这对于只有 1C1G 的共享空间来说，已经可以接受了。除此之外，内存开销、文件读写数量也都降低了15%。
当然，关闭 Jetpack 有一些代价，对我影响最大的是评论区不能支持 Markdown 了，发布新博文不能同步创建一个长毛象嘟嘟了。
总而言之，对我在使用的这台非常弱鸡的服务器来说，Jetpack 有些过于沉重了。
最近在整理家里的一些电子文件的时候，发现 QNAP 提供的 Qsirch 搜索功能无法搜索 /Public 目录下的文件了，不管是文件名还是文件内容，都查询不到搜索结果。
在网络上搜索了一番，Reddit 中有网友提到可以在 Multimedia Console 中重建索引，然后去 Appcenter 中重启 Qsirch 应用。不过我试下来，发现并没有什么卵用。
折腾半天，感觉实在没办法了，只能求助客服，在等待客服回复的过程中，突然想到，我之前通过 NFS 共享过 /Public 目录，当时似乎从 Docker 中访问时，弄乱过目录的访问权限。所以，会不会是因为目录权限错误，导致 Qsirch 无法对文件建立索引？
为了验证我的猜想，SSH 登录 QNAP 后，发现 /Public 目录的权限果然有问题，该目录属于一个未知的 group，手动修改 Owner 为 admin/administrators 后，Qsirch 开始运行建立索引的后台任务了。等待索引建立完成，Qsirch 已经能够检索 /Public 目录的文件了~
我的 N100 小主机最近陷入了无响应的困境，一次系统级的卡顿，让我不得不深入诊断底层硬件问题。最终，故障源头被锁定在一块出现问题的 NVMe 硬盘上。
故障最初表现为：系统在日常运行中，当需要读取某些特定数据时，NVMe 硬盘会陷入无响应状态。这直接导致相关进程卡滞在 D 状态（不可中断睡眠状态）。当这类进程累积过多时，整个操作系统陷入僵局，无法响应任何其他请求。
首次尝试解决，我选择了重启。然而，系统通常能坚持不到十分钟，便会在 CPU 占用率不高的正常负载情况下再次卡死。这表明问题并非偶发，而是存在深层原因。
为了区分软件与硬件故障，我启动了 SystemRescue Live CD。在 Live CD 环境下，我开始使用 smartctl 工具检查硬盘的健康状况。令人惊讶的是，仅仅执行 smartctl -x /path/to/disk 这样的详细健康状况检查命令，就能稳定复现系统卡死的故障。
这一现象直接排除了操作系统层面的复杂问题，将故障的矛头清晰地指向了 NVMe 硬盘本身。
为了进一步验证，我将这块故障硬盘从 N100 小主机上取下，安装到另一台笔记本电脑上进行测试。结果，同样的卡死问题依然能够重现。这最终确认了硬盘是故障的根本原因，而非 N100 主机的 PCIe 接口或其他主机侧问题。
这块 NVMe 硬盘尚未过保，这意味着我可以直接申请售后换新。然而，更换新硬盘的代价是硬盘上的所有数据。这块硬盘主要保存着我部署在 Docker 上的应用数据以及一些从网络下载的影片。
幸运的是，Docker 应用的关键数据每天都通过 restic 进行备份。因此，更换新硬盘对我来说，影响微乎其微，核心应用数据和配置都得以安全保存。至于影片文件，虽然会丢失，但并非不可恢复。
这次故障也促使我思考关键服务的紧急应对措施。我的 N100 宿主机上运行着一个软路由虚拟机，这意味着一旦宿主机故障，全屋的网络将随之瘫痪。
发生故障时，我的临时解决方案是：使用一根网线连接器，将 N100 主机上原本连接 LAN 与 WAN 的网线直连起来，并让家中的光猫直接充当网关。这样可以在最短时间内恢复主要的网络连接，保障家庭网络的正常运行。这为后续的故障排查与修复争取了宝贵的时间。
尽管 Docker 应用数据有定期备份，但这次经历也暴露了一个疏漏：我却忽略了软路由虚拟机磁盘映象（VM Disk Image）的备份。软路由的配置和运行状态都包含在这个映象文件中，一旦丢失，重建起来会相当耗时。
好在这次运气眷顾，通过 Live CD 成功抢救回了这份重要的虚拟机映象文件，避免了额外的麻烦。
上周五，我的外置显示器突然在一次热插拔后无法被笔记本电脑识别 4K 分辨率了，在排查了笔记本电脑、线材问题后，基本可以确定是显示器本身出了问题。
从内核日志来看，系统无法读取显示器 EDID 信息：
[ 174.781913] EDID has corrupt header
[ 174.781923] amdgpu 0000:65:00.0: [drm] *ERROR* EDID checksum invalid.
[ 178.681809] EDID has corrupt header
[ 178.681819] amdgpu 0000:65:00.0: [drm] *ERROR* EDID checksum invalid.
[ 232.892047] EDID has corrupt header
[ 232.892057] amdgpu 0000:65:00.0: [drm] *ERROR* EDID checksum invalid.
[ 235.172080] EDID has corrupt header
[ 235.172091] amdgpu 0000:65:00.0: [drm] *ERROR* EDID checksum invalid.
[ 623.720346] EDID has corrupt header
[ 623.720359] amdgpu 0000:65:00.0: [drm] *ERROR* EDID checksum invalid.
[ 625.949958] EDID has corrupt header
[ 625.949969] amdgpu 0000:65:00.0: [drm] *ERROR* EDID checksum invalid.EDID 是一份显示器能力识别数据，包含生产厂商、支持的分辨率、刷新率等信息。EDID 一般存储在显示器的芯片内，如果显示器有多个输入端口，那么每个端口上的 EDID 通常会被分别存储在独立的芯片内。当电脑连接显示器时，会通过 DDC 读取显示器上存储的 EDID 信息，从而能够让电脑正确识别显示器的型号并输出显示器支持的视频信号。
当 EDID 存储器损坏导致电脑无法读取时，我们可以主动向操作系统提供某个视频输出端口的 EDID 信息。这样以来，解决问题的思路就导向了寻找一份可用的 EDID 文件。
幸好我的显示器有多个输入端口——一个 HDMI 2.0 以及 两个 HDMI 1.4 ，可以尝试读取 HDMI 1.4 端口的 EDID 文件，然后用 EDID 编辑器为其添加 4K@60Hz 的输出设置，作为 HDMI 2.0 接口的 EDID 文件。
在 ArchLinux 上，可以使用 eedid-tool (AUR) 读取并保存 EDID 信息。
# 扫描已连接的显示器 i2c bus
$ eedid-tool -s
Bus 11 has EDID, mfg BOE
1 EDID(s) found.
$ eedid-tool -r -b 11 > ./edid_hdmi1.4.bin由于 HDMI 1.4 不支持 4K 60Hz 的输入规格，所以需要手动尝试为其添加。
为了魔改刚刚导出的 EDID 文件，我使用了 AW EDID Editor，这款软件可以完美地通过 Bottles (Wine）运行，打开 AW EDID Editor 后，选择要修改 EDID 文件，稍等片刻后，你将看到这样的界面。
点击 CEA Extension 下面的 Add new CEA Block，选择 Detailed Timing Descriptor。
这时你会看到一个输入框全是 0 的配置界面。
接着点击 Use predefined format，选择希望添加的分辨率规格即可，对于我的显示器来说，需要选择 3840×2160 60Hz。
当配置界面被填充满各种数据后，就可以点击左上角的 File 菜单，保存修改后的 EDID 文件。
首先需要将修改后的 EDID 文件保存到 /usr/lib/firmware/edid/ 目录下，Linux 固件相关的二进制文件通常都放在这里。
接着，我采用了下面的 systemd 文件来自动加载 EDID：
[Unit]
Description=Override HDMI EDID for Koios Monitor
After=sys-kernel-debug.mount
Requires=sys-kernel-debug.mount
[Service]
Type=oneshot
# 关键：告诉 systemd 即使脚本跑完了，服务也被视为"active"，这样才能执行 stop
RemainAfterExit=yes
# --- 启动时执行 (应用 EDID) ---
# 1. 写入自定义 EDID
ExecStart=/bin/sh -c 'cat /usr/lib/firmware/edid/koios_hdmi2.0.bin > /sys/kernel/debug/dri/1/HDMI-A-1/edid_override'
# 2. 触发热插拔，让内核应用更改
ExecStart=/bin/sh -c 'echo 1 > /sys/kernel/debug/dri/1/HDMI-A-1/trigger_hotplug'
# --- 停止时执行 (撤销修改) ---
# 1. 清空 override 文件
ExecStop=/bin/sh -c 'echo -n reset > /sys/kernel/debug/dri/1/HDMI-A-1/edid_override'
# 2. 再次触发热插拔，让内核读取显示器原本的真实 EDID
ExecStop=/bin/sh -c 'echo 1 > /sys/kernel/debug/dri/1/HDMI-A-1/trigger_hotplug'
[Install]
WantedBy=multi-user.target由于我经常只会用到这一台显示器，所以还设置了自动启动服务，当需要连接其他显示器时，就可以通过停止这个服务，让操作系统直接读取该显示器提供的 EDID 。
在解决这个问题的过程中，参考了 Gemini 3 Pro 生成的回复，不过其中有不少事实性错误，仍应参考 Arch Wiki 的文档：
https://wiki.archlinux.org/title/Kernel_mode_setting#Forcing_modes_and_EDID
另外，为了防止笔记本内置显示器的 EDID 在未来也发生了无法读取的情况，以及方便其他拥有跟我同型号显示器的人需要 EDID 文件，我将这些 EDID 上传到了 IPFS 网络：
QmRYhQDg645VqcRknCWK6ucVsmn3iWBp5j4RAE16oufAHLQmRKseLcqduk41bxvPSfBPDCYaZoyP4uRQUKB6nV4Kpq5cWorking with multiple GitHub accounts on the same machine can be tricky, but we can automate account switching when changing workspaces. Here’s my solution using Fish Shell and Direnv.
Install direnv, this handy tool automatically loads environment variables when you cd into directories.
Add this function to your Fish Shell configuration:
function __gh_auth_switch_gh_account --on-variable GH_ACCOUNT
if test -n "$GH_ACCOUNT"
gh auth switch --user "$GH_ACCOUNT"
end
endLet’s break down the snippet:
--on-variable tells Fish Shell to run this function when the variable GH_ACCOUNT changes value.test -n $GH_ACCOUNT returns true if the length of GH_ACCOUNT is non-zero.gh auth switch --user "$GH_ACCOUNT" switches the active account to $GH_ACCOUNT.For example, if we need to switch to gh-user-1 under path/to/company/ . We can add a .envrc file under path/to/company：
export GH_ACCOUNT=gh-user-1When we cd into path/to/company/project1, direnv will set the GH_ACCOUNT variable automatically, and the callback function __gh_auth_switch_gh_account will be invoked by the Fish Shell to make gh-user-1 active.
之前一篇文章的评论区有人提到过机械革命15XPro 暴风雪在唤醒后键盘会短暂失效的问题，往往需要重新睡眠再唤醒才能激活键盘。经过我的排查后发现，在该问题出现时，有两个比较重要的 Log 线索：
Aug 27 09:04:52 arch kernel: atkbd serio0: Failed to deactivate keyboard on isa0060/serio0
Aug 27 09:04:52 zarch kernel: atkbd serio0: Failed to enable keyboard on isa0060/serio0根据 Claude 以及互联网上相关的讨论，这个问题大概率跟内置键盘的驱动有关，通常可以通过尝试不同的 i8042/atkbd 相关参数来解决。
跟 Claude 讨论一番过后，我决定添加如下 kernel parameters：
i8042.reset=1 i8042.nomux=1 i8042.nopnp i8042.noloop atkbd.reset=1实际体验下来，键盘失效的问题已经一周多都没有复现了。