子方有料

P104-100 显卡（AMD B450 平台）调优与排障指南

Sun, 08 Mar 2026 17:58:13 GMT

一、硬件物理层：最基础也最致命

1. 金手指清洁（头等功）

现象： 显卡能识别（lspci 有名），但一跑加速（如 ComfyUI 采样）就报错 Xid 79 或掉总线。

经验： 矿卡长期处于高温、灰尘环境，金手指氧化层会严重干扰 PCIe 高频信号。使用橡皮擦反复擦拭金手指是解决“能认卡但不能算”的第一步。

2. PCIe 链路选择（x1 vs x16）

经验： 部分老旧/退役矿卡在 AMD 平台的 x16 插槽上可能存在信号不达标或损坏。如果 x16 槽始终掉卡，使用 PCIe x1 转接卡（矿卡延长线） 通常能获得极高的稳定性，虽然带宽低，但足以满足 AI 绘图需求。

权衡： x1 带宽（约 1GB/s）虽低但信号极稳；x16 模式（即使锁 Gen1 约 4GB/s）若物理受损则完全无法使用。

3. 平台的差异性

还有的情况，同样一块显卡，就是Intel主板可以识别，但是AMD主板无法识别。这是不同平台的兼容及宽容性问题。
早些年我也是AMD YES，但在虚拟化研究中，这个真的是让人苦不堪言。

二、 BIOS 与内核层：打通地址寻址

1. 核心 BIOS 设置

Above 4G Decoding: Enabled（8GB 显存映射必开）。
CSM: Disabled（纯 UEFI 环境，防止寻址冲突）。
PCIe Speed: 建议手动锁死 Gen1（提高老旧矿卡容错率）。
ASPM: Disabled（关闭节能，防止空闲掉卡）。

2. 宿主机内核参数

编辑 /etc/default/grub，在启动项添加：

pci=realloc pci=noaer

pci=realloc: 强制重新分配 PCIe 资源（解决 [disabled] 的核心）。
pci=noaer: 禁用高级错误报告（屏蔽微小信号波动触发的重置）。

三、设备节点深度识别（多卡识别手册）

在多显卡环境下，必须准确判断哪个 /dev 节点对应哪块卡。

1. 使用 by-path 建立物理映射（最准）

执行命令：ls -l /dev/dri/by-path

# 示例输出逻辑：
pci-0000:06:00.0-card   -> ../card1       # 物理 06:00.0 (P104) 对应的显示节点
pci-0000:06:00.0-render -> ../renderD128  # 物理 06:00.0 (P104) 对应的计算节点
pci-0000:08:00.0-card   -> ../card2       # 物理 08:00.0 (P400) 对应的显示节点
pci-0000:08:00.0-render -> ../renderD129  # 物理 08:00.0 (P400) 对应的计算节点

判断依据： 根据 nvidia-smi 中的 Bus-Id（如 06:00.0）在输出中寻找对应的 cardX 和 renderDX。

2. NVIDIA 核心节点对应

/dev/nvidia0: 通常对应 Bus-Id 靠前的第一块卡 (GPU 0)。
/dev/nvidia-uvm: 统一内存管理，CUDA 计算必须挂载。

3. 设备节点与物理卡精准对应（实测方案）

在多显卡环境下，必须准确判断 /dev/nvidia-caps/nvidia-capX 与具体物理 GPU 的对应关系，这通常由次设备号 (Minor Number) 决定。

一键获取映射关系：执行以下命令（通过抓取上下文确认型号、总线地址与 Minor 的成组关系）：

nvidia-smi -q | grep -E "Product Name|Bus Id|Minor Number"

实测输出示例：

Product Name    : NVIDIA P104-100
Minor Number    : 0
    Bus Id      : 00000000:06:00.0   # 确认 P104 对应 Minor 0

Product Name    : Quadro P400
Minor Number    : 1
    Bus Id      : 00000000:08:00.0   # 确认 P400 对应 Minor 1

匹配逻辑规则：
- 核心节点： /dev/nvidiaX 中的 X 直接对应 Minor Number。
- 能力节点： /dev/nvidia-caps/nvidia-capY 中的 Y 对应 Minor Number + 1。
本例映射结果：

显卡型号次设备号 (Minor) 对应核心节点能力节点 (Caps)

P104-100 0 /dev/nvidia0 nvidia-cap1

Quadro P400 1 /dev/nvidia1 nvidia-cap2

显卡型号	次设备号 (Minor)	对应核心节点	能力节点 (Caps)
P104-100	0	`/dev/nvidia0`	`nvidia-cap1`
Quadro P400	1	`/dev/nvidia1`	`nvidia-cap2`

💡 映射口诀： nvidiaX 对应 Minor；nvidia-capY 对应 Minor + 1。

