BunsenLabs GNU/Linux(Debianベース)の奇妙な動作に遭遇しました。
OSをオフにできないことがあります。 Sudo poweroff
を使用するか、GUIアプローチを使用するかは関係ありません。
これは、Sudo poweroff
を実行した後に得られるものです。
Failed to start poweroff.target: Transaction is destructive
回避策はありますか?なぜそれが起こっているのですか?
これが私の/lib/udev/rules.d/70-power-switch.rules
の内容です。
ACTION=="remove", GOTO="power_switch_end"
SUBSYSTEM=="input", KERNEL=="event*", SUBSYSTEMS=="acpi", TAG+="power-switch"
SUBSYSTEM=="input", KERNEL=="event*", KERNELS=="thinkpad_acpi", TAG+="power-switch"
LABEL="power_switch_end"
私はしばらくの間、解決策を探していましたが、最後に解決策を見つけました。それは私のために働いた。何がこの奇妙な振る舞いを引き起こすのかはわかりません。
これは、Debianをシャットダウンするためのレシピです。
ps aux | grep suspend
を実行します。結果の1つは次のようになります。
root 3651 0.0 0.0 8668 1716 ? Ss 07:18 0:00 /lib/systemd/systemd-sleep suspend
Sudo kill 3651
または結果のpidを実行します。
初めて、私はPCをシャットダウンすることができました。 2回目は、kill
コマンドの直後にPCがスリープ状態になりました。
プロセスを終了する前に、グラフィカルデスクトップ環境からログアウトすることをお勧めします。
出典: buntuフォーラム 。
私の場合はsystemd-sleep
プロセスが実行されていなかったため、この質問に別の回答を追加しますが、マシンを停止、シャットダウン、電源オフ、または再起動できませんでした。 (この振る舞いは、systemd
が マルウェア として完全に修飾されていることのもう一度の証明だと思いますが、その議論は別の機会に残しましょう。)
結局、私はsystemd
との闘いを手助けするためにカーネルに頼りました。以下はハードリブート(電源ボタンを押す)とそれほど変わりませんが、マシンに物理的にアクセスできない場合に役立ちます。
echo 1 > /proc/sys/kernel/sysrq
echo b > /proc/sysrq-trigger
これと同じ問題がありました。
# systemctl status poweroff.target
● poweroff.target - Power-Off
Loaded: loaded (/lib/systemd/system/poweroff.target; enabled; vendor preset:
Active: inactive (dead)
Docs: man:systemd.special(7)
次に実行しましたsystemctl start poweroff.target
そして、それはシャットダウンしました。