fdisk本身不修复分区表，仅写入手动指定结构；真正修复需已知原始起始扇区、大小和类型，否则易致数据不可访问，故应先用parted -l、gdisk -l、cat /proc/partitions交叉验证损坏层级，并优先选用testdisk扫描恢复。
分区表损坏本身不产生修复日志
Linux内核和分区工具（fdisk、parted、testdisk）在检测或修复分区表时，**不会写入专门的“分区表修复日志”文件**。所谓“修复日志”，实际是分散在几个地方的诊断线索，需主动抓取和交叉比对。
关键诊断命令输出就是你的“日志”
分区表损坏的痕迹藏在命令执行的即时输出里，不是事后翻文件。重点看以下三类输出：
-
sudo fdisk -l /dev/sdX：若报Unable to open /dev/sdX或输出为空/只有 Disk header 行，说明分区表无法解析；出现Partition table entries are not in disk order是典型 MBR 错序 -
sudo parted /dev/sdX print：若提示Error: /dev/sdX: unrecognised disk label或Partition Table: unknown，基本确认分区表头损坏 -
sudo gdisk -l /dev/sdX：GPT 盘的关键判断依据——输出含Found invalid GPT and valid MBR或Found invalid GPT and invalid MBR时，才是真损坏；仅Warning: Not all of the space available to /dev/sdX is used属于正常提醒
/var/log/syslog 和 dmesg 里藏硬件级线索
分区表损坏常伴随底层读取异常，内核会在启动或首次访问时记录原始错误：
-
dmesg | grep -i "sda\|partition"：找类似end_request: I/O error, dev sda, sector 0或Failed to read partition table的行——sector 0 出错几乎等于 MBR 损毁 -
grep -i "partition\|GPT\|MBR" /var/log/syslog：系统服务（如 udev、systemd）加载失败时可能留下failed to scan partitions或ignoring invalid partition table - 注意时间戳：这些日志集中在磁盘首次被探测时（通常是开机或热插拔后几秒），不是你运行
testdisk之后才写入
testdisk 运行时的交互过程就是操作日志
testdisk 不生成外部日志文件，但它的每一步选择和扫描结果就是最可靠的修复过程记录：
- 启动后显示的
Selected disk /dev/sdX和Geometry from BIOS值，决定了它如何解读扇区布局 -
Quick Search找到分区后按P预览目录——能列出文件就说明分区边界推断正确；全空或乱码则说明签名匹配失败 - 执行
Write前，它会打印将要写入的分区起始/结束扇区（如Partition Start End Size行），**务必抄下来**——这是唯一可回溯的“修复参数”
真正容易被忽略的是：分区表损坏的修复没有“成功日志”，只有验证动作。写完必须立刻跑 sudo partprobe /dev/sdX + lsblk 看 sda1 是否重现，否则一切输出都只是推测。
