之前的帖子中曾写到，编译最新版本的hived(v1.26.0rc3)，需要Ubuntu 20.04 LTS及以上版本。于是把平时编译用的VPS升级到了Ubuntu 20.04 LTS。
然后编译hived的最新版本，总算可以成功编译了，不过拿到我本地机器上(Ubuntu 18.04 LTS)执行，却被提示如下问题：
./hived_v1.26.0.rc3: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required by ./hived_v1.26.0.rc3)
通过如下指令可以查看支持的GLIBC版本
strings /lib/x86_64-linux-gnu/libm.so.6 | grep GLIBC_
显示如下：
也就是说使用高版本GLIBC编译的程序，无法在低版本GLIBC上设备上执行。
升级目标设备上的GLIBC版本应该可以解决这个问题。不过需要编译glibc，比较麻烦，也可能会引进新的问题。所以决定升级目标机器的Ubuntu版本。
按着最稳妥的做法，升级之前应该沐浴更衣焚香祷告，以免出故障。不过为了节省时间，我就简单的把房间地面用洗地机洗一遍，自己洗了洗手。
然后就是关闭机器上当前正在运行的程序，包括hived(这次记得了备份/dev/shm中的shared_memory.bin到文件目录），更新系统以及软件包等等，重启系统。
原本打算连接键盘，显示器，鼠标等外设后，安全地升级物理机。不过因为之前为了省电，把主机的显卡拔掉了（也不知道是否真省电），所以如果连接外设升级，还要拆机接显卡，实在是太麻烦了。
于是决定直接在SSH里操作，万一出问题了再连显示器等外设去解决（虽然这样风险比较高，不过懒惰的我决定不管那些了）。
直接执行do-release-upgrade，一路确定，好在升级没出啥问题，很是顺畅。
升级过程中会遇到一些选择界面，如果这时候SSH卡了，就惨了：
经过漫长的等待，总算升级完成，重启：
重启后测试了电脑上的老版本hived（v1.25.0)以及新版本hived(v1.26.0rc3)。发现老版本可以正常使用，新版本可以正常打印版本信息hived_v1.26.0.rc3 --version：
"version":{"blockchain_version":"1.26.0","hive_revision":"64f7389128f3c1a59f2c8107509d5f6de37aa2d9","fc_revision":"64f7389128f3c1a59f2c8107509d5f6de37aa2d9"}
电脑上其它程序（不包含虚拟环境下的内容），目测也正常执行。
这时我有点上头了，既然Ubuntu 20.04 LTS升级如此顺利，程序执行起来也没啥问题，那么想必升级到Ubuntu 22.04 LTS也应该不会出啥问题。
重启电脑，SSH登录后，会看到如下提示信息：
New release '22.04.1 LTS' available.
Run 'do-release-upgrade' to upgrade to it.
升级过程和从Ubuntu 18.04 LTS升级到Ubuntu 20.04 LTS大同小异，过程就不再赘述了。升级完成，重启后登录：
不过我本地的EOS命令行钱包cleos无法使用了，提示如下信息：
cleos: error while loading shared libraries: libssl.so.1.1: cannot open shared object file: No such file or directory
哎，明明Ubuntu 20.04 LTS下，一切都好用，我为啥要折腾呢？呜呜呜呜呜呜。这个不急，以后慢慢折腾吧。
好消息是，hived（v1.25.0)以及新版本hived(v1.26.0rc3)都可以在Ubuntu 20.04 LTS正常运行，毕竟我主要就是要跑hived以及测试新版本hived，所以这个结果不算太坏吧。
升级到新版，带来的另外一个问题就是机器上在运行的虚拟环境virtualenv下的脚本都无法执行了。
执行python指令（或者随便运行一个脚本），都会出现诸如下边的提示：
这个是正常的，升级到Ubuntu 20.04 TLS 也会遇到，毕竟python的版本变了，所以需要更新一下。不过我机器上这样环境比较多，脚本也比较混乱，够我修一阵的啦。
看来以后做事情要规范一些，就不至于如此混乱了。不过生命就是在于折腾嘛，制造一些麻烦，然后再去解决麻烦，这样才有趣，不是嘛？（呜呜呜呜呜呜呜😭）
PS: 补充个坏消息，貌似我写的Python库，有部分功能也没法用啦，正在DEBUG中。
