Lawtee | 法律小茶馆修改

2025-09-04 16:30:00

纪念中国人民抗日战争暨世界反法西斯战争胜利80周年阅兵仪式在昨日隆重举行。老话说，国之大事，在祀与戎，而和平年代的阅兵式，正是这两件事的完美结合。作为当今世界最受关注的事件，老T在网上冲浪过程中，也看到不少外国人的评价，其中很多都比较有意思，这里也简单跟大家分享一下。

俄罗斯人如何看待93阅兵

老T在日常混迹的多个技术论坛上都看到有人发贴讨论中国的阅兵式，其中最典型的评论就是：“看吧，中国果然没有向俄罗斯提供武器，不然战争局面早就改写了。” 由于在多个平台都看到这种评论，老T也感觉摸不着头脑。只能说，相比西方媒体这些年大肆宣扬的“中国威胁论”，西方民间对俄罗斯的恐惧感，确实是入心入肺了。

由于我们这一代人都在亲身经历中国工业现代化进程，对国内的制造能力早已有充分认识。哪怕按照最朴素的唯物主义思维也知道，一个常住人口和GDP都比不过广东的国家，制造能力显然跟中国有巨大差距。

但西方老百姓长期受媒体偏见影响，对中国的这种能力认识还是存在较大偏差。而此次阅兵展示，一定程度上也算是在帮他们纠偏。

不过，在这过程中，我也很好奇，就是作为这种评论里的另一方，俄罗斯人会如何看待中国阅兵呢？

老T特意找了些懂俄语的朋友帮忙，也翻了翻俄罗斯两大社交平台 VK.com 和 Pikabu.ru，了解下到底俄罗斯普通网友有何观后感。

1. “大受震撼”的技术派

主要评论包括： “规模惊人！技术顶尖！” “正步完美，装备像科幻片” “机器狗和核导弹？中国准备好应对一切了” “水下无人机和机器人才是未来战争，中国AI武器领先了” “新型坦克配高超音速导弹…北约想清楚要和谁打了吗？”

照老T说，这反应在我们这边看来也还算实在。我们天天看着“下饺子” 新装备官宣，可能有点习以为常了。但对俄罗斯人来说，这次阅兵式上展示的装备，特别是高超音速、无人机、AI 这些新装备，确实刷新了他们的认知，甚至带点羡慕嫉妒。毕竟毛子那边也是一堆搞军工的，一眼就能看出门道高低。他们这个“科幻片”的评价，跟我们网上常说的“过于先进，不便展示”也算是有异曲同工之妙。也说明我国这些科技树也确实是点到位了，把老邻居都“震”住了。

2. 地缘政治说

主要评论包括： “中俄朝三位领导人同台——这是给西方的信号！” “中国展示核力量就是领导权宣言，特朗普气疯了” “世界在变，美国中心要没了，这对我们俄罗斯人好” “这是个反西方联盟！” “中国不可威慑，这是给世界的警告” “俄罗斯会不会成了中国的桥头堡？普京在阅兵上像路人…”

这部分就挺有意思了。很多俄罗斯网友，把三国领导人同框解读成“反美统一战线”，觉得中俄抱团取暖对抗西方是好事。他们挺享受这种“世界秩序要变”的感觉，觉得能削弱美国挺好。不过，也有些人担心：中国实力这么强，又这么高调展示，俄罗斯会不会慢慢从“盟友”变“小弟”或者“前哨站”？这种“既想靠大树乘凉，又怕被树荫完全遮盖”的矛盾心态挺明显。

其实，这次我国搞阅兵主要还是聚焦自身发展和对历史的纪念，展示实力也是国家发展的自然结果。至于“对抗联盟”的解读，更多是外界自己加戏了。至于俄罗斯的地位，那得看他们自己怎么走。

3. 吃瓜与调侃的围观

主要评论包括： “有成龙吗？想来场天安门动作戏！” “要是特朗普看到，肯定要搞个带广告的阅兵！” “中国军演像科幻电影，好看但实战咋样？（引用俄军经验）” “看了三小时直播！这女孩分享的彩排片段好感动。”

老实说，全世界网民都一个调性，围观、看热闹、玩梗都是常态。调侃特朗普（真是全球顶流）、cue成龙、甚至拿俄军在乌克兰战场的拉跨经验来质疑阅兵式军队的“实战性”，都是普通网友的自然反应。其中，也有被宏大场面感染，或者被某个小细节打动的。就像老T，始终对战士们在阅兵时从车后跳进车内时的行云流动作佩服至极，也算得上是“人类围观行为学”的普遍现象了。说明阅兵式除了硬核展示，也确实达到了吸引眼球、引发情感共鸣的效果。

美国人如何看待93阅兵

说完俄罗斯，那势必得提提阿美利坚。毕竟，老T在观看直播时，一个很明显的感受就是，这次集中展示这么多新装备，一个重点的目的应该就是让阿美利坚好好冷静一下吧。特别是东风5C拆成3段展示，感觉就是担心川普那草台班子看不懂。

老T 试着汇总了一下美国贴吧、美国知乎和常逛的几个技术论坛上一些评论。总体感觉就是，来自美帝这边的评价，看起来就是“离散值”高得离谱，有的评论从技术角度客观冷静得惊人，有的插科打诨，有的歇斯底里，分化的特别厉害，不知道这算不算美帝内部撕裂的又一次生动展示。

1. 吃瘪的军迷

“中国阅兵是纪律与协调的教科书级展示，美军根本比不了”（前美国海军教官）
“一个方阵350人！我们练48人都要命，他们怎么做到的？”（美国退伍兵）
“无人机+机器狗+高超音速导弹——这装备像从科幻片里扒出来的！”（美国军迷）

老T重点看了看美国军迷那边的反应，毕竟老牌帝国主义了，天天在外边打仗，军迷规模也算庞大，而且长期以专业性著称。

这次，美国军迷圈最炸锅的，是中国全套反潜黑科技的首次公开亮相。以往被美军视为“终极底牌”的核潜艇，这次成了阅兵式的“头号靶子”：

• “深海刺客”无人潜艇：能悄无声息摸到美军潜艇身边放鱼雷，有人哀嚎：“这玩意比好莱坞《猎杀红色十月》还离谱！”
• “空中猎手”反潜无人机：撒声呐浮标像天女散花，帖子里热议：“P-8反潜机的活儿被无人机干了，成本还只要零头？”
• 智能水雷+火箭鱼雷全家桶：尤其智能水雷被戏称“深海地雷阵”，火箭助飞鱼雷更被解读为“专治美军潜艇高速逃逸”。

老T觉得，这届美国军迷还算有点本事，不过也真破防了——“以后弗吉尼亚（核潜艇）要躲无人机、防无人艇、避智能雷，还得防天上扔鱼雷？！”。但也有一些人依然嘴硬：“没实战都是PPT！”。

犹记得一个月前，老T还兴致勃勃的看了好莱坞大片《碟中谍8：最终清算》。电影里边，阿汤哥从黑人女总统手上要来一个航母舰队指挥权，然后从鱼鹰直升机上一跃而下，想肉身进去弗吉尼亚级核潜艇。不过，这核潜艇上的科技装备倒也刷新老T对这种水下巨物的认知。

毕竟，从现实来说，核潜艇也算是美帝的最后依仗了。此前，美军应该老早意识到，在西太平洋这块中国家门口的地方，美军陆上、水上装备算是优势丧尽，不然也不至于每次派个航母舰队过来时，一遇到 055 大驱就夹着尾巴逃。

但美帝可能也一直幻想，虽然水面会挨揍，但他最先进的核潜艇一直安全得很。没想到被这次93阅兵三位一体的潜艇杀手装备集中亮相，打了个措手不及，也难怪五角大楼得连夜加披萨。

2. 中国威胁论

“DF-5C射程覆盖全球，这是对美国的死亡警告！”
“反美联盟形成，第三次世界大战倒计时”（阴谋论者）
“关岛基地？DF-26D早瞄准了！深海堡垒？中国反潜网已铺开！”

这帮人差不多是西方媒体一贯论调，一会中国崩溃，一会中国威胁，左右脑互博，很少有清醒的时候。当看到这次中国展示先进装备时，仿佛听到自己精神防线崩裂的声音。最逗的是有人狂at特朗普：“他肯定在连夜策划更浮夸的阅兵！”（结果特朗普真发了条咆哮体推文骂“中国阴谋”😂）。不过也有清醒的人反驳：“中国40年没打仗，美国同期扔了50万枚炸弹，到底谁才是和平破坏者？”

3. 娱乐至死

