内核初始化过程中崩溃的罪魁祸首是什么？
我正在运行一个拥有initramfs的内核，inittab是非常基本的rcS（如sysinit）和getty（respawn）。在启动时我没有收到任何错误消息，但是init给了我这条消息： S0重新生成太快：禁用5分钟，其中S0实际上是respawn :: getty行（似乎getty保持崩溃），也没有在控制台上看到rcS生成的消息（我假设rcS命令也是crashe）。
如果我强制内核转到/ bin / sh（而不是/ init）我可以手动调用rcS并且我没有错误，getty也是如此（如果我使用inittab中的相同参数调用getty它工作正常）。
我想知道init生成进程的方式和/ bin / sh的方式有什么区别。
答案 0 :(得分：0)
某些操作系统的日志初始化重新生成wtmp，您可能需要在那里查看。打开你的系统日志也可能会有所帮助。
当您通过/ bin / sh启动getty时，它是否继续运行？ AFAIK，init respawn的技巧是它生成的PID被监视，如果它关闭，它将启动另一个。
答案 1 :(得分：0)
stock / bin / sh不是静态的，也不是getty。你需要看一下 / bin / sh和getty的共享库依赖关系，所有库都存在。
您可以使用ldd或'readelf -a'查看共享库依赖项。
答案 2 :(得分：0)
可能没有设置/dev/tty1，/dev/tty2等，但是/dev/console上的内容正常运行（这与/dev/tty1不同）。如果您依赖于initramfs或根文件系统中的/ dev目录，请检查这些目录。
可能init = / bin / sh和让init产生的东西之间的主要区别是/dev/console与/dev/ttyx。我想不出任何其他相关的东西。请记住，我认为initramfs确实首先运行。
顺便说一下，如果init（8）或/bin/sh可以运行，你显然已经超过了内核初始阶段。