我将 Debian（2019 年最新版本）安装到 AMD 64 计算机上，运行 8 GB 内存和 128 GB SSD 磁盘。从那时起，BIOS 就变得非常慢，并且计算机挂在那里，几乎不可能安装另一个操作系统。有人认识到与此类似的问题吗？
答案1
如果这是服务器级系统，或者 BIOS 包含一项将 BIOS 和引导加载程序输入/输出重定向到串行端口（可以是真实端口，也可以是 iLO/iLOM/IRMC/DRAC/等远程控制台处理器）的功能。 ），然后激活该功能但不指定高串行端口速度可能会导致这种缓慢。如果为启用了硬件握手的真实串行端口激活了此类功能，但实际上没有任何连接到该端口，则缺少握手信号甚至可能导致输出完全停止，直到达到超时。
重新加载 BIOS 默认值可能会禁用重定向功能，从而使一切恢复正常，符合您的体验。
通常，BIOS 实用程序菜单的设计假设屏幕重绘基本上是即时的。但如果 VGA 文本模式输出重定向到以 9600 bps 速度工作的串行端口，则该假设将非常不真实。
使用虚拟串行端口时，使用最高常用串行传输速度 115200 bps 通常不是问题，但某些远程控制台处理器可能存在限制。但即使在我见过的最慢的虚拟串行端口实现中，也可以达到 38400 bps 的速度。
9600 bps 和 115200 bps 之间的差异足以将 BIOS 实用程序访问从“它是否挂起或只是非常慢？”改变。到“可用但有点慢”。
具有远程控制台处理器的旧系统可能需要 Java 来实现 KVM 远程控制台功能，由于新 Java JRE 包的安全要求，这可能会很麻烦。较新的远程控制台处理器已开始提供基于 HTML5 的 KVM 远程控制台，不再需要 Java。
许多远程控制台处理器还将支持基于 SSH 字符的连接和虚拟串行端口。由于 Linux TTY 设备本质上是串行端口或其仿真，因此可以轻松地将 Linux 配置为使用串行端口作为其控制台设备，这非常适合提供此类访问的远程控制台处理器。即使在主网络接口出现问题或配置错误的情况下，这也允许对系统进行强大的、无需 Java 的管理访问。
但 Linux 控制台访问仅在内核启动后才起作用 - 并且访问 Linux 引导加载程序以指定内核的引导参数可能是故障排除的重要部分。为了解决这个问题，引导加载程序还必须可以通过虚拟串行端口访问。这可以通过以下两种方式之一完成：通过显式配置引导加载程序以使用串行端口（GRUB 有相应的功能）或通过激活 BIOS 文本模式 I/O 重定向到串行端口（如果此类功能可用） 。后一个选项还将向基于串行的远程控制台提供 BIOS 启动消息，这在出现硬件问题时非常有用。
某些 HP 系统允许将 BIOS 实用程序菜单切换为命令行模式以进行低速访问，这也可能有所帮助。但您必须在激活 KVM I/O 重定向到串行端口之前执行此操作。
答案2
等待了20分钟后，BIOS实用程序终于启动了。我加载了 Bios Defaults，重新安排了启动顺序，终于能够再次控制机器。希望这对某人有帮助。