“中美阅兵对比：中国像星际舰队，美国像刚蹦完迪的醉汉” “如果中美同时点披萨，中国导弹会比披萨先到你家”
“特朗普想要的生日阅兵，中国给他搞了个顶配版” “以前美国潜艇是深海狼人，现在中国无人机是预言家，无人艇是猎人，智能水雷是女巫——狼人第一晚就出局！”
“五角大楼该给中国打钱——他们帮美军省了军费！”

美帝网民自黑起来也算是狠！自家阅兵被吐槽成“迪士尼花车游行”，还有人毒舌：“英国博物馆该把抢的中国文物还了，不然东风快递包邮上门”。这种解构式幽默背后，其实也藏着对中美实力迭代的微妙认知。就像一句高赞评论：以前中国没钢铁只有钢铁意志，现在中国有钢铁了，该轮到你们练意志了！

的确，美国人看中国阅兵，更像在围观一场陌生人秀，一边惊叹，一边警惕，又忍不住用美式幽默消解焦虑。

当俄罗斯人还在纠结“中俄关系里谁当老大”时，美国人更纠结的是“中国崛起算不算美国衰落”。

但无论哪种声音，都印证了这次阅兵的核心意义：祀以告慰英灵，戎以止战维和。至于美帝核潜艇还能不能睡好觉？不妨学学央视主持人在东风5C亮相时的宣传词：射程覆盖全球，但具体参数嘛……“过于先进，不便展示”😉。

全球围观潮：其他国家网民看法

在看美国网民评论过程中也有个头疼的事，毕竟美帝的平台，很多都是全球各国网友都在用，有时候也很难分清那些发言到底是哪个国家的人。不过也还是很多主动表明身份，以及使用其他语种的发言，大体也能分辨出一些来源，这里也简单汇总下一些典型评价。

总体来看，如果说美俄网民的评论还带着“对手滤镜”和“盟友包袱”，那么其他国家网友的反应则更纯粹。有人当科幻大片看，有人当历史课补，还有人默默掏出小本子记笔记。老T翻了上千条评论，发现这四类评论最有代表性：

1. 发展中国家的集体共鸣

“中国证明了一点：曾被殖民的国家也能逆袭成强国！”（越南@vietnamesebeauties）
“西方媒体总说中国威胁，可中国帮我们修铁路时，欧美只送来账单”（肯尼亚@meja2546）
“看完阅兵我立刻学中文——未来是中国的游戏”（印尼@mohamedaminali6594）
“美国在伊拉克扔炸弹，中国在伊拉克建电站——谁才是真朋友？”（伊朗@haamedkasmaei3999）
“巴西被美国监听十年，中国却给我们发射卫星！”（巴西@leoncioco3305）

正如天安门城楼上“世界人民大团结万岁”，广大第三世界朋友，总体上对这次阅兵都是赞誉和表扬。

不过老T在翻看这些评论时，也感受到很多无奈的情绪，很多人都明显透露着“苦美久矣”的憋屈。

这次93阅兵，对广大第三世界而言，更像是一段爽文剧情：曾经被欺压的穷兄弟，如今带着东风61来撑腰了。

尤其当菲律宾网友 @Axel-t1q9 自嘲“我们挨过日本打却还舔美日”时，一种“恨铁不成钢”感觉，让人五味杂陈。

2. 被日本侵略过的国家集体控诉

“日本至今不认南京大屠杀，却有人批评中国阅兵‘秀肌肉’？”（韩国@문재인-i6p）
“祖父被日军强迫修‘死亡铁路’，中国阅兵也是替我们发声”（泰国@dimsimbogan.）
“欧美只纪念诺曼底登陆，谁记得亚洲死了2000万人？”（越南网友高赞评论）
“奶奶被日军刺刀捅伤时，美军还没参战。中国抗战凭什么被抹杀？”（马来西亚华侨@dangoh2237）

这次阅兵，主题是中国人民纪念抗战胜利。而抗日战争也是能让亚洲众多国家引发共鸣的核心问题。

当西方媒体炒作“中国威胁论时”，韩国网友直接甩图：“看看汉城‘慰安妇’雕像！中国在纪念所有亚洲受害者！”

过程中，老T感觉最扎心的是柬埔寨网友@nuomitang30的质问：“如果中国炫耀武力算威胁，日本隐藏罪行算什么？”

3. 欧洲职业看客

“350人方阵误差小于0.1秒——德国人DNA动了！”（德国@jonaswiegandt3829）
“英国博物馆该归还中国文物了，不然下次阅兵方阵开到伦敦？”（英国@nistelooyv7847）
“阅兵整齐得像AI生成……哦等等这是真的？！”（法国网友暗讽）
“中国花车秀再炫，也改变不了我是自由公民”（阴阳怪气的瑞典网友）

欧洲也是老阴阳人扎堆了，把“双标”玩得明明白白：夸中国纪律性时秒变理工男，提价值观立刻切换圣母模式。

不过也有画风突变的时刻，特别是来自东欧塞尔维亚、保加利亚、匈牙利那边的评论。

有的还特地用翻译软件，将想表达的赞美翻译成中文发出来。本文前边截图中就有一个塞尔维亚的高赞评论。不过，显然人家也不懂简体中文和繁体中文是啥意思，翻译时用的繁体字。

4. 印巴总能出彩

“中巴友谊比喜马拉雅山高！比印度洋深！”（@pakistanime9793 ）
“印度买法国阵风？中国J-10C在巴基斯坦打靶全胜！”（@Maxwell-t3o 这条下边评论都是J-10在阅兵式上只是喷彩条的表演机）
“承认吧！我们阅兵摩托叠罗汉，中国阅兵在组团踢正步”（@DE_EZY ）
“怕中国是真，但上海地铁比新德里干净也是真”（@Aarohanbaru_goku ）

莫迪这次到天津开会，也算是向中国示好了。但很可惜，没有参加阅兵活动。不过中印这关系，讲实在的，一时半会也很难彻底改善。

但印度网友在网上的评论倒是一如既往灌浆糊，有的一边怼“中国武器没实战”转头又问“怎样才能练成这样”。而巴基斯坦地网友，基本都是在评论中狂刷❤️🇨🇳。

值得玩味的是，当评论中涉及到美国时，印巴网友倒是能罕见达成共识：“美国挑拨中印关系，坐收渔利最可恨！”

总结

这次93阅兵，老T总体上感觉是具有极其重大历史意义的标志性事件。在看了各国网友的评价后，也深深感受到国家进步、民族昌盛带来的自豪感。

从1945到2025，中国这80年来真是太不容易了。

城楼上抗战老兵代表与各国领导人们逐一握手那一刻，也让老T不禁泪目。

沧海桑田，如今的中国已经不是1840年之后长达百年里任人宰割的中国。

正如柬埔寨网友 @FFuunnyymudP 写下的那句“中国最震撼的武器，是让阅兵场成为战场终点站。”

80年前我们用血肉筑起长城，80年后我们以强大科技和军事实力拱卫和平。

那响彻云霄的正步声，既是告慰英灵的安魂曲，亦是写给霸权者的止战书。

2025-09-02 18:30:00

周日下午，老T准备在 PVE 装个 RouterOS 测试，结果发现无法创建虚拟机。具体表现是，在虚拟机创建页面，节点处提示 “Node epson seems to be offline” ，然后 PVE 面板上，节点显示灰色问号，提示状态为 “Unknown”。由此，开始了老T一段跌宕起伏的 Bug 修复过程。

PVE 存储设备配置冲突

遇到 Bug 后，老T第一时间怀疑是不是节点配置冲突。因为节点内的虚拟机本身在正常运行，除了节点上有灰色问号，在节点中还有两个存储设备也同样显示黑色问号。

这两个存储设备实际就是主机中的两个机械硬盘。此前，老T将这两个机械硬盘挂载后，直通给了 100 号虚拟机使用。

但考虑到虚拟机中无法读取硬盘温度，便分离了存储，改用 PCI-E 硬件直通，将 SATA 控制器直通到虚拟机。故此遗留两个过期的存储设备。

于是老T在 PVE 面板中直接删除了两个存储设备，然后刷新，看到问题依旧。

老T在想，是否是因为集群状态还没更新，于是重启并强制刷新集群状态，同时检查存储挂载情况。

1
2
3

systemctl restart pve-cluster
systemctl restart corosync
pvesm status

果然，存储状态有点问题。PVE 配置中保留了两个 HDD 的 LVM 存储定义，但实际物理磁盘已经直通给 100 号虚拟机不可见。

1
2
3
4
5
6
7
8

