web-dev-qa-db-ja.com

BunsenLabs（Debian derrivative）はシャットダウンしません（poweroff.targetの開始に失敗しました：トランザクションは破壊的です）

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"
systemdudevshutdownbunsenlabs
11
Mateusz Piotrowski

私はしばらくの間、解決策を探していましたが、最後に解決策を見つけました。それは私のために働いた。何がこの奇妙な振る舞いを引き起こすのかはわかりません。

これは、Debianをシャットダウンするためのレシピです。

  1. ps aux | grep suspendを実行します。

  2. 結果の1つは次のようになります。

    root 3651 0.0 0.0 8668 1716 ? Ss 07:18 0:00 /lib/systemd/systemd-sleep suspend

  3. Sudo kill 3651または結果のpidを実行します。

  4. 初めて、私はPCをシャットダウンすることができました。 2回目は、killコマンドの直後にPCがスリープ状態になりました。

プロセスを終了する前に、グラフィカルデスクトップ環境からログアウトすることをお勧めします。

出典： buntuフォーラム 。

8
Mateusz Piotrowski

私の場合はsystemd-sleepプロセスが実行されていなかったため、この質問に別の回答を追加しますが、マシンを停止、シャットダウン、電源オフ、または再起動できませんでした。 （この振る舞いは、systemdが マルウェア として完全に修飾されていることのもう一度の証明だと思いますが、その議論は別の機会に残しましょう。）

結局、私はsystemdとの闘いを手助けするためにカーネルに頼りました。以下はハードリブート（電源ボタンを押す）とそれほど変わりませんが、マシンに物理的にアクセスできない場合に役立ちます。

echo 1 > /proc/sys/kernel/sysrq
echo b > /proc/sysrq-trigger

再起動すると、 処理一掃 によって地獄のスポーン。

6
Alberto Santini

これと同じ問題がありました。

# 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

そして、それはシャットダウンしました。

1
Miati