排障备注： 若 LXC 内 nvidia-smi 报错权限不足，需在宿主机执行：
chmod 444 /dev/nvidia-caps/nvidia-cap*

四、虚拟化实战配置

1. LXC 容器（ComfyUI 专用精准映射）

在 /etc/pve/lxc/ID.conf 中，建议仅挂载 P104 相关节点：

dev0: /dev/nvidia0
dev1: /dev/nvidiactl
dev2: /dev/nvidia-uvm
dev3: /dev/nvidia-uvm-tools
dev4: /dev/nvidia-caps/nvidia-cap1
dev5: /dev/nvidia-caps/nvidia-cap2
dev6: /dev/dri/card1,gid=44
dev7: /dev/dri/renderD128,gid=105

2. VM 虚拟机（P104 特殊直通）

机型/BIOS: 必须使用 i440fx + SeaBIOS (Legacy)。

原因: P104 的 VBIOS 多不支持 UEFI GOP，使用 OVMF (UEFI) 引导会导致虚拟机无法初始化显卡。

五、总结建议

性能优化： 如果使用 x1 链路，启动 ComfyUI 建议添加 --lowvram --disable-cuda-malloc，防止瞬时总线压力过载。
多卡管理： 容器内使用 export CUDA_VISIBLE_DEVICES=0 锁定 P104，避免程序错误调用 2GB 显存的副卡。

说明： 本指南重点在于解决 AMD 平台下非标 NVIDIA 计算卡的“物理连接稳定性”与“设备节点精准隔离”。

NVIDIA Quadro P400 显卡直通与 OCLP 驱动注入实战教程

Sun, 01 Mar 2026 20:18:42 GMT

本教程针对在 Proxmox (PVE) 环境下，通过 OpenCore 虚拟机直通 NVIDIA Quadro P400 显卡并。不过，p400无法实现硬件加速，或者说是不完整的，他不能脱离pve显示独立输出，也不具备完整的加速功能。

lzp@lzps-iMac-Pro ~ % nvram -p | grep boot-args
boot-argskeepsyms=1 debug=0x100 amfi_get_out_of_my_way=1 ngfxgl=1 ngfxcompat=1 nvda_drv_vrl=1
lzp@lzps-iMac-Pro ~ % csrutil status
System Integrity Protection status: unknown (Custom Configuration).

Configuration:
Apple Internal: disabled
Kext Signing: disabled
Filesystem Protections: disabled
Debugging Restrictions: enabled
DTrace Restrictions: enabled
NVRAM Protections: enabled
BaseSystem Verification: enabled

This is an unsupported configuration, likely to break in the future and leave your machine in an unknown state.
lzp@lzps-iMac-Pro ~ %

核心原理： 由于 macOS Monterey 删除了对 Pascal 架构（P400）的原生支持，必须通过彻底关闭系统安全限制（SIP/AMFI）来强行注入旧版驱动补丁。

1. 解除系统安全锁定 (修改 config.plist)

使用 ProperTree 修改硬盘 EFI 分区中的 config.plist，确保以下参数准确无误：

A. 彻底禁用 SIP

路径：NVRAM -> Add -> 7C436110-AB2A-4BBB-A880-FE41995C9F82

键名： csr-active-config
修改值： EF0F0000 (Data 类型)
注：必须在 NVRAM -> Delete 下的对应 UUID 列表中包含 csr-active-config 字符串。

B. 注入启动参数

在同一路径下的 boot-args 中添加以下内容：

keepsyms=1 debug=0x100 amfi_get_out_of_my_way=1 ngfxgl=1 ngfxcompat=1 nvda_drv_vrl=1

C. 禁用安全启动

路径：Misc -> Security -> SecureBootModel

值： Disabled

2. 刷新 NVRAM (关键步骤)

1 保存并重启虚拟机。

2 在 OpenCore 引导图标界面，立即按下 空格键 弹出隐藏选单。

3 选择 Reset NVRAM 并回车。系统将自动重启以应用新的安全设置。

3. 执行 Root Patch 驱动注入

进入桌面后，如果 loginwindow 不再报错，即可进行最后的驱动安装：

打开 OpenCore Legacy Patcher.app。
点击 Post-Install Root Patch。
系统应识别到 Graphics: Nvidia Pascal。
点击 Start Root Patching，完成后按提示重启。

4. 故障排查汇总

故障现象	根本原因	解决方案
loginwindow 进程崩溃报告	SIP 或 AMFI 仍在拦截未签名驱动	确认 `csrutil status` 显示各分项均为 disabled
物理显示器黑屏无输出	驱动加载失败或 PVE 虚拟显卡冲突	关闭 PVE 虚拟显卡，仅保留直通的 P400 硬件
系统报告显示显存 7MB/14MB	Root Patch 补丁未成功写入内核	检查 SIP 值是否为 `EF0F0000` 并重新执行补丁