root@epson:# pvesm status
Command failed with status code 5.
command '/sbin/vgscan --ignorelockingfailure --mknodes' failed: exit code 5
Name Type Status Total Used Available %
HDD1 lvm inactive 0 0 0 0.00%
HDD2 lvm inactive 0 0 0 0.00%
local dir active 98497780 13880408 79567824 14.09%
local-lvm lvmthin active 832888832 126265946 706622885 15.16%

于是老T 将无效存储配置进行清理，重新修复 PVE 集群状态。

1
2
3
4
5
6

pvesm remove HDD1
pvesm remove HDD2
systemctl restart pve-storage.target
pmxcfs -l # 重建集群配置文件
pvecm updatecerts --force
systemctl restart pve-cluster

顺便再 reboot，想着问题应该解决了。

但重启后发现节点依然显示灰色问号。

集群配置文件错误

如果说，上边检查 PVE 存储配置时发现错误尚且简单，接下来检查 PVE 集群配置时，就开始逐渐入坑了。

1
2

root@epson:~# pvecm status
Error: Corosync config '/etc/pve/corosync.conf' does not exist - is this node part of a cluster? Linux epson 6.8.12-9-pve #1 SMP PREEMPT_DYNAMIC PMX 6.8.12-9 (2025-03-16T19:18Z) x86_64

查看集群状态发现，corosync 配置文件丢失，一个稀奇古怪的 Bug。也不知道因何而起。

但在重建前，还有另一个小问题需要重视。

老T使劲查看了一遍 PVE 面板，发现除了节点显示灰色问号，还有另一个问题，就是节点上 CPU 和内存利用率这些基本信息也不显示，包括图表信息也都丢失，图标下方直接显示 1970 年 1 月 1 日。

系统时间

于是，老T开始怀疑是否是系统时间服务故障导致的这一系列问题。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

root@epson:# timedatectl
Local time: Mon 2025-08--31 21:18:39 CST
Universal time: Mon 2025-08--31 13:18:39 UTC
RTC time: Mon 2025-08--31 13:18:39
Time zone: Asia/Shanghai (CST, +0800)
System clock synchronized: yes
NTP service: active
RTC in local TZ: no
root@epson:# hwclock --show
2025-08--31 21:19:03.141107+08:00

不过并未发现故障。系统时间都是正确的。

文件路径问题

没办法，只剩一条路，重建配置文件。

照旧，先检查一下 corosync 状态。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

root@epson:~# systemctl status corosync
○ corosync.service - Corosync Cluster Engine
 Loaded: loaded (/lib/systemd/system/corosync.service; enabled; preset: enabled)
 Active: inactive (dead)
 Condition: start condition failed at Mon 2025-09-01 21:13:46 CST; 6min ago
 └─ ConditionPathExists=/etc/corosync/corosync.conf was not met
 Docs: man:corosync
 man:corosync.conf
 man:corosync_overview

Aug 31 21:13:46 epson systemd[1]: corosync.service - Corosync Cluster Engine was skipped because of an unmet condition check (ConditionPathExists=/etc/corosync/corosync.conf).
root@epson:~#

不检查不要紧，一检查状态又发现新问题。前边检查集群配置时，系统提示缺少 /etc/pve/corosync.conf ，但 corosync 状态却显示它在查找 /etc/corosync/corosync.conf，两个路径似乎不一致。

于是老T试图修复一下这个问题。结果并没有区别，corosync 依然提示无法查找到配置文件。

1
2
3
4

oot@epson:# mount | grep /etc/pve
/dev/fuse on /etc/pve type fuse (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other)
root@epson:# mkdir -p /etc/corosync
root@epson:# ln -s /etc/pve/corosync.conf /etc/corosync/corosync.conf

重建集群配置

终于开始重建配置。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

root@epson:# systemctl stop pve-cluster pvedaemon pveproxy corosync # 停止服务
root@epson:# rm -rf /etc/pve/* # 删除原配置
root@epson:# rm -rf /var/lib/pve-cluster/* # 删除原配置
root@epson:# mkdir /etc/pve # 重建目录
root@epson:# mkdir /var/lib/pve-cluster # 重建目录
# 写入配置
root@epson:# cat > /etc/pve/corosync.conf <<EOF
totem {
version: 2
cluster_name: epson
transport: knet
crypto_cipher: aes256
crypto_hash: sha256
}
nodelist {
node {
name: epson
nodeid: 1
quorum_votes: 1
ring0_addr: 192.168.1.8
}
}
quorum {
provider: corosync_votequorum
expected_votes: 1
}
logging {
to_syslog: yes
}
EOF

root@epson:# chown root:www-data /etc/pve/corosync.conf
root@epson:# chmod 640 /etc/pve/corosync.conf
root@epson:# rm -f /etc/corosync/corosync.conf # 删除旧链接
root@epson:# ln -s /etc/pve/corosync.conf /etc/corosync/corosync.conf
root@epson:# systemctl daemon-reload
root@epson:# systemctl start corosync
Job for corosync.service failed because the control process exited with error code.
See "systemctl status corosync.service" and "journalctl -xeu corosync.service" for details.

一整套搞下来，过程都挺正常，但结果 corosync 还是崩了。查看日志发现，是缺少认证密钥文件 Could not open /etc/corosync/authkey: No such file or directory。

修复密钥文件

简单修复下密钥文件，并按照错误提示，将其链接到对应路径。

1
2
3
4
5

root@epson:# corosync-keygen
Corosync Cluster Engine Authentication key generator.
Gathering 2048 bits for key from /dev/urandom.
Writing corosync key to /etc/corosync/authkey.
root@epson:# ln -s /etc/pve/authkey /etc/corosync/authkey

重新检查 corosync 状态，发现这次终于没问题了。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

root@epson:~# systemctl status corosync
● corosync.service - Corosync Cluster Engine
Loaded: loaded (/lib/systemd/system/corosync.service; enabled; preset: enabled)
Active: active (running) since Mon 2025-08-31 21:37:39 CST; 29s ago
Docs: man:corosync
man:corosync.conf
man:corosync_overview
Main PID: 18905 (corosync)
Tasks: 9 (limit: 18833)
Memory: 112.4M
CPU: 204ms
CGroup: /system.slice/corosync.service
└─18905 /usr/sbin/corosync -f

不过，corosync 虽然修复，但是最开始的 epson 节点上灰色问号问题依旧没能解决。也就是说，目前还是没能定位到实际问题所在。

重置配置

接下来开始进入深坑。

在开始重置集群配置前，照例先将 cluster 原本文件删除。结果，哦豁，PVE 彻底崩了。

1
2
3
4
5
6
7

root@epson:# systemctl stop pve-cluster corosync pvedaemon pveproxy
root@epson:# rm -rf /var/lib/pve-cluster/*
root@epson:# pvecm updatecerts -f
ipcc_send_rec[1] failed: Connection refused
ipcc_send_rec[2] failed: Connection refused
ipcc_send_rec[3] failed: Connection refused
Unable to load access control list: Connection refused

好在，此前在上一个环节中，还备份了文件，于是找到备份文件恢复过来。

想着起码不至于全崩吧，回到本次开局状态就行。

结果，问题依旧。查看日志，发现出了个奇奇怪怪的新问题，pmxcfs 无法打开数据库文件 ‘/var/lib/pve-cluster/config.db’。

1
2

[database] crit: splite3_open_v2 failed: 14#010
[main] crit: memdb_open failed - unable to open database '/var/lib/pve-cluster/config.db'

抱着破罐子破摔的想法，要么就彻底来次重配吧。

1
2
3
4
5
6

