我正在尝试解决在 Devuan ASCII 下运行的 Sun Ultra 24 Workstation 的一个令人讨厌的关机问题。
groucho@devuan:~$ inxi -b
System: Host: devuan Kernel: 4.9.0-8-amd64 x86_64 (64 bit) Desktop: Xfce 4.12.3
Distro: Devuan GNU/Linux ascii
Machine: Device: portable System: Sun Microsystems product: Ultra 24 v: 0.00.01
Mobo: Sun Microsystems model: Ultra 24 v: 50 BIOS: American Megatrends v: 1.56 date: 01/21/2011
--- snip ---
groucho@devuan:~$
显然它不是一个便携式系统。只是这个 BIOS 文件是在 2010 年 1 月（Sun 倒闭的日期）之后发布的。
groucho@devuan:~$ uname -a
Linux devuan 4.9.0-8-amd64 #1 SMP Debian 4.9.144-3.1 (2019-02-19) x86_64 GNU/Linux
groucho@devuan:~$
这似乎是一个与分布无关的问题。它也发生在与紧急 TCore Linux 相同的设备上，我在启动时可以通过 F8 访问记忆棒上的紧急 TCore Linux。
我不知道它是否会发生在 MSOS 安装中，因为我没有，只有一台运行 XP 的虚拟机来测试东西。
这个问题基本上是这样的：
关闭时，机器将执行以下两项操作之一：
- 正确关闭
- 此时关机期间冻结...
e1000e: EEE Tx LPI Timer
Preparing to enter sleep state S5
Reboot: Power Down
...风扇全速吹。
最初，这是一个由两部分组成的问题：第一部分是关机时重新启动问题，但（显然）通过禁用 WoL 解决了这个问题，并且没有再次发生。
第二部分（像第一部分一样）以完全不可预测的方式发生，我无法复制它或将其链接到任何特定的东西。
除了禁用 WoL（有点麻烦，因为它无法通过 BIOS 完成）之外，我还禁用了 Intel e1000e 控制器的 EEE 设置，但没有效果。
在关机时使用脚本卸载 e1000e 驱动程序模块或在内核命令行中插入各种 restart= 节也不起作用。即：reboot=force、reboot=acpi、reboot=BIOS 等。
为了尝试了解正在发生的情况，我决定使用一个脚本关闭设备，该脚本（希望）隔离关闭过程的每个阶段，并且（也许）在终端给我一些反馈，很多就像我在 MS-DOS 时代所做的那样，通过逐步运行 config.sys 和 autoexec.bat 来消除启动问题：
#!/bin/sh
#Shut down system without the use of shutdown helper
#
PATH=/sbin:/bin:/usr/sbin:/usr/bin:
for i in s u o; do echo $i | sudo tee /proc/sysrq-trigger; sleep 2; done # halt
但不，在多次关闭之后，它最终再次发生，这就是我在屏幕上看到的：
s
u
sudo: unable to open log file: /var/log/sudo.log: read only file system
...风扇全速吹。
当我没有遇到关闭冻结时，var/log/messages 将始终文件读取：
Mar 8 09:37:16 devuan kernel: [ 8831.030260] sysrq: SysRq : Emergency Sync
Mar 8 09:37:16 devuan kernel: [ 8831.051494] Emergency Sync complete
Mar 8 09:37:18 devuan kernel: [ 8833.038247] sysrq: SysRq : Emergency Remount R/O
Mar 8 09:37:18 devuan kernel: [ 8833.069992] EXT4-fs (sdb1): re-mounted. Opts: (null)
Mar 8 09:37:18 devuan kernel: [ 8833.139131] EXT4-fs (sdb6): re-mounted. Opts: (null)
但有时（并非全部）关闭冻结会将一长串 ascii“非文本”代码写入相关日志文件，特别是 0xx（字符串终止字符），这似乎是不正常停止的标准行为，例如冻结造成的。
这会搞砸日志文件，通常的文本编辑器将在文件（Leafpad）中显示到直接拒绝打开日志文件（Pluma）的那一点。您必须使用十六进制编辑器或 MC 打开它，这实际上会向您显示文件中的所有内容。
因此，我现在需要的是一种方法来更详细地研究关闭过程的这一部分，并了解导致关闭冻结的原因。
然后我可能能够可靠地重现它。
它可能是由 Ultra 24 丑陋的 BIOS 引起的，也可能是内核中的一个不起眼的错误，这种错误已经被维护人员忽视，因为它没有影响足够数量的安装，也没有被报告，分配并被放弃或只是被打扰，因为支持就此结束任何。
我见过一些错误被分配的例子（例如：LibreOffice），由于缺乏可用时间而被受让人放弃，然后传递给其他人，而其他人出于某种原因没有接受它，最终最终多年未分配。
有没有其他方法可以检查关闭过程以进一步解决此问题？