PVE 虚拟化环境黑苹果 Monterey 视觉化指南

Sat, 28 Feb 2026 20:01:24 GMT

本教程专为在 Proxmox VE (PVE) 虚拟化平台上运行 macOS Monterey 的黑苹果爱好者准备。侧重于抹平虚拟化延迟与压榨系统响应速度，不讨论纯视觉美化。

核心原则： 减少 CPU 指令模拟开销，优化磁盘 I/O 路径，彻底禁用宿主机不需要的 macOS 后台服务与冗余视觉动画。

一、存储与磁盘 I/O 优化

磁盘延迟是虚拟机“卡顿感”的主要来源。建议弃用 SATA 模拟，转向半虚拟化协议。

1. 选用 VirtIO Block / SCSI

推荐方案： 在 PVE 磁盘设置中选择 VirtIO Block。
优化配置： 开启 IO Thread（IO 线程隔离），避免大文件读写时系统 UI 假死。（也有很多人推荐不开）

2. 关键参数设置

参数	建议值	作用
Discard	开启 (Checked)	支持 TRIM，防止虚拟磁盘性能衰减
SSD Emulation	开启 (Checked)	让 macOS 按照固态硬盘逻辑优化文件布局
Cache	Write back	利用宿主机缓存提升写入响应感

二、内存底层优化

macOS 有自己的一套内存压缩和释放逻辑，与 PVE 的 Ballooning 极易冲突。在内存设置中取消勾选 “Ballooning Device”，分配固定内存。这能消除由于物理内存回收导致的随机系统瞬间冻结。

三、视觉减负：禁用系统动画

在没有完美显卡硬加速的情况下，macOS 的视觉特效是性能最大的杀手。通过终端强制关闭动画，可以瞬间提升窗口响应速度。

1. 开启“减弱动态效果”

前往 系统偏好设置 -> 辅助功能 -> 显示器，勾选 “减弱动态效果” (Reduce motion)等。这将取消大部分窗口切换时的平滑过渡。

2. 终端深度禁用指令

执行以下命令彻底消除窗口缩放和 Dock 栏动画：

# 禁用窗口打开和保存时的动画
defaults write NSGlobalDomain NSAutomaticWindowAnimationsEnabled -bool false

# 禁用快速预览 (Quick Look) 的过渡动画
defaults write NSGlobalDomain QLPanelAnimationDuration -float 0

# 调整 Dock 栏显示/隐藏的速度 (设为0即瞬开)
defaults write com.apple.dock autohide-time-modifier -float 0
defaults write com.apple.dock autohide-delay -float 0

# 重启 Dock 生效
killall Dock

四、 macOS 系统服务“大瘦身”

在 macOS 终端执行以下命令，关闭在虚拟机环境中无意义的资源消耗：

1. 禁用 Spotlight 索引 (磁盘 I/O 大户)

sudo mdutil -a -i off

2. 禁用休眠与睡眠

sudo pmset -a sleep 0; sudo pmset -a hibernatemode 0; sudo pmset -a disablesleep 1

3. 停止崩溃报告与系统日志

sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.syslogd.plist
sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.ReportCrash.Root.plist

模拟胜原生？R5-2600 虚拟黑苹果性能大对决：Skylake 模拟 vs Host 补丁方案跑分复盘

Fri, 27 Feb 2026 19:54:12 GMT

前言：折腾缘由与技术复盘

从几年前配合 GT 710 的初步尝试，到如今在 Proxmox VE (PVE) 9.1 环境下深度调优，这次复盘历时一周。本文将通过多组跑分数据，深入探讨模拟架构与原生补丁方案的性能差异。

一、硬件环境与实验配置

核心硬件： AMD Ryzen 5 2600 (6C/12T) | 16GB RAM (8G*2)
直通显卡： NVIDIA Quadro P400 (Pascal 架构)
系统平台： PVE 9.1
对比系统： macOS 12 (Monterey) vs macOS 13 (Ventura)

二、性能对决：跑分数据与原始报告

为了探究不同机型与引导对性能的影响，我使用了 Geekbench 6 进行了多轮测试。数据证明：Skylake 模拟架构配合现代机型定义，能最大程度释放物理 CPU 的性能。

机型 (SMBIOS)	系统版本	引导/CPU模式	单核/多核	原始报告
iMac19,1	macOS 13.7.8	LongQT / Skylake	1119 / 3357	查看报告
MacPro7,1	macOS 13.7.8	LongQT / Skylake	1096 / 3301	查看报告
iMac19,1	macOS 12.7.6	LongQT / Skylake	1112 / 3351	查看报告
iMacPro1,1	macOS 12.7.6	proxmox / R5-2600	1056 / 2916	查看报告
iMac19,1	macOS 12.7.6	proxmox / R5-2600	1032 / 2965	查看报告

