Devuan ASCIIで実行されているSun Ultra 24ワークステーションで発生する迷惑なシャットダウンの問題を解決しようとしています。
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:~$
これは展開とは無関係な問題のようです。これは、Emergency TCore Linuxと同じデバイスでも発生し、起動時にF8を介してメモリースティックのEmergency TCore Linuxにアクセスできます。
MSOSのインストールでこれが起こるかどうかわかりません。これはMSOSがなく、テスト用にXPを実行している仮想マシンしかないからです。
質問は基本的に次のとおりです。
終了すると、マシンは次の2つの操作のいずれかを実行します。
- 正しく閉じる
- 現在終了中に凍結中...
e1000e: EEE Tx LPI Timer
Preparing to enter sleep state S5
Reboot: Power Down
...ファンが最高速度で回転します。
最初は、これは2つの部分からなる問題でした。最初はシャットダウン時の再起動の問題でしたが、これはWoLを無効にして（明らかに）解決され、再び発生しませんでした。
2番目の部分（最初の部分と同様）は完全に予測不可能な方法で発生するため、複製したり特定の項目にリンクしたりすることはできません。
WoLを無効にすること（BIOSを介して実行できないため少し面倒です）に加えて、Intel e1000eコントローラでEEE設定も無効にしましたが、何の効果もありませんでした。
終了時にスクリプトを使用してe1000eドライバモジュールを削除したり、カーネルコマンドラインにさまざまなrestart =セクションを挿入したりすることは効果がありません。つまり、再起動=強制、再起動=acpi、再起動=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（文字列終了文字）が記録されます。これは、次のような異常な停止に対する標準的な動作のようです。凍結炉。
これにより、ログファイルが混乱し、一般的なテキストエディタがログファイル（Pluma）を完全に拒否するまでファイル（Leafpad）に表示されます。実際には、ファイルのすべての内容を表示する16進エディタまたはMCでファイルを開く必要があります。
したがって、今私が必要とするのは、シャットダウンプロセスのこの部分をさらに詳しく調べ、シャットダウンが停止する原因を理解する方法です。
それから私は可能安定して再現できます。
これは、Ultra 24の見苦しいBIOSによって引き起こされる可能性があり、十分な数のインストールに影響を与えず、報告、展開、および放棄されなかったため、管理者が無視したカーネルのあいまいなバグである可能性があります。サポートはそこで終わるので面倒です。どの。
私は間違った割り当て（例：LibreOffice）のいくつかの例を見ました。担当者が利用可能性の欠如のために作業を中断した後、何らかの理由で作業を行わずに他の人に渡され、最終的に作業を実行できないことがありました。長年にわたって割り当てられました。
この問題をさらに解決するためにシャットダウンプロセスを確認する他の方法はありますか？