上文core node 遭遇分叉(fork)的问题无法启动正在修复中，出块时间又逼近。决定冒险执行 core 的迁移。
原本升级迁移的也在计划中，只是这次遇到情况提前了。万幸手边设备是就绪的，除了故障的core以外内网还有3个可用的relay在正常备选。
选之前众筹拿到的 r86s，配置16G RAM 和 128 eMMC+ 500G SSD 较高，应付将来 cardano-node 升级要求提高还有充分的冗余。
至少需要2台节点设备，建议3台。
建议有1 core 2 relay 3台，因为 迁移 relay至少得停掉其中2台，重启后如果没有relay保持在线，外部检测会认为你的pool完全脱机。
遭遇节点自动重启后长期处于 starting 状态（1个小时以上）
检查日志
cd $CNODE_HOME/logs
tail -f node0.json
发现正在验证区块
{"host":"cnoder86","pid":"3127081","loc":null,"at":"2022-04-04T03:43:18.66Z","ns":["cardano.node.ChainDB"],"sev":"Info","env":"1.34.1:73f9a","data":{"kind":"TraceImmutableDBEvent.ValidatedChunk","chunkNo":"2171"},"msg":"","thread":"5","app":[]}在社区资讯过大佬们，答曰是一些 dirty data 造成的。或许是异常的重启或者来自分叉的节点的干扰数据。
无他，是节点的自纠和保护机制
如果赶时间又自信数据没有问题，可以用逃课的办法跳过这个自检：
cd $CNODE_HOME/db
touch clean
systemctl restart cnode
简单的说, 就是在 db 路径下新建一个名为clean的空文件。节点启动的时候检查到有这个文件就会跳过自检。
但以上方法慎用，当你无法保证数据正确完整的时候跳过自检可能导致自己的chain db 进入错误的分叉，下文详述。
-待续-
备忘，因为经常忘记
用途略，在有 limit 时同时返回相关的总行数， 便于计算管理分页。
两行已经概括完主要的用法。返回第2页（每页20条）的结果。
SELECT SQL_CALC_FOUND_ROWS * FROM airdroplog LIMIT 20,20;
SELECT FOUND_ROWS() as `rows`;
补充说明： LIMIT 的参数 offset值不会影响 found_rows() 返回的值。请求跳过前 100， 与从 0 开始算， 返回的 found_rows 值是一致的。
给R86S灌系统的时候nvme硬盘还没发货，所以系统先装在内建的 EMMC上，到货之后才加装，备忘本文。
（正常流程可以在安装ubuntu的时候顺便做分区格式化）
以标题同名关键词搜索 google 已经得到精炼的步骤指引：
ubuntu20.04挂载硬盘
- 通过df -h 查看现磁盘使用情况
- 通过fdisk -l查看电脑挂载的硬盘 ...
- 删除原硬盘分区，执行fdisk /dev/sdb，输入d，然后根据提示输入对应分区号即可
- 将清除分区的硬盘格式化为ext4格式，执行命令mkfs.ext4 /dev/sdb.
按上述流程操作个大概，以下是部分要点补充