三、关键技术分析：为什么模拟更强？

根据跑分反馈，LongQT (Skylake 模拟) 在多核性能上比原生补丁方案高出约 13%。这是因为：

内核适配： macOS 对 Intel Skylake 的拓扑识别极为成熟。
补丁开销： 原生 R5-2600 依赖大量的内核补丁来修复指令集不兼容，这在某种程度上损耗了 CPU 效率。
兼容性： 在 macOS 13 下，模拟架构的稳定性明显优于原生 host 模式。

四、显卡直通：Quadro P400 的驱动与体验

Quadro P400 (Pascal) 虽然无法通过 Metal 加速，但在 macOS 12/13 中通过 NVIDIA WebDrivers 注入后，可实现桌面渲染。相比 CPU 软渲染，它极大地提升了系统的交互流畅度，是黑苹果虚拟化中极具性价比的“亮机卡”。

AMD Ryzen 5 2600 + PVE 9.1：黑苹果虚拟机安装与 Quadro P400 直通实战总结

Thu, 26 Feb 2026 19:50:31 GMT

折腾缘由

这一切的起点要追溯到 OpenClaw 私人 AI 助理。几年前我曾在这台物理机上安装过黑苹果，当时配置还是 GT 710。今年春节前后，我花了大约一周时间重新钻研，对 OpenCore 和 KVM 的底层逻辑有了更深的理解。

最让我感到意外的是，上次尝试在 AMD 平台上直通显卡总是导致系统锁死，而这次居然顺利跑通了。这很可能得益于 PVE (Proxmox VE) 内核的迭代更新，对硬件直通（Passthrough）的兼容性显著增强。

实验环境概览

核心硬件/软件	详细参数
CPU	AMD Ryzen 5 2600 (Zen+)
GPU	NVIDIA Quadro P400 (Pascal)
内存	16GB (8GB x 2)
虚拟化平台	Proxmox VE 8.4 / 9.1

一、性能实测数据

系统版本差异： 不同版本系统分数差别不大，波动约为 1-3%。对比 macOS 12 (Monterey)，macOS 13 (Ventura) 表现略微胜出。
机型定义差异： SMBIOS 对性能有略微影响，幅度在 3-7%。在对比测试中，iMac19,1 的表现优于 MacPro7,1。

二、引导方案深度对比

在折腾过程中，我研究并对比了目前主流的几个虚拟化引导项目：

Penryn 补丁系： thenickdude 对 OpenCore 贡献的 PENRYN 补丁被广泛引用。opencore-osx-proxmox-vm 看起来是在其基础上进行的修改（补丁内容基本一致）。
Skylake 模拟系： LongQT-OpenCore 主要是基于 OpenCore 的 Sample 模板修改，未使用 PENRYN 补丁，而是采用 Skylake 架构模拟。
自定义尝试：
- 曾尝试基于原生 OpenCore 制作引导，但连 Logo 界面都无法进入。
- 尝试在 LongQT-OpenCore 基础上添加 AMD 内核补丁，结果能进引导但卡在 Logo 处。

核心发现： 不同引导对 args 参数的要求各异。例如：部分配置不需要 OSK 密钥也能启动，但必须严格指定处理器型号；基于 host 模式时，某些引导可以启动 macOS 12 但会在 macOS 13 上引导失败。

三、显卡直通研究：NVIDIA Quadro P400

Pascal 架构显卡的原生驱动支持止步于 High Sierra (10.13.6)。

经过实测证实：Quadro P400 在 macOS 12 和 13 中，通过 Nvidia’s WebDrivers 驱动注入后可以被系统识别。虽然由于缺乏 Metal 硬件加速支持，它并非“完美驱动”，但作为一张亮机卡，它的体感流畅度远超纯 CPU 软件渲染。至少在桌面环境下，操作响应非常丝滑。

四、特别推荐：参考资料链接

1. 核心文档（必读）

Dortania’s Getting Started：最基础也是最重要的文档，解决安装诸多疑难杂症。
LongQT-OpenCore ISO：重点推荐引导！ 安装过程建议遵循其示例文档。

2. 实用项目与教程

OSX-PROXMOX (Gabriel Luchina)：我的“首亮”参考，提供了非常棒的配置脚本思路。
thenickdude / OSX-KVM：强大的工具包，支持制作恢复镜像及完整镜像。
Nick Sherlock’s 教程：由 KVM-Opencore 作者亲自撰写的 Ventura 安装指南。

3. 进阶参考阅读

