一次Hyper-V和Azure平台设备无法启动的问题调试过程

最近一个客户报bug说升级新版本失败，由于版本跨度较大，我们首先怀疑是由于配置不兼容导致的，拿到用户的配置后开始尝试复现，无奈实验室环境无法复现。
由于客户环境是hyper-v环境，想着自己老是自己闷头尝试也不是办法，于是请求客户把环境中的vm备份成快照，然后把快照传过来，问题得以复现。happy
于是采用最直接的办法，在系统升级流程中加入详细的调试，看看卡在了哪个地方。
根据调试信息，系统启动后卡在了硬盘扫描的地方，细化调试信息，发现设备会调用libblkid的API 时卡住了，Google了一下，该库是用来探测块设备的，我们直接用的linux的标准库，如果要想获取进一步的信息，为什么卡住，还有下载源代码，进一步调试。
这个时候我开始想标准库应该不会卡主，这个是个常用的库，看了下用法也没有逻辑错误，于是开始怀疑是不是我们自己的代码出现了问题。
这个时候有2个思路：
1，系统启动卡住的时候，kernel已经启动完毕，目前正在启动应用程序，会不会是某个应用程序导致了库接口卡住？
2，进行版本回溯，看下哪个版本开始卡住的，再来分析改版本新提交的代码，进行问题排查。
衡量了一下，第一个思路比较容易些，于是我把接口加入到卡住的代码之前，多次调用，查看从哪个地方开始卡住的。
经过定位，确定了该问题确实是某个应用卡住的，新版本中某个同事加入了CPU-offline 功能导致了该问题。
我们知道Linux 支持CPU核心热插拔（上/下线）功能，除了CPU0外，可以通