阿里云自定义镜像启动 ECS 卡死在启动中的奇怪问题，不知道有没有人遇到过？

[lin_toto]

我们有一个用来弹性伸缩的自定义镜像，之前一直用着没问题，6 月底一天开始突然这个镜像起机器就会卡在启动中非常久，一般都要 15-20 分钟才能起得来。

进了系统之后看 dmesg，log 显示只有这 20 分钟的最后几秒是在启动内核，前面的时间完全不知道发生了什么，难道还能卡在 grub 吗。。卡着的时候用控制台那个远程连接也连不上

但是我们其他的镜像又都正常，只有这个镜像起机器会卡，也重做过了还是没有改善，想请教一下有没有什么排查的思路（又或者是阿里云抽风），感谢各位

[coolloves]

ecs 好像可以远程链接过去,直接看启动过程

[HuasLeung]

是哪种类型的镜像，信息有点少

[lin_toto]

@coolloves 启动中的远程连接用不了

@HuasLeung 基于 Debian 10 的镜像，基本上就是个系统加上自己的业务代码，没有对系统底层做什么修改。

也在阿里云那开了个工单，可是感觉他们客服很不专业，基本不指望他们能解决

[laozhoubuluo]

因 systemd 在系统启动时需要熵信息，且内核在可用熵较少时会阻塞相应的调用，所以系统启动时可能挂起数分钟至数小时，直至随机子系统充分得到初始化（ random: crng init done ）。对于支持 RDRAND 指令的 amd64 系统，Debian 的内核已可以避免这个问题，因为内核默认将尝试使用该指令（ CONFIG_RANDOM_TRUST_CPU ）。

非 amd64 架构的系统和某些虚拟机可能需要从其它来源获取熵以保证快速启动。Debian 安装程序内部选择了 haveged 作为替代方案，在硬件熵不可用时，这可能是个可以使用的解决方案。在虚拟机上，请考虑经由 virtio_rng 将主机的熵转发至虚拟机中。

如果您在阅读本篇文档之前已将远程的系统升级至 buster，请考虑经由网络持续 ping 远程系统，这样做可以向系统的随机池中添加熵，并最终使得系统可以重新通过 ssh 登录。

请参见维基( https://wiki.debian.org/BoottimeEntropyStarvation)以及 DLange 对此问题的简述( https://daniel-lange.com/archives/152-hello-buster.html)以了解其它解决方法。

https://www.debian.org/releases/buster/amd64/release-notes/ch-information.zh-cn.html#entropy-starvation

[holinhot]

同自定义镜像，正常启动没问题，但单用户模式启动就卡 crng init done