OpenCorePkg：一切引导的根源。
Kholia / OSX-KVM：针对 KVM 环境运行 macOS 的底层调优建议。
GPU Patching Guide & NVIDIA 不支持显卡列表。

amd处理器安装pve8时开通IOMMU分组

Wed, 11 Feb 2026 17:47:14 GMT

在 PVE 8 中，显卡（GPU）和网卡（NIC）被分在同一个 IOMMU 组是 AMD B450/X470 等主流平台非常常见的问题。这是因为主板的 PCIe 通道划分不够精细。要强行拆分它们，需要使用 ACS Override (Access Control Services) 补丁。这相当于告诉内核：“请假装这些设备是互相独立的”。

确认引导方式

在 PVE 命令行输入：
[ -d /sys/firmware/efi ] && echo "UEFI 引导" || echo "Legacy 引导"

如果显示 UEFI：需要进一步确认是使用 GRUB 还是 systemd-boot（PVE 8 默认 ZFS 安装通常用后者）。
执行 efibootmgr -v，如果看到 systemd-boot 字样，则是 systemd-boot；否则通常是 GRUB。

GRUB引导时的处理

nano /etc/default/grub

#找到并修改为
GRUB_CMDLINE_LINUX_DEFAULT="quiet amd_iommu=on iommu=pt pcie_acs_override=downstream,multifunction"

update-grub
reboot

修复exif因拍摄日期异常导致的时间断档

Wed, 21 Jan 2026 22:32:41 GMT

前言

由于照片移动不当，导致部分照片在时间线插队，即部分照片直接显示在移动操作的一天。为了更好的贴合原来的时间线，快速修改，拟定以下几种调整逻辑。其实就是按文件名，贴着有时间的修改日期。部分就只能指定了。

通过这种“逆/正序寻锚、逐个回溯”的逻辑能非常优雅地修复因拍摄日期异常导致的时间断档。

正序（跳开异常年份数据）

#!/bin/bash

# 1. 待修复文件完整路径列表
FILES=(
"/mnt/S50JW-PICT/ZSF/PHOTO/相机/201810 正序修改/IMG_8927.JPG"
"/mnt/S50JW-PICT/ZSF/PHOTO/相机/201810 正序修改/IMG_9129.JPG"
"/mnt/S50JW-PICT/ZSF/PHOTO/相机/201810 正序修改/IMG_9130.JPG"
"/mnt/S50JW-PICT/ZSF/PHOTO/相机/201810 正序修改/IMG_9131.JPG"
"/mnt/S50JW-PICT/ZSF/PHOTO/相机/201810 正序修改/IMG_9132.JPG"
"/mnt/S50JW-PICT/ZSF/PHOTO/相机/201810 正序修改/IMG_9133.JPG"
"/mnt/S50JW-PICT/ZSF/PHOTO/相机/201810 正序修改/IMG_9134.JPG"
"/mnt/S50JW-PICT/ZSF/PHOTO/相机/201810 正序修改/IMG_9135.JPG"
"/mnt/S50JW-PICT/ZSF/PHOTO/相机/201810 正序修改/IMG_9136.JPG"
"/mnt/S50JW-PICT/ZSF/PHOTO/相机/201810 正序修改/IMG_9137.JPG"
)

# 2. 确保路径列表按文件名正序排列 (从小到大)
IFS=$'\n' SORTED_FILES=($(sort <<< "${FILES[*]}")); unset IFS

echo "🚀 开始执行 [正序修改] 正序寻锚 (+30s) 修复..."