rm -rf /var/lib/pve-cluster/*
rm -f /etc/corosync/corosync.conf
rm -f /etc/pve/corosync.conf
rm -f /var/lib/corosync/*

apt-get install --reinstall --purge pve-cluster corosync

于是，老T将 cluster 和 corosync 干脆一并删了，重新来过。

但，依旧失败。PVE 面板此时已经没法恢复。由于虚拟机还在运行，老T也没继续折腾。等第二天再弄。

二次修复集群配置

第二天早上，老T 早早的就起来，想着趁上班前早点修复这个。

不得不说，睡了一晚，人也清醒多了。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

# 检查备份现有文件
ls -la /var/lib/pve-cluster/
cp /var/lib/pve-cluster/config.db /root/config.db.bak.$(date +%Y%m%d)

# 停止进程
systemctl stop corosync pve-cluster pvedaemon pveproxy
pkill -9 pmxcfs

# 修复数据库
sqlite3 /var/lib/pve-cluster/config.db ".dump" > /root/dump.sql
sqlite3 /var/lib/pve-cluster/new_config.db < /root/dump.sql
mv /var/lib/pve-cluster/new_config.db /var/lib/pve-cluster/config.db
chown www-data:www-data /var/lib/pve-cluster/config.db
chmod 0600 /var/lib/pve-cluster/config.db

## 重启集群服务
systemctl start pve-cluster

不过，重启依然失败。查看日志，发现是 pmxcfs 无法挂载文件系统到 /etc/pve 。也是个稀奇古怪问题。

仔细检查 /etc/pve 路径发现，原来此前用的 rm -rf /etc/pve/* 命令，只是删除了目录中部分文件，对于以点（.）开头的隐藏文件并没有删除掉，导致目录实际不为空。

又重新来一遍，将 /etc/pve 目录移除，重新创建空目录。

然后将原来的两个虚拟机配置重新写入 /etc/pve/qemu-server/100.conf /etc/pve/qemu-server/101.conf。

总算是回到了起点。

即，PVE 中节点 epson 上显示灰色问号。折腾两趟，毫无起色。

远程把 PVE 干丢了

老T把这段过程，找 DeepSeek 复盘，看看中间到底哪里出了差错。结果它立马提醒，在恢复集群配置后，该立马更新网络配置。

也就是信了它的鬼，老T按照它提供方法，创建了网络配置，直接把远程 PVE 干离线了。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

# 创建临时网络配置
cat << EOF > /etc/network/interfaces.tmp
auto lo
iface lo inet loopback

auto eno1
iface eno1 inet manual

auto vmbr0
iface vmbr0 inet static
 address 192.168.1.238/24
 gateway 192.168.1.1
 bridge-ports eno1
 bridge-stp off
 bridge-fd 0
EOF

# 应用配置
mv /etc/network/interfaces.tmp /etc/network/interfaces
chmod 644 /etc/network/interfaces
systemctl restart networking

拯救 PVE 网络问题

一波未平一波又起，被 deepseek 这样一搞，心态又崩了。只能找 Gemini 来挽救下。

排查发现，PVE 网络本身并没啥太大问题，能够正常联网。

只是因为此前在写入两个虚拟机配置时，错写了磁盘空间格式，应该写成 64G 被老T写成 64 GiB，导致 PVE 无法解析磁盘。因而在网络配置重启后，无法连接到虚拟机。

但也就是在排查这个网络问题过程中，让老T看到一个新的问题。

在运行状态中显示，这个节点的名称叫 2606:4700:3037::6815:3752 ，而在corosync 配置中，这个节点名称叫 epson 。

按道理，当 corosync 服务启动时，它会读取配置文件中的 name: epson。然后，它需要将 epson 这个名字解析成一个 IP 地址，以便在网络上进行通信。如果在这个解析过程中失败了，corosync 可能会“自暴自弃”，直接使用IP地址作为自己的名字。

经详细检查发现，是因为老T之前曾修改过 PVE 的主机名，正常情况下，节点应该解析到 192.168.1.238，但添加了自定义域后，节点被解析到 Cloudflare 的 IP 。将 Hosts 顺序调整后，算是修复了这个 Bug。

1
2
3

root@epson:~# getent hosts epson
2606:4700:3037::6815:3752 epson.fosu.cc
2606:4700:3031::ac43:91f8 epson.fosu.cc

结局

我重新看了下 PVE 面板各项功能，在将硬件状态监控面板时长从“天”调整到“月”后，终于是发现大问题。

原来，这个PVE节点故障，已经存在 10 来天了。按照 8 月 21 日的时间节点，有可能是因为当时安装 PVEtools 的缘故。

由于当时为了解决飞牛系统中硬盘显示温度问题，过程中曾一度安装过 PVEtools 更改面板设置，添加了温度监控。

在想起这茬事后，立即开始验证。

1
2
3
4

root@epson:~# dpkg --verify pve-manager # 验证文件改动情况
missing c /etc/apt/sources.list.d/pve-enterprise.list
??5?????? /usr/share/perl5/PVE/API2/Nodes.pm
??5?????? /usr/share/pve-manager/js/pvemanagerlib.js

毫无疑问，因为 PVEtools 的安装，导致 PVE 管理器后端 API 和核心 JS 库都被改动过。即便我印象中，安装 PVEtools 中相关组件后曾进行卸载，也不起作用。

于是重新安装 PVEmanager。这次终于是把 PVEtools 残留在面板上的温度显示给去掉了。

1
2

apt-get update
apt-get install --reinstall pve-manager

接着继续排查，PVETools 安装后可能给 PVE 带来的负面影响。

经查看 PVE 各种组件状态，在排查到 PVE 状态守护组件时，发现它一直在疯狂报错。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

root@epson:~# systemctl status pvestatd # 验证PVE状态守护情况
● pvestatd.service - PVE Status Daemon
Loaded: loaded (/lib/systemd/system/pvestatd.service; enabled; preset: enabled)
Active: active (running) since Tue 2025-09-01 19:07:31 CST; 5min ago
Process: 1081 ExecStart=/usr/bin/pvestatd start (code=exited, status=0/SUCCESS)
Main PID: 1116 (pvestatd)
Tasks: 1 (limit: 18833)
Memory: 156.2M
CPU: 2.704s
CGroup: /system.slice/pvestatd.service
└─1116 pvestatd

Sep 01 18:11:50 epson pvestatd[1116]: node status update error: Undefined subroutine &PVE::Network::ip_link_details called at /usr/share/perl5/PVE/Ser>
Sep 01 18:12:00 epson pvestatd[1116]: node status update error: Undefined subroutine &PVE::Network::ip_link_details called at /usr/share/perl5/PVE/Ser>
Sep 01 18:12:10 epson pvestatd[1116]: node status update error: Undefined subroutine &PVE::Network::ip_link_details

最后，老T通过对 PVE 进行一次完整的组件升级，解决问题。

1

apt update && apt full-upgrade

问题回顾与总结

1. 初始症状

   • PVE 节点状态显示 unknown（灰色问号），无法创建虚拟机，节点性能图表丢失（显示 1970 年 1 月 1 日）。

2. 弯路 1：误判存储配置冲突

   • 怀疑直通硬盘遗留的无效存储配置（HDD1/HDD2）导致问题，清理后重启但问题未解决。

3. 弯路 2：错误重建集群配置

   • 发现 corosync.conf 丢失并尝试重建集群（包括修复路径、密钥文件），但节点状态异常依旧。

4. 弯路 3：被误导修改网络配置

   • 依据错误建议重写网络配置，导致 PVE 失联，后修复 hosts 解析（节点名误解析到 Cloudflare IP）但核心故障仍在。

5. 初步怀疑

   • 结合时间线（故障始于 8 月 21 日）和操作历史，怀疑 pvetools 脚本（曾用于添加温度监控）是根源。

6. 关键证据 1

   • dpkg --verify pve-manager 确认核心文件（Nodes.pm, pvemanagerlib.js）被 pvetools 修改。

7. 第一次尝试

   • 重装 pve-manager：恢复了被修改文件（温度监控消失），但节点状态异常仍未修复，表明问题更深层。

8. 决定性证据 2

   • 检查 pvestatd 日志发现致命错误：Undefined subroutine &PVE::Network::ip_link_details，明确指向库版本不匹配。

9. 根本原因

   • PVE 组件版本冲突：新版本 pve-manager 调用了旧版 Perl 库（如 libpve-common-perl）中不存在的函数。

10. 最终解决方案

    • 执行完整系统升级：apt update && apt full-upgrade，同步所有 PVE 组件至兼容版本，彻底解决问题。

2025-08-30 20:30:00

这是老 T 在 8 月份的说说内容，这里将其一并提取发布，主要包括 Folo RSS 更换域名后的一些问题，医保用药问题，汽车滤芯损毁问题，以及在使用飞牛和群晖过程中遇到的一些问题等。

Github issue 作为博客说说发布页面的模板设置问题

在设置模板过程中，需要留意以下几个问题：

1. 页面构建缓存。可能导致页面内容可能无法更新。

1
2
3
4
5
6

 {{ $url := "https://api.github.com/repos/user/moments/issues/1/comments" }}
 {{ $opts := dict
 "headers" (dict "User-Agent" "Hugo Static Site Generator")
 "cache" 300
 "cacheKey" (printf "gh-comments-%s" (now.Format "2006-01-02-15:04"))
 }}

2. 内容排序。 github issue api 输出数据是最新的内容在后边，需要倒过来。

1
2
3
4

 {{ with resources.GetRemote $url $opts }}
 {{ if and .Content (ne .Content "") }}
 {{ $comments := .Content | transform.Unmarshal (dict "format" "json") }}
 {{ $sortedComments := sort $comments "created_at" "desc" }}

3. 时间格式。github issue 默认使用 UTC 时间，中国的话，需要在基准上加8个小时。

1
2
3

<time>
 {{ (.created_at | time.AsTime).Add 28800e9 | time.Format "2006-01-02 15:04" }}
</time>

Folo 使用过程中的几个问题

最近在使用 Folo (follow) 过程中发现几个问题：

RSSHub 源失效问题

在我的中文博客列表中已有 28 个 RSS 源失效，占比 20% 左右，但这些都是个人站点，倒也正常。有时候换个域名或者换个程序原来的 RSS 链接就没法跟踪了。但 RSSHub 这边，像知乎这种大平台的 RSS 源失效，真是不能忍。输出结果都是 403，应该是知乎那边把 RSSHub 屏蔽了。

Error Message:

FetchError: [GET] "https://www.zhihu.com/people/rpwi/": 403 Forbidden

Route: /zhihu/posts/:usertype/:id

Full Route: /zhihu/posts/people/rpwi

RSS 源的图标缓存问题

我博客的 RSS 源是去年下半年添加的，当时正在更换域名，临时找了个 favicon 顶着，没过几天便换了新的、正式的 favicon。但没想到，Folo 现在依然使用的首次添加时的 favicon。

Folo 使用了 webp.se 的图片缓存服务，它在获取网站图标后，自动添加了一个回退源参数 ?fallback=true ，我看 webp.se 文档介绍，他们是每天更新一次缓存，但 Folo 这边似乎是定死了缓存图标，没找到哪里可以刷新，我试着在链接上使用常见参数来刷新，但都无效。事实上 webp.se 获取我博客图标毫无问题。

Folo 图标地址： https://unavatar.webp.se/lawtee.com?fallback=true

正常图标地址： https://unavatar.webp.se/lawtee.com

该问题经过一阵折腾，后来算是解决了。但我也不知道到底是哪个操作导致刷新成功的。

RSS 源迁移问题

我在去年将博客域名从 hyruo.com 更换到 lawtee.com 后，将原来的 RSS 链接作了 301 重定向。

https://hyruo.com/index.xml --> https://lawtee.com/index.xml

我看 Folo 是可以识别到这种迁移的。

但问题是，每次重置 RSS 源后，隔上几分钟，总会失效。链接地址又会从 lawtee.com 变回去 hyruo.com。

Folo RSS 页面地址：法律小茶馆

之所以存在这种问题，主要是因为 Folo 会自动在 RSS URL 后方加入机器校验。在迁移时，会自动为新的 RSS 源设置迁移标识，只有当访问 https://hyruo.com/index.xml#migrate-102195283873064960 这种链接能够正确进入到新的 RSS 源时才能成功。（不过folo那边始终有问题，经常在两个url中反复横跳，我也不确定是不是真的就能永久成功）

更换小米 14 手机

前两天，老婆跟我说她手机突然开始变卡了，微信动不动就没法下载图片，无法打开 Office 文件，无法打开别人发的视频，自己发图片出去也经常失败，打开微信视频号中的视频也无法观看，关机重启好一阵但没过多久又这样。我帮他清理了手机存储，清理了微信缓存，但总是没过多久又会出现故障。

我知道这个原因主要出在她微信上存储的东西太多，目前手机上两个微信已经占了500GB存储容量，但她什么东西都舍不得删，上万好友加上千个微信群，也是难为手机了。

她目前用的是 Vivo X100 Pro 1TB 的手机，鉴于她不肯删微信记录，重置手机又耗时耗力，我只好重新帮她买了个小米 14，由于是老款，价格也还不错，2700 多块钱 1TB 版本，应该足够她继续用一年微信不卡了吧。后续再出问题，只能麻烦点，再倒腾回 Vivo 了。

VIVO 手机APP迁移乌龙

昨晚在将 vivo X80 迁移到 vivo X100 Pro 时闹了个乌龙。第一次迁移时，手机设置和自带应用那些都成功迁移了，微信 QQ 也都正常迁移，但是大量手机应用程序 APP 却未成功。

此前，在将 vivo X100 迁移到小米 14 时，并没有发现这种问题。于是在想，是不是因为我大量的应用都是使用谷歌Play安装所导致。此前，vivo X100上所有的应用都是使用vivo自带应用商店安装的。

然后我下载了一款第三方迁移手机应用的软件，折腾了大半个小时，发现这个迁移也没办法做到把应用的数据部分同步迁移过去，只能迁移应用本身。

这可把我急坏了，因为我手机上 100 多款应用大多，很多都是从谷歌 play 或者 github 上面下载的，不少应用都没有账号同步功能，如果都要从头再来，这可是个巨大的工程。

我又使劲研究了一下这个 vivo 一键换机功能，最后发现是我在以前为了防止各种 app 胡乱读取我的 applist，将一键换机的应用也给限制读取 applist 权限。但很可惜，在使用一键换机过程中，vivo 并未提示应用权限缺失，而此前我在小米 14 上，印象中换机时该应用逐个提醒我打开了各种权限功能。

在找到问题后，我重新启动了一键换机，发现全部 APP 及数据都能正常迁移。包括 google play 本身都可以迁移，暂未发现任何使用问题。

医保用药是不是坑

医保集采后，我一直以为医院的药都很便宜。此前，我妈因慢病每两三个月都去医院开药，都是一二十块钱。但今天去医院复查时，我仔细看了下医生开的几个药，发现每个价格都不便宜。

首当其冲那就是那个高锰酸钾片，我此前在京东买了一盒，5块钱。

但医院这个，相同份量，居然要60块。我又在京东查了下同款高锰酸钾外用片，确实也卖60块。

然后我仔细看了下区别，京东买的这个5块钱高猛酸钾片，只有企业标准，连个“消字号”都没有，而医院同款的是 OTC 。

我进一步搜索发现，目前国内就两款 OTC 的高猛酸钾外用药。一个是上边图上的济南康福生“TXTY”牌，另一个是山东明仁福瑞达制药股份有限公司生产的。不过，目前在售的只找到"TXTY"牌的，而福瑞达这个，全网连个药盒子照片都找不到。

也就是说，目前这个"TXTY"牌的高锰酸钾外用片，几乎是个垄断药了。难怪卖的这么贵。

知乎回答首破8000赞

前几天在知乎看到甘肃庆阳市宁县一家长发视频质疑校服问题被拘留事件有关话题，看了几百个回答，感觉都是草草输出情绪为主，便试着写了个回答，花了一个晚上时间。结果第二天起来，发现收获了 5000 点赞。截至目前，已经超过 8000 赞和 2000 收藏。也算是在情绪价值上收获了回报吧。

老早就知晓，这种封闭平台的流量，是显著高过个人博客的，但定位不同，也不好比较。事实上，我早就把知乎上2019年之前的回答全部删除，主要也是公开平台确实更多输出的是一刹那的情绪，而博客这边反倒心态平和很多。

群晖中报废 SSD 一块

之前从群晖中移除两块硬盘格式化后放到了Epson ST190E主机里边用作飞牛NAS存储。

看到群晖硬盘仓空荡荡的，就从老电脑拆了块SATA口的SSD进去，想着也试试群晖+固态，看能不能提点速。

结果，在系统中没发现有 SSD 缓存功能，一查群晖网站，发现我这款NAS不支持 SSD 缓存。

既然不能当缓存，那当个软件盘总可以吧。于是把盘格式化成basic模式进去，安装了几个常用软件在上边。

直到8月12日那天，我打开群晖面板，才发现这块没放进去多久的硬盘已经彻底崩了。

从8月8日晚上，到8月12日，NAS无数次试图通过SMTP发邮件告诉我这回事，但因为SMTP配置已经过期，我显然没有到邮件通知。错过了最佳抢救期。事实上，8月8日错误次数还比较少，到8月11日，我看它一天内弹了600多次严重警告，估计就是系统在跟硬盘疯狂搏杀了，到8月12日，系统已经完全无法读到硬盘，此时硬盘也彻底报废了。

SMTP过期这种事情，确实很麻烦，群晖这个SMTP我起码设置有四五年了，估计是因为中途改过邮箱密码所导致，平常也想不起来这么多事情。例如，刚才我查看QQ邮箱的SMTP设置，发现有几个授权码莫名其妙，也不知道自己啥时候设置的，IP有的在美国，有的在马来西亚，还都在近期发过信，但我丝毫没印象。

飞牛相册 AI 识图调度策略差异

飞牛的AI相册调度策略有点看不懂。

我上周第一次用 AI 相册识别时，人脸识别和智能分类识别，都是用的GPU在干活。由于两个进程都在调度GPU，导致GPU运转过程中 Render 使用率都是峰谷交错，每隔几秒满载一下，导致 CPU 风扇也是跟着不断循环往复从 20% 转速到 100% 转速反复横跳，CPU 核心则处于闲置状态。

由于上周识别效果差，特别是我家四个人的人像都识别失败，抱着不死心的态度，我又重新测试一遍。但这次 AI 相册识别时调度策略明显不一样了。这周是人脸识别的进程在调动 CPU 运算，而图像智能分类识别，是调动 GPU 在运算，好处是 CPU 和 GPU 基本都是同步持续稳定输出，CPU 占有率 3 核 40% 左右，GPU 这边整理利用率 25% 左右，其中 Render 部分稳定在 95% 以上。

这个调度策略我还是相对满意的。CPU 和 GPU 同时预算，两者识别速度都差不多。此前，只用 GPU 时，人脸识别大概比智能分类识别快 2 倍。现在两者半斤八两，速度只差个一半左右。但还是带来另一个问题：散热。目前 CPU 基本就在温度墙附近游离，维持在 80 度上下。

机油滤芯断在发动机里边

昨天下午开车去京东养车做保养，遇到个稀奇古怪的事情。

小伙子在帮我换机油的过程中，发现机油滤清器整个散架断在里边。

他反反复复把车升降，从发动机舱上方和底盘下方伸手去掏，但有一截始终掏不出来。

由于我这个车的发动机设计太过于奇葩，机油滤清器所在的位置太过狭窄，无论是从上面还是从下面去掏，手指都很难发力。花了大半个小时，把他心态都给搞崩了。

我在抖音查询这种情况，并没有找到类似的案例。最后根据原本的滤清器结构，建议他用一根铁丝去勾。经过几次尝试才终于把这玩意弄出来。

搞出来之后，小伙子跟我说这次保养得加钱。

好在我立马反应过来，说上一次保养也是在这家店做的，并打开京东app给他看了上一次保养记录。言外之意，之前这个滤芯也是在京东养车买的，坏了也得京东养车负责，并且这滤芯坏在里边，搞不好就是上一次保养的安装问题，没理由让我承担责任。

小伙也机灵，见我拿出上次保养记录，也没说啥，加钱一说便作罢。

解决 PVE 安装飞牛后，飞牛系统中不显示硬盘使用时长、温度等信息问题

之前我一直没留意飞牛中两块机械硬盘 SMART 信息，今天看下才发现，居然没法检测。此前，飞牛上一直显示这两块盘使用时长 1H 温度 31℃ ，当是 Bug了。

今天在 AI 提示下，说我原来设置硬盘直通，用的 SATA 模式有问题，得改成 SCSI 模式。

1
2

qm set 100 -sata1 /dev/disk/by-id/ata-ST2000LM015-2E8174_WDZBN66Q #AI提示把sata改成scsi就行
qm set 100 -sata2 /dev/disk/by-id/ata-ST2000LM015-2E8174_WDZBN776

结果，这一改，飞牛里边存储空间全乱套了，无法修复重建，只能格式化从头再来。同时，硬盘温度那边压根就不显示了，连 1H 31℃ 都没有。

后来，我在想，之前在设置 GPU 直通时也是信了 AI 的鬼，用的命令设置，结果一直没搞通，是直接在 PVE 中添加 PCI 设备成功的，是不是这次也可以试一下，结果这一试，两个问题都一并解决。

在虚拟机添加 SATA 控制器后，原来飞牛中的存储空间恢复正常，之前的数据也没丢，硬盘 SMART 信息也能够准确读取了，压根不用添加硬盘。

2025-08-28 15:20:00

虽然还没到 9 月 1 日，但我儿子今天已经提前去学校适应小学生活，随着新的阶段到来，我也想着给本博客换个名称。过程中，找两个小孩帮忙，顺便给他们解释了一下网站域名 Lawtee的含义，然后，不知怎得，两娃就突然开始喊我“老T”。感觉也是天意注定，那我就将本博名字改叫“老T博客”吧。

老T即Lawtee

去年我在选择 Lawtee.com 这个域名时，本来也没想太多，主要是 5 位带 law 三个字母的 com 域名，早已被注册殆尽，而 6 字母中带这三个字母的，也所剩无几，矮个子里边挑高个，最后也就选了这个。

在英文发音中，Law 的美式发音 /lɑː/ 读起来跟 老 字很相近，而 Tee 发音为 /tiː/ 跟字母 T 一模一样。因此，Lawtee 读成 “老T” 倒也显得理所应当。

这次更名前，我也在网上简单搜索了一下，好像叫“老T”这种名字的也不多，那就这样用了。

为什么不再用之前名称

此前，我将本博取名 “法律小茶馆” 其实是按照 Lawtee 意译而来，在一些欧洲国家，Tee 就是茶的意思，跟 Tea 的发音也没啥区别。

但正如目前所现，本博其实大部分内容都跟法律没啥关系，与法律相关主题最多能占到 1/4，强行取个这样的名字，很容易让人误解。

不过，总的来说，由于我长期从事法律工作，这个域名倒也没有继续更换的必要。只是文字介绍需要稍微变动一下，不再着重强调自己的职业，而是依据内容展现方向，改成了“法律、科技和生活”。

毕竟，工作只占日常 1/3 不到的时间，工作之余，这个身份也没有必要随时挂着碍眼了。

未来有何规划

这里还是引用之前更换 Lawtee.com 域名时的想法吧，其实也没什么大的变化。

正如我在 关于 页面中提到： “到 2023 年，自己也已经接近 35 岁，在一些行业都是开始想着退休的年龄，于是回头重构一下博客，想着就这样定型玩下去。” 本博客作为 1ip 博客定位，还是会坚持做下去。未来方向主要还是围绕自己工作学习有关的法学法律领域，并适当扩展一些生活内容，坚持做到知行合一吧。

更新一下自己的硬件清单

作为一个曾经误入歧途的老 IT 人，多年来，我始终对 IT 硬件保持着浓厚兴趣，即便都是些“家常菜”，但在自己眼里，对每一件都有着特殊感情。此前这些列表，曾作为“签名机”在 51nb maxpda 之类的论坛展示，这里也就合并罗列出来，并适当补充下参数和相关情况了。

明白了，我会将状态内容(如"在用"、“吃灰"等)放在参数行对应的年份列中(年份数字的正下方)。以下是修改后的内容：

PC 硬件

外设

影音娱乐

移动设备

网络和存储

远程资源

办公设备

2025-08-26 11:30:00

最近，我家一个智能马桶盖出故障，控制板上，除了水温按钮有反应，其他按钮全失灵，而且重新上电也没任何反应。直觉告诉我，这应该不是单一故障，而是多个问题同时存在所导致。为此，我晚上花了几个小时仔细研究了一下这个产品。

故障表现

这台松下 EKS09 智能马桶盖是我 2019 年买的，迄今已接近 6 年，超出了五年保质期。要么自己修，要么换新的。

考虑到我之后买的两个马桶盖水压普遍偏大，而这个松下的冲水柔和，主要是小孩在用，所以我第一反应还是想通过维修来解决。

此前这个马桶盖曾出现过按键失灵情况，一度所有按钮都没反应，但隔天又好了，应该是排线板接触不良或腐蚀问题。

这次故障更加麻烦点。

1. 控制面板上 8 个按钮。其中 6 个功能控制键中，只有 1 个水温键有反应；测试键方面，长按测试后灯常亮，但没进入测试，并且无论如何无法退出测试，着座键及灯光正常。

2. 在断电重新上电后，只听到电机嗡嗡声，但不出水，冲洗杆也不伸出来。

问题查找和维修过程

由于我此前对智能马桶盖的内部构造没有研究过，直觉上认为这次应该是两个问题。

1. 控制面板失灵；
2. 冲洗杆马达坏了或堵了。

主板

马桶盖外壳拆解倒是比较简单，总体来说，就是卸下螺丝，稍微用力就拆出来了。但真要找到问题所在还得花点功夫。

首先是肉眼观察整个主板，发现已经作了防水处理，肉眼也没见到有元器件烧毁情况。也应证了水温按钮可以使用、上电后电机会嗡嗡出声的情况，总体功能上应该没大的问题。

出水杆

其次，重点是研究这个出水杆的构造。

这个出水杆由两个马达控制，蓝色管进水，白色管输送到出水杆中。

我一开始不知道这个东西原理，以为是出水杆末端马达控制升降，三角位的马达在抽水。

后来才知道，出水杆末端那个马达仅仅是起到旋转开关的作用，控制阀门；而控制升降的是三角位的马达。

但拆下这两个马达后，却也没发现什么异常情况。

在整机上电后，末端马达能够正常运转，在我强行将出水杆拉出来之后，三角马达也能将出水杆缩回去。

说明马达本身应该没什么问题，只是这个出水杆无论我怎么测试都不能自动伸出来比较头疼。

我开始怀疑这个伸缩杆里边的伸缩装置是不是出了什么问题，只能缩回去，没法伸出来。

不过这玩意压根没法拆，在把马达卸下后，发现整个塑料部分似乎是一体成型的。

但也有另一种可能，就是在我测试这个出水杆时，发现蓝色管子那边，也不出水。

这就奇怪了。

如果是卡在伸缩杆这边，那就相当于水堵在这里边出不来。

但如果蓝色管子也不出水，说明问题还在前端，不在这里。

当然，不排除出水杆也坏了，那这局面就更复杂了。

热水箱

接下来，我开始重点排查这个蓝色管子前端的水路构造。

这个水路总体来说比较简单，左下角电磁阀控制进水，电磁阀两个出口，一个出口直通热水箱，另一个在底端连接一个压力阀门，当水压过大时直接从底部透明管道排出。水箱顶上满水时，也会通过透明水管从底部排出。水箱右侧就是出水口，用蓝色水管连接前边的出水杆。

我用手机闪光灯照了下热水箱，并没有看到里边有浑浊物，蓝色水管和透明水管都没有堵塞迹象。说明热水箱出水这边水路应该是通的。

于是重点排查对象就来到了前端电磁阀。

电磁阀

这个电磁阀左边连接进水管，右边固定在水箱底部接口，应该是整个水路的核心。

不过这玩意很不好拆，四个螺丝都朝向内测，这一侧被马桶盖的座圈给挡着，想拆的话要么把热水箱拆了，要么把座圈拆了，而座圈那边因为要达到防水效果，拆除难度非常大，最后没办法，只能拆热水箱。

好在热水箱也只有一颗螺丝固定，只是热水箱顶部就是主板，各种线材卷在一起，很难拉出来。

最后，我是靠着整机塑料外壳的韧性，强行扭曲外壳拆解下来的。

拆完电磁阀，我看了下里边，似乎也没发现啥问题，除了黑色胶卷上有一层薄薄的白色水垢，其他无异常。

然后装回去。没想到，一装回去，通上电，下水管就出水了。

这可把我高兴坏了，我还以为问题彻底解决。立马关了电、关了水，开始修复控制板排线。

排线板

在此之前，我为了测试按钮功能，早已把控制板拆个精光，胶合的排线都被我硬撕开了，想着是不是哪里发生短路导致的，把一个个按钮都拆掉逐个测试。

把排线版重新装好，插回主板上，重新通电、通水，一下给我干蒙了。

的确，现在排线板上已经有按钮能控制出水杆出水。喷头出水那一刻，也让我如释重负。

但下水口一直在流水是咋回事。

仔细看，水应该是从电磁阀后边的泄压阀流出来的。

电磁阀安装

莫非，自己拆电磁阀时，把这玩意搞坏了？

联想到家里水压过大，导致家中电热水器外的泄压阀也一直在滴水，莫非是因为我家水压过大导致的？

或者，是电磁阀没装好，里边配件需要特定角度安装？

抱着不死心的态度，我开始网上查电磁阀原理。

发现其实也挺简单，就电磁控制阀内一个金属棍，金属棍吸上去，阀门就打开，金属棍放下来，阀门就关闭。金属棍后边一个小弹簧，确保金属棍能压住阀门出口。

对了，金属棍。

我想起来在安装电磁阀时，怎么好像没见到这玩意。

于是重新拆下电磁阀，发现里边果然没有金属棍。

我又在洗手间地上各个角落找，都是一干二净，也没发现啥东西。

最后，我晃了晃马桶盖，发现里边好像有东西，搞不好就是这玩意。

把热水箱拆掉后，果然，一个一头沾着橡胶头的小金属棍就躺在机壳最深入。

这应该是我在首次拆电磁阀时，被弹簧意外弹飞的，当时我也没留意有这个，以为电磁阀里就这点塑料和橡胶件。

最终，在将这个金属棍塞进电磁阀，重新安装好上电后，下水口不再异常出水。

控制板上除了原本就失灵的按钮，剩下的也能正常运作。

问题终于得到解决。

总结

这次维修，我本来没报太大期望，主要是这玩意并非单一故障，而是多个故障混在一起，查找定位起来麻烦。

加上以前也没接触过这个，过程中走了很多弯路。一度想着破罐子破摔，拿把剪刀把排线板从尾端开始剪，一断一断来测试，反正都坏了，不研究出个所以然来，对不住自己的劳动。

包括在拆解过程中，有时就是蛮力搞，好在这个产品还比较结实，像拆电磁阀时，电磁阀两个接头因为卡在热水箱加热棒的接头上，被我拽来拽去好多次，居然没松动；排线接口，被我反复插拔几十次，依然能稳定使用；主板上各种接口接线也在拆卸过程中被我反复拉扯，一个都没断，也算是不错了。

通过这次维修，我算是初步摸清智能马桶盖的构造，对各个配件和功能实现算是有了比较清晰的认识，以后再遇到这种问题就容易多了。

此外，在拆解控制板的过程中，我发现这玩意防水效果还真是有待改进，一拆开控制板，就发现排线开关下边有一圈黄色的水滴，应该是渗水或者水汽渗入导致的。长期下来，排线被腐蚀导致按键失灵也就不意外了。

看了一圈淘宝，发现更换控制板的情况还是挺多的，但价格也不便宜。一个塑料件 + 排线开关就得 120 元，如果买第三方 DIY 的排线，也得 70 元。感觉不值这个价。先暂且用着，迟点闲鱼再看看情况。

总之，一个已经用了 5 年的电子产品，也不指望它能继续用多少年了，迟早还是得换新的。只是，最近这段时间实在被京东恶心死了，每看一个电子产品，都标着几个价格，其中国补价格比标价便宜个 15%-20%，感觉给用户信号就是，没用上国补的就是冤大头，但一查国补资格，全国就两个省份能用，真是膈应。

2025-08-19 16:30:00

之前在 群晖、迷你主机还是捡垃圾，家用NAS怎么选 提到，我家里 NAS 存储的重要家庭数据已经达到 1000GB，主要就是家中多年积累下来的照片、视频，共计约 20 万文件。虽说存储量也不大，但在迁移过程中，还是感觉很吃力，大量小文件读写，用移动硬盘复制都得几个小时。为了解决这个问题，便于日后轻松上阵，我借鉴之前在 hugo 和 soomal 项目中的经验，对 NAS 文件来了次大瘦身，节约 75% 的空间。

清理重复文件

我以前备份照片视频的模式，基本都是采取每年一到两次的频率，将相机、手机照片视频冷备份到 NAS。大体是选择在春节、国庆长假这种时间节点，以及换手机的时候，一股脑把手机上照片视频通过移动硬盘复制过去。

在这过程中，有一个比较麻烦的事情是，每次我换手机都会将上一台手机的照片视频导入新手机，而上一台手机中很多照片、视频实际上都已经在 NAS 有备份。这种情况下，如果自己备份的时候认真一点，通常会考虑删除一遍重复文件，但很多时候比较懒就没管了。造成 NAS 中实际上有不少文件都是重复版本。

要清理群晖 NAS 中的重复文件，通常有三种方法。

1. 群晖自带的存储空间分析器。打开群晖自带的存储空间分析器，查找“潜在重复文件”，通常会输出一个 csv 文件，列明重复文件。把需要删除的文件导出为 txt，然后在“任务计划”中通过命令 cat /volume3/video/delete.txt | xargs -I {} rm -f "{}" 就能把重复文件删除。

这种方法只适合重复文件数量较少的情况。例如，我的群晖每次只支持查找 5000 个重复文件。如果重复文件显著超过这个数值，就不是很实用了。毕竟，每次查找重复文件都耗时颇多。

2. 第三方应用工具。 群晖第三方应用市场有几款删除文件工具比较实用。例如：dupeGuru fdupes 等。我也下载测试过，但查找速度比较慢，主要是因为我的群晖 CPU 性能太低了，几个小时都没输出结果，就没等下去了。另外，这种方式其实也相对不是很直观，如果对重复文件的表现形式不是很确定，设置起来也麻烦。

3. Windows 重复文件删除软件。 通过文件挂载，在 Windows 上利用电脑 CPU 和电脑软件来查找重复文件。我使用的是 Duplicate Cleaner，进行了多次重复文件删除操作。包括：a. 查找相同 MD5 的文件；b. 查找相似文件名 + 相似大小的文件； c. 查找相似内容文件； d. 用图片模式。

过程中也并不容易。一开始我用重复文件名模式，结果发现，很多手机都用同一种命名方式，比如我能搜索到 5 个设备拍出来的照片都是 IMG_001.jpg 这种命名模式，必然会有大量文件重名。然后，很多文件在传输过程中被重命名了，原本可能是 IMG_001.jpg 但另一个版本的名字可能是一串随机数字，而且 md5 也不同。其次，有不少文件因为微信传输等原因，内置 exif 都不存在了，导致相似的两张照片文件数据区别稍大，需要将重复文件匹配的灵敏度调至最低才行。另外，还有不少 live photo 的文件，出现不同的保存策略，有的保存为一个文件，有的存为两个文件，大体是因为群晖在不同时期对苹果、安卓各种 live photo 格式支持策略不同的原因。

最终，经过重复文件清理，我群晖中保存的照片、视频下降到了 817 GB。

将照片转为 WEBP 格式

图片批量转 WEBP 我也不是第一次操作了，去年已将本网站所有图片转为 WEBP，前几个月把 Soomal.cc 上近 10 万张照片也转为了 WEBP 格式。

我对 WEBP 格式非常喜爱，即便此前将 JPG 转 WEBP 只保留 70% 质量，肉眼也很难分辨出两者之间的差异。这次保险起见，我设置了 85% 的质量，拿两个 4K 显示器对测试图片进行对比时，也是看不出什么差距。也可能因为我是色弱的原因吧，我找小孩帮忙看看，她说除了颜色淡点，也没看出个所以然来。

既然差距不大，那我将 NAS 中全部文件转为 WEBP 就不再有任何心理压力了。即便是 WEBP 色彩不如 JPG 丰富，也就是一个手机相册修图 AI 滤镜就能解决的事。但两者存储大小，可是差了三四倍。

我此前曾用 ChatGPT 写过一个简单转换代码，这次还是差不多。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

@echo off
setlocal enabledelayedexpansion

for /r %%i in (*.jpg *.jpeg *.png) do (
 set "newFile=%%~dpi%%~ni.webp"
 cwebp -q 85 "%%i" -o "!newFile!"
 del "%%i"
 rename "!newFile!" "%%~nxi"
 echo Converted %%i to "%%~nxi"
)

echo All images converted and originals deleted.
pause

不过，这次除了 JPG PNG 还得考虑 RW2 CR2 HEIC 等格式转换问题，同时还得确保前后照片 EXIF 信息不丢失，整体转换代码稍微复杂点。但只要提示得当 AI 基本都能一次过。

将视频转为 H265 编码

我家庭存储的视频，有很多都是相机原生格式，不少都是老编码大码率的 mp4 mov。这次我准备将它们来个瘦身。

一开始我盯上的是 av1 编码，毕竟原生视频压缩到 av1，存储容量压缩四五倍都是正常的。

但有两个问题比较头疼，一是我家里的 RTX 2080 显卡不支持硬解 av1 编码，如果要用 CPU 来软解，这个过程过于漫长了； 二是我的飞牛 NAS 所使用的 i3-8300T CPU 也不支持硬解 av1，日后播放起来也比较麻烦。

最终，我还是保守起见，选择使用 H265 编码来压缩，没想到效果倒也很不错，即便是较新的 H264 转 H265，也能压缩一倍多容量。

这种转换同样可以借助 AI 编写转换脚本，过程中注意几个问题就好： 1. 调用 GPU 参与转换；2. 注意保留原视频 EXIF 信息；3. 先测试再转换。 其中，我在测试时发现，EXIF 信息处理稍微麻烦点，因为 GPU 默认无法处理这个事情。最后，我是分开两步走，先转换视频，再通过另一个脚本将源文件 EXIF 写入转换后的 EXIF。

转换脚本示例：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50

import subprocess
import os

def convert_to_h265(input_file, output_file, crf=28, preset='fast'):
 """
 使用FFmpeg和NVIDIA GPU将视频转换为H.265编码

 参数:
 input_file: 输入视频文件路径(MOV/MP4等)
 output_file: 输出文件路径(建议用.mp4后缀)
 crf: 质量参数(18-28，值越小质量越高)
 preset: 编码速度预设(slow, medium, fast等)
 """
 if not os.path.exists(input_file):
 raise FileNotFoundError(f"输入文件不存在: {input_file}")

 # FFmpeg命令
 cmd = [
 'ffmpeg',
 '-i', input_file, # 输入文件
 '-c:v', 'hevc_nvenc', # 使用NVIDIA的HEVC编码器
 '-preset', preset, # 编码速度预设
 '-rc', 'vbr', # 可变比特率模式
 '-cq', str(crf), # 质量参数(类似CRF)
 '-qmin', '0', # 最小量化值
 '-qmax', '51', # 最大量化值
 '-b:v', '0', # 不设置目标比特率
 '-profile:v', 'main', # H.265 profile
 '-tune', 'hq', # 高质量调优
 '-movflags', '+faststart', # 流媒体优化
 '-c:a', 'aac', # 音频编码
 '-b:a', '128k', # 音频比特率
 output_file
 ]

 try:
 # 执行命令
 subprocess.run(cmd, check=True)
 print(f"转换成功: {output_file}")
 except subprocess.CalledProcessError as e:
 print(f"转换失败: {e}")
 except Exception as e:
 print(f"发生错误: {e}")

# 使用示例
if __name__ == "__main__":
 input_video = "input.mov" # 替换为你的输入文件
 output_video = "output_h265.mp4" # 输出文件名

 convert_to_h265(input_video, output_video, crf=23, preset='fast')

转换结果

通过将图片和视频转换为更高效格式，最终，我原本 817GB 的照片、视频库，被压缩到 248GB。

这个存储量，基本上我可以在现有各种存储方案，包括电脑、手机、移动硬盘、群晖、飞牛 NAS 以及 Onedrive 上都备份一遍，显著提升数据存储的可靠性。

同时，我也在移动硬盘和群晖中继续各保留一份原始文件，但其实必要性也不大。

我早年用佳能、松下拍过很多照片，都保留的 RAW 格式。当年想着，以后有需要时，再用 Photoshop 或 Lightroom 进行处理，但实际上最近 5 年以上，我电脑里连一个 Adobe 家的软件都没安装过。根本没有继续折腾的必要，一个轻巧的文件格式，直接用平板电脑或手机处理就够了，再不济，还有 AI 修图这种 Bug 级产品，再差的画质也都能修复。更何况目前保留的格式，跟源格式之间也没有显著差距，也就更心安理得。

EXIF 中 GPS 处理问题

在这次转换过程中，我无意间搞了个 BUG 出来，就是飞牛相册中，我的照片、视频里边，只有视频的 GPS 信息能显示到相册地图，所有 WEBP 都无法显示地理位置。

一开始我在飞牛的文件管理器中查看 EXIF ，并没有发现问题，无论是能显示到地图中的视频 EXIF 还是无法显示到地图中的图片 EXIF，在文件管理器中都能看到有 GPS 信息。

于是我在 MT Photos，群晖和手机中测试，发现这些 WEBP 照片的 GPS 显示都没有问题，图片都能正常加载到地图中。我一度以为这个飞牛相册的 BUG。毕竟，群晖、手机、MT photos 都显示正常，只有飞牛显示不正常，正常人都会认为这是飞牛相册的问题。

在官方论坛反馈多日后，开发人员才回复。让我上传几张样图供测试。

也就是在上传样图的过程中，我在飞牛相册中偶然查看了一下照片的 EXIF 详细信息（飞牛文件管理器中只显示 EXIF 简要信息）。这才发现区别。

1
2
3
4
5
6
7
8
9

# 源文件
"GPSLatitude": "23 deg 7' 47.54\" N",
"GPSLongitude": "112 deg 34' 56.19\" E",
"GPSPosition": "23 deg 7' 47.54\" N, 112 deg 34' 56.19\" E"

# 转换后
"GPSLatitude": "23 deg 7' 47.54\"",
"GPSLongitude": "112 deg 34' 56.19\"",
"GPSPosition": "23 deg 7' 47.54\", 112 deg 34' 56.19\"",

原来是我 WEBP 文件的 EXIF 中 GPS 信息丢了方位标识。也就是 E N S W 这种东经、北纬、西经、南纬符号，其他相册软件可能自动按照所属地区帮助补全了这些信息，而飞牛没有自动补全，自然也就无法识别这个 GPS 位置。

在知道问题所在后，解决起来倒也容易。由于我所有照片都是在国内拍摄的，也就是自动补全北纬、东经两个符号即可。在转换时，注意开启 CPU 多线程处理，实测 7 万照片，我的 AMD 9700X 8核16线程 CPU 满载半小时搞定。转换后，将照片增量备份到移动硬盘，然后将移动硬盘数据增量备份到群晖和飞牛 NAS 即可。