for fullpath in "${SORTED_FILES[@]}"; do
    [ ! -f "$fullpath" ] && continue

    dir=$(dirname "$fullpath")
    filename=$(basename "$fullpath")
    cd "$dir" || continue

    # 核心逻辑：寻找前序锚点 (编号比自己小、且不在待处理列表中或已修复完成的最近一张)
    # 使用 sort -r 反向排序，确保 awk 拿到的第一个就是最接近当前文件的小编号文件
    anchor_ref=$(ls | sort -r | awk -v cur="$filename" '$1 < cur' | while read -r p; do if [[ "$p" =~ ^IMG_[0-9]{4}\. ]]; then # 实时检查 EXIF 年份，确保非 2026 p_year=$(exiftool -s3 -DateTimeOriginal "$p" | cut -d: -f1) if [[ -n "$p_year" && "$p_year" != "2026" ]]; then echo "$p" break fi fi done | head -n 1) if [ -n "$anchor_ref" ]; then # 提取基准时间 ref_time_str=$(exiftool -d "%Y-%m-%d %H:%M:%S" -s3 -DateTimeOriginal "$anchor_ref") # 转换为时间戳并增加 30 秒 base_ts=$(date -d "${ref_time_str//:/-}" +%s 2>/dev/null || date -d "$ref_time_str" +%s)
        new_ts=$((base_ts + 30))
        
        new_time=$(date -d "@$new_ts" +"%Y:%m:%d %H:%M:%S")
        touch_time=$(date -d "@$new_ts" +"%Y%m%d%H%M.%S")

        echo "🔄 处理: $filename <- [锚点: $anchor_ref] | 修正为: $new_time"

        # 写入 EXIF (核心日期及作者标识)
        exiftool -overwrite_original \
            "-DateTimeOriginal=$new_time" \
            "-CreateDate=$new_time" \
            "-ModifyDate=$new_time" \
            -Artist="Manual" \
            -Author="Manual" \
            "$filename"

        # 同步文件系统的修改日期
        touch -t "$touch_time" "$filename"
    else
        echo "⚠️ 警告: $filename 之前找不到有效的参考锚点，已跳过。"
    fi
done

echo "✨ [正序修改] 系列修复任务全部完成！"

逆序（跳开异常年份数据）

#!/bin/bash

# 1. 待修复文件列表
FILES=(
"/mnt/S50JW-PICT/ZSF/PHOTO/相机/201809 逆序修改/IMG_8896.JPG"
"/mnt/S50JW-PICT/ZSF/PHOTO/相机/201809 逆序修改/IMG_8895.JPG"
"/mnt/S50JW-PICT/ZSF/PHOTO/相机/201809 逆序修改/IMG_8889.JPG"
"/mnt/S50JW-PICT/ZSF/PHOTO/相机/201809 逆序修改/IMG_8888.JPG"
"/mnt/S50JW-PICT/ZSF/PHOTO/相机/201809 逆序修改/IMG_8887.JPG"
"/mnt/S50JW-PICT/ZSF/PHOTO/相机/201809 逆序修改/IMG_8886.JPG"
"/mnt/S50JW-PICT/ZSF/PHOTO/相机/201809 逆序修改/IMG_8885.JPG"
"/mnt/S50JW-PICT/ZSF/PHOTO/相机/201809 逆序修改/IMG_8882.JPG"
"/mnt/S50JW-PICT/ZSF/PHOTO/相机/201809 逆序修改/IMG_8878.JPG"
"/mnt/S50JW-PICT/ZSF/PHOTO/相机/201809 逆序修改/IMG_8877.JPG"
)

# 2. 确保列表按文件名从大到小排列 (逆序处理)
IFS=$'\n' SORTED_FILES=($(sort -r <<< "${FILES[*]}")); unset IFS echo "开始执行 [逆序修改] 系列逆序寻锚修复..." for fullpath in "${SORTED_FILES[@]}"; do [ ! -f "$fullpath" ] && continue dir=$(dirname "$fullpath") filename=$(basename "$fullpath") cd "$dir" || continue # 核心逻辑：寻找后置锚点 # 规则：编号比自己大 ($1 > cur)、年份非 2026 的最近一张正确照片
    next_ref=$(ls | sort | awk -v cur="$filename" '$1 > cur' | while read -r p; do
        if [[ "$p" =~ ^IMG_[0-9]{4}\. ]]; then
            # 检查 EXIF 年份是否已修复（非 2026）
            p_year=$(exiftool -s3 -DateTimeOriginal "$p" | cut -d: -f1)
            if [[ -n "$p_year" && "$p_year" != "2026" ]]; then
                echo "$p"
                break
            fi
        fi
    done | head -n 1)

    if [ -n "$next_ref" ]; then
        # 提取锚点时间
        ref_time_str=$(exiftool -d "%Y-%m-%d %H:%M:%S" -s3 -DateTimeOriginal "$next_ref")
        
        # 将 EXIF 时间转为系统秒级时间戳并减去 30 秒
        base_ts=$(date -d "${ref_time_str//:/-}" +%s 2>/dev/null || date -d "$ref_time_str" +%s)
        new_ts=$((base_ts - 30))
        
        new_time=$(date -d "@$new_ts" +"%Y:%m:%d %H:%M:%S")
        touch_time=$(date -d "@$new_ts" +"%Y%m%d%H%M.%S")

        echo "🔄 修正: $filename <- [锚点: $next_ref] | 新时间: $new_time"

        # 写入 EXIF
        exiftool -overwrite_original \
            "-DateTimeOriginal=$new_time" \
            "-CreateDate=$new_time" \
            "-ModifyDate=$new_time" \
            -Artist="Manual" \
            -Author="Manual" \
            "$filename"

        # 同步系统修改时间
        touch -t "$touch_time" "$filename"
    else
        echo "⚠️ 警告: $filename 右侧找不到有效的参考锚点，跳过。"
    fi
done

echo "✨ [逆序修改] 目录处理完毕！"

特定日期修改

# 1. 定义待处理文件路径
file1="/mnt/S50JW-PICT/ZSF/PHOTO/相机/201802 在家/DWHI5806.jpg"
file2="/mnt/S50JW-PICT/ZSF/PHOTO/相机/201802 在家/WLZI0220.jpg"

# 2. 批量执行修改
for f in "$file1" "$file2"; do
    if [ -f "$f" ]; then
        echo "正在处理特殊命名文件: $(basename "$f")"
        
        # 写入 EXIF 核心日期及作者信息
        exiftool -overwrite_original \
            -Artist="Manual" \
            -Author="Manual" \
            -DateTimeOriginal="2018:02:17 20:10:00" \
            -CreateDate="2018:02:17 20:10:00" \
            -ModifyDate="2018:02:17 20:10:00" \
            "$f"
        
        # 同步文件系统时间 (touch 格式: YYYYMMDDhhmm.ss)
        touch -t 201802172010.00 "$f"
        
        echo "✅ $(basename "$f") 修复完成"
    else
        echo "❌ 未找到文件: $f"
    fi
done

正序（均为同年或不便排除异常）

#!/bin/bash

# 1. 待修复文件完整路径列表
FILES=(
"/mnt/S50JW-PICT/ZSF/PHOTO/相机/201911 同年正序修改/IMG_4350.JPG"
"/mnt/S50JW-PICT/ZSF/PHOTO/相机/201911 同年正序修改/IMG_4351.JPG"
"/mnt/S50JW-PICT/ZSF/PHOTO/相机/201911 同年正序修改/IMG_4352.JPG"
"/mnt/S50JW-PICT/ZSF/PHOTO/相机/201911 同年正序修改/IMG_4353.JPG"
"/mnt/S50JW-PICT/ZSF/PHOTO/相机/201911 同年正序修改/IMG_4354.JPG"
"/mnt/S50JW-PICT/ZSF/PHOTO/相机/201911 同年正序修改/IMG_4355.JPG"
)

# 2. 确保路径列表按文件名正序排列 (从小到大)
IFS=$'\n' SORTED_FILES=($(sort <<< "${FILES[*]}")); unset IFS

echo "🚀 开始执行 [同年正序修改] 正序寻锚 (+30s) 修复..."

for fullpath in "${SORTED_FILES[@]}"; do
    [ ! -f "$fullpath" ] && continue

    dir=$(dirname "$fullpath")
    filename=$(basename "$fullpath")
    cd "$dir" || continue

    # 核心逻辑：寻找前序锚点 (编号比自己小、且不在待处理列表中或已修复完成的最近一张)
    # 通过 exiftool 实时检查年份，确保锚点是“正确”的
    anchor_ref=$(ls | sort -r | awk -v cur="$filename" '$1 < cur' | while read -r p; do if [[ "$p" =~ ^IMG_[0-9]{4}\. ]]; then # 实时检查 EXIF 年份，非 2026 视为正确锚点 p_year=$(exiftool -s3 -DateTimeOriginal "$p" | cut -d: -f1) if [[ -n "$p_year" && "$p_year" != "2026" ]]; then echo "$p" break fi fi done | head -n 1) if [ -n "$anchor_ref" ]; then # 提取基准时间 ref_time_str=$(exiftool -d "%Y-%m-%d %H:%M:%S" -s3 -DateTimeOriginal "$anchor_ref") # 转换为时间戳并增加 30 秒 base_ts=$(date -d "${ref_time_str//:/-}" +%s 2>/dev/null || date -d "$ref_time_str" +%s)
        new_ts=$((base_ts + 30))
        
        new_time=$(date -d "@$new_ts" +"%Y:%m:%d %H:%M:%S")
        touch_time=$(date -d "@$new_ts" +"%Y%m%d%H%M.%S")

        echo "🔄 处理: $filename <- [锚点: $anchor_ref] | 修正为: $new_time"

        # 写入 EXIF (拍摄时间、创建时间及作者标识)
        exiftool -overwrite_original \
            "-DateTimeOriginal=$new_time" \
            "-CreateDate=$new_time" \
            "-ModifyDate=$new_time" \
            -Artist="Manual" \
            -Author="Manual" \
            "$filename"

        # 同步文件系统的修改日期
        touch -t "$touch_time" "$filename"
    else
        echo "⚠️ 警告: $filename 之前找不到有效的参考锚点（或全是 2026 年文件），已跳过。"
    fi
done

echo "✨ [同年正序修改] 链式修复任务完成！"

机械磁盘SMART信息及sata线材稳定性测试

Mon, 05 Jan 2026 17:23:03 GMT

核心健康指标

05 (Reallocated Sector Ct)—— 头号杀手
硬盘发现某个扇区坏了，会自动从“备用仓库”里拿一个好的扇区来替换它。RAW 值必须为 0。如果这个值大于 0 且在持续增加，说明盘片正在物理脱落或磁头已经划伤盘片。

197 (Current Pending Sector) —— 逻辑坏道与物理坏道的交界
磁头读到这里时发现读不出来，系统把它标记为“待观察”。它还没被正式判定为坏死。RAW 值最好为 0。如果大于 0，可以尝试通过全盘写零（dd）修复。如果写零后它变成了 ID 5，那是物理坏道；如果写零后它归零且 ID 5 没涨，说明是逻辑坏道（电荷干扰）。

187 (Reported Uncorrect) —— 性能预警
磁头尝试了所有纠错手段（ECC）后依然无法读出的数据。RAW 值应为 0。哪怕只有 1 或 2，也说明这块盘读取极不稳定，随时可能导致系统 IO 卡死（IO Delay 爆表）。

199 (UDMA_CRC_Error_Count) ——连接稳定性
如果这个值很大，只要它不涨，硬盘就是安全的。如果它正在涨，说明 SATA 线坏了。

7(Seek_Error_Rate) —— 机械结构健康度
磁头定位到目标轨道的准确率。对于希捷（Seagate）盘，这个数值很大是正常的；但对于西部数据（WD）或东芝（Toshiba），这个值必须为 0。

188 (Command_Timeout) —— 通讯历史
硬盘曾因响应太慢导致超时。这通常与供电不足或上述的 SATA 线材问题共同导致

198 (Offline Uncorrectable) —— 不可修复的扇区错误。

针对线材可能故障的检查

短自检（Short Self-test）

#这种测试主要检查硬盘的磁头读写功能、伺服电路以及盘片的一小部分区域，大约需要 1-2 分钟。
smartctl -t short /dev/sdX


#在 1 分钟后运行以下命令：
smartctl -l selftest /dev/sdd

如果显示 “Completed without error”：说明磁头和电路基本功能正常。
如果显示 “Completed: read failure”：说明磁头撞到了读不出来的点。

再次检查属性值 (Attributes)：自检结束后，再次运行 smartctl -a /dev/sdd，对比以下数值：
ID 187 (Reported_Uncorrect)：是否变成了更大的数字？
ID 197 (Current_Pending_Sector)：是否从 0 变成了非 0？（如果变了，说明刚才的自检扫出了新坏道）。
ID 199 (UDMA_CRC_Error_Count)：如果你在自检期间没动过线材，这个值不应该增加。如果增加了，说明你的 SATA 线已经烂到连简单的指令传输都会丢包。

稳定性测试

#记录原始值
smartctl -a /dev/sdX | grep UDMA_CRC

# 连续读取这块盘的前 20GB 数据，看是否会触发 CRC 增加
dd if=/dev/sdX of=/dev/null bs=1M count=20480 status=progress

#再次验证是否有增加，不增加则稳定
smartctl -a /dev/sdX | grep UDMA_CRC

解决Ubuntu20.04server安装xfce桌面后XRDP访问黑屏退出

Wed, 05 Nov 2025 02:51:39 GMT

创建或修改用户 .xsession 文件

每个通过 xrdp 登录的用户，需要指定默认会话：

echo "startxfce4" > ~/.xsession
chmod +x ~/.xsession

再次连接可以了。

Ubuntu22配置WireGuard客户端

Sun, 17 Aug 2025 23:45:31 GMT

安装

sudo apt install wireguard -y

配置文件

配置文件放到 /etc/wireguard/ 下，比如 /etc/wireguard/wg0.conf

sudo nano /etc/wireguard/wg0.conf


[Interface]
PrivateKey = xx
Address = 10.0.0.12/24

[Peer]
PublicKey = xx
Endpoint = web.pp.com:10001
AllowedIPs = 10.0.0.0/24, 172.16.31.64/26, 172.16.20.224/27
PersistentKeepalive = 30

#配置里写了 AllowedIPs = 0.0.0.0/0，那么所有流量都会走 wg0。如果只写了内网网段（比如 10.0.0.0/24），那么只有访问那个网段时才会走 WireGuard。

启停

启动连接
sudo wg-quick up wg0

断开连接
sudo wg-quick down wg0

开机自动启动
sudo systemctl enable wg-quick@wg0

查看更多

sudo wg show

interface: wg0
  public key: xx
  private key: (hidden)
  listening port: 36361

peer: xx
  endpoint: xxx:10001
  allowed ips: 10.0.0.0/24, 172.16.31.64/26, 172.16.20.224/27
  latest handshake: 33 seconds ago
  transfer: 2.81 MiB received, 194.58 KiB sent
  persistent keepalive: every 30 seconds