VMware Workstation 26H1でOmarchy 4の画面が真っ黒になる問題

2026年8月25日にテスト済み

ゲストOSの再起動後、壁紙、トップバー、シェルUIが表示されているOmarchyデスクトップ。 — 回避策の適用後、VMware Workstation Pro 26H1上で正常に動作しているOmarchy 4。

Omarchy 4は起動していました。Hyprlandも動作していました。それでもデスクトップは真っ黒なままでした。

ログイン後、VMの画面に表示されたのは黒い背景と大きすぎるカーソルだけでした。トップバーもランチャーもなく、Omarchyシェルも見当たりませんでした。

それでも、Super + Enterを押すとターミナルが開きました。

この一点で、調査の方向性は完全に変わりました。

このことから、コンポジターが動作し、キーバインドが処理され、ウィンドウも作成できると分かりました。単にHyprlandが起動していないという状況ではなかったのです。

表示されていなかったのは、QuickshellベースのOmarchyデスクトップシェルでした。

まず試すこと：30秒でできるテスト

モニター設定の変更、Omarchyの再インストール、VMware 3Dアクセラレーションの無効化を行う前に、ターミナルから次を実行してください。

LIBGL_ALWAYS_SOFTWARE=1 \
quickshell -p "$OMARCHY_PATH/shell"

Omarchyのバーが表示され、Quickshellが動作し続ける場合、この記事で扱っているものと同じ種類の障害である可能性が高いです。

永続的な回避策だけが必要な場合は、「Omarchyのファイルを編集せず、再起動後も回避策を有効にする」まで進んでください。診断過程と根拠を確認する場合は、このまま読み進めてください。

それでもクラッシュする場合は、ここから先へ進まないでください。ブラックスクリーンの原因が異なる可能性があります。

実際にテストした環境

ホスト： Windows 11 25H2
VMware： Workstation Pro 26H1、ビルド25388281
VMware 3Dアクセラレーション： 有効
VMハードウェア： 8 GB RAM、16 vCPU、60 GB SCSIディスク
ゲスト： Omarchy 4 / Quattro
インストール： 公式4.0.0 ISOでインストール後、Omarchy Updateを実行
ゲストツール： open-vm-toolsをインストール済み
仮想GPU： VMware SVGA II Adapter
カーネルドライバー： vmwgfx
セッション： Wayland上のHyprland

Omarchy 4では、バー、ランチャー、メニュー、通知、OSD、パネル、ロック画面、そのほかのシェル機能が、単一の常駐Quickshellプロセスに移行されました。

そのため、1つのプロセスがクラッシュするだけで、Hyprlandは応答しているのに、デスクトップにはほとんど何も表示されない状態になり得ます。

最初に得られた有用なエラー

Quickshellが正常に動作しているか確認しました。

pgrep -af quickshell

安定して常駐しているシェルプロセスはありませんでした。

そこで、Omarchyシェルをフォアグラウンドで起動しました。

quickshell -p "$OMARCHY_PATH/shell"

QML設定は読み込まれました。

Launching config: "/usr/share/omarchy/shell/shell.qml"
Configuration loaded

その後、Quickshellが終了しました。

The Wayland connection experienced a fatal error: Invalid argument

QuickshellがOmarchyの設定を読み込んだ後、Wayland接続を失っている。 — OmarchyのQML設定は正常に読み込まれました。致命的な障害はその後に発生しました。

出力の前半にはポータル登録に関する警告も表示されていましたが、Quickshellはその後も読み込みを続けていました。実際にプロセスが終了したのは、Waylandエラーが発生した時点です。

ジャーナルからは、Omarchyのランチャーがすでにシェルを起動し、その終了を検知して再起動していることも確認できました。

したがって、これは自動起動の問題ではありませんでした。

公式の起動処理は機能していました。クラッシュしていたのは子プロセスです。

テスト時点のOmarchyでは、デフォルトのHyprland自動起動からomarchy-launch-shellが実行されていました。ランチャーはomarchy-shellジャーナルタグを付けてQuickshellを起動し、Hyprlandが動作している間、Quickshellが0以外の終了コードで終了すると再起動を試みます。起動コマンドのうち、Quickshell本体の呼び出しは次のとおりでした。

quickshell -n -p "$OMARCHY_PATH/shell"

ランチャーの再起動動作は、テスト時点のスクリプトで確認できます。

ディスプレイ設定を変えても改善しなかった

HyprlandはVMwareの出力を次のように識別していました。

Virtual-1

当初の環境では、VMwareによって動的に変更される解像度と、スケール係数2が使われていたため、一時的に標準の1920×1080モードに固定し、次の設定をテストしました。

scale 1
scale 1.25
scale 2

Quickshellは、どの場合もまったく同じように失敗しました。

The Wayland connection experienced a fatal error: Invalid argument

これだけで仮想ディスプレイが無関係だと証明されたわけではありませんが、少なくともこのVMでは、問題が元の解像度とスケールの組み合わせだけに固有のものではないと分かりました。

VMwareの描画経路が最有力候補に

ゲスト環境では、次の情報が確認できました。

VMware SVGA II Adapter
Kernel driver in use: vmwgfx
Kernel modules: vmwgfx

セッションはネイティブWaylandでした。

XDG_SESSION_TYPE=wayland
WAYLAND_DISPLAY=wayland-1

VMware SVGA IIアダプター、vmwgfxカーネルドライバー、ネイティブWaylandセッションを確認できる端末出力。 — ゲストはネイティブWaylandセッションで、`vmwgfx`を介してVMware SVGA IIを使用していました。

この時点では、Quickshell/Qt、Mesa、Hyprland、VMwareのグラフィックススタック間の相互作用が有力な仮説でした。

しかし、「グラフィックススタック内の何か」というだけでは、まだ曖昧すぎます。

失敗したWaylandリクエストを正確に確認することにしました。

`WAYLAND_DEBUG`で失敗箇所を特定する

Waylandプロトコルのトレースを有効にしてQuickshellを起動しました。

WAYLAND_DEBUG=1 \
quickshell -p "$OMARCHY_PATH/shell" \
> /tmp/qs-wayland.log 2>&1

次に、ログ末尾の関連部分を抽出しました。

grep -nEi \
'error|invalid|attach|buffer|dmabuf|surface' \
/tmp/qs-wayland.log | tail -50

重要なシーケンスは次のとおりです。

zwp_linux_dmabuf_v1.create_params(...)
zwp_linux_buffer_params_v1.create_immed(...)

wl_surface.attach(wl_buffer, 0, 0)
wl_surface.commit()

wl_display.error(
  ...,
  "invalid arguments for wl_surface.attach"
)

Waylandトレースがwl_surface.attachに到達し、その後「invalid arguments」エラーが表示されている。 — トレースが`wl_surface.attach`に到達した後、コンポジターが「invalid arguments」エラーを返しています。

これが転機となりました。

致命的なエラーはQML設定の読み込み後に発生しました。Quickshellがdma-bufベースのバッファーをサーフェスへアタッチしようとした後、Wayland接続が切断されました。

このトレースだけを根拠に、原因を特定の1つのコンポーネントと断定することは避けます。

このトレースだけでは、無効な組み合わせが次のどれに起因するのかを証明できません。

VMware SVGAまたはvmwgfx
Mesa
QtWaylandまたはQuickshell
Hyprlandのバッファー検証
これら複数のコンポーネント間の相互作用

ただし、このエラーパターンはこのVMだけに固有のものではありません。

別のVMwareゲストに関するHyprlandのIssueには、ほぼ同一のシーケンスが記録されています。linux-dmabufバッファーの作成、wl_surface.attach、そしてError 22 (Invalid argument)です。

その後のHyprlandのディスカッションでは、3Dアクセラレーションを有効にしたVMware Workstationとvmwgfxドライバーでの事例が報告されています。ネイティブWaylandターミナルは、ほかのコンポジターでは動作する一方、Hyprlandでは同じattachエラーで失敗したと報告されています。

これらの上流での報告は、すべての事例が同じ根本原因によることを証明するものではありません。

しかし、QMLのタイプミスや起動コマンドの欠落と判断する前に、グラフィックススタックの互換性を調べるべきだという強い根拠になります。

単一変数のA/Bテスト

通常起動 — 失敗

quickshell -p "$OMARCHY_PATH/shell"

結果：

The Wayland connection experienced a fatal error: Invalid argument

ソフトウェアレンダリングでの起動 — 成功

LIBGL_ALWAYS_SOFTWARE=1 \
quickshell -p "$OMARCHY_PATH/shell"

結果：

Omarchyのバーがすぐに表示され、Quickshellは動作し続けました。

Mesaのソフトウェアレンダリングを使うと、同じシェルが正常に起動したことを示す画面。 — 1つの変数を変更するだけで、Omarchyシェルが動作し続けるようになりました。

Mesaのドキュメントでは、LIBGL_ALWAYS_SOFTWAREはソフトウェアレンダリングを強制するものと説明されています。

このテストでは、成功時にlinux-dmabufが完全に使われなくなったことまでは確認できていません。また、特定のフォーマットやモディファイアの不一致も切り分けていません。

証拠から確実に言えるのは、次の範囲に限られます。

Mesaのソフトウェアレンダリングを強制することで、このVMでバッファーのアタッチ時に発生していた失敗を回避できました。

仮想マシンのVMware 3Dアクセラレーションは有効なままでした。

Omarchyのファイルを編集せず、再起動後も回避策を有効にする

永続化する前に、まず一度だけ実行するテストでQuickshellが動作し続けることを確認してください。さらに確度を上げるには、5つの診断条件と照合します。

LIBGL_ALWAYS_SOFTWARE=1をグローバルに設定する方が簡単ですが、Hyprlandセッション内の無関係なOpenGLアプリケーションにまでソフトウェアレンダリングを強制してしまう可能性があります。

そこで、この設定の適用範囲をOmarchyシェルランチャーのプロセスツリーに限定しました。Hyprlandセッション全体への設定は避けられますが、Quickshellの子孫プロセスとして起動するアプリケーションには、この変数が継承される可能性があります。

テスト時点のOmarchyでは、自動起動からPATHを介してomarchy-launch-shellが実行されていました。また、Omarchy自身のbinディレクトリがPATHの先頭に置かれるため、私のインストール環境では、通常の~/.local/binに置いた同名のラッパーは選択されませんでした。

このPATHの動作は、テスト時点のHyprland環境設定で確認できます。

解決策は、専用のラッパーディレクトリを設け、ユーザーレベルのPATHの先頭に追加することでした。

ステップ1 — ラッパーを作成する

mkdir -p ~/.local/omarchy-workarounds/bin

cat > ~/.local/omarchy-workarounds/bin/omarchy-launch-shell <<'EOF'
#!/usr/bin/env bash
set -euo pipefail

export LIBGL_ALWAYS_SOFTWARE=1

exec "${OMARCHY_PATH:-/usr/share/omarchy}/bin/omarchy-launch-shell" "$@"
EOF

chmod +x \
  ~/.local/omarchy-workarounds/bin/omarchy-launch-shell

このラッパーは環境変数を1つ設定し、その後でOmarchyの公式ランチャーに処理を引き継ぎます。

次のファイルは直接編集しないでください。

/usr/share/omarchy/bin/omarchy-launch-shell

このファイルはOmarchyパッケージに属しており、アップデートによって置き換えられる可能性があります。

ステップ2 — ラッパーをOmarchyのbinディレクトリより前に置く

次のファイルを開きます。

~/.config/hypr/hyprland.lua

次の行を探します。

require("default.hypr.omarchy")

その直後に、以下のコードを追加します。

-- VMware workaround: run the Omarchy shell with Mesa software rendering.
local workaround_bin =
  (os.getenv("HOME") or "") .. "/.local/omarchy-workarounds/bin"

local current_path =
  os.getenv("PATH") or "/usr/local/bin:/usr/bin"

local kept = {}

for entry in current_path:gmatch("[^:]+") do
  if entry ~= workaround_bin then
    table.insert(kept, entry)
  end
end

table.insert(kept, 1, workaround_bin)
hl.env("PATH", table.concat(kept, ":"))

このコードでは、ディレクトリを先頭に置く前に既存の同一エントリーを削除するため、設定を繰り返し再読み込みしても同じPATHエントリーが重複して追加されません。

Omarchy公式の自動起動、ジャーナル連携、シェルの再起動監視はそのまま維持されます。

ステップ3 — 再起動して確認する

reboot

ログイン後、バー、壁紙、通知、シェルUIが自動的に表示されました。

Quickshellを手動で実行する必要はありませんでした。

実行中のシェルが環境変数を継承していることを確認するには、次を実行します。

pid=$(pgrep -f 'quickshell.*omarchy/shell' | head -n1)

tr '\0' '\n' < "/proc/$pid/environ" |
  grep '^LIBGL_ALWAYS_SOFTWARE=1$'

期待される出力は次のとおりです。

LIBGL_ALWAYS_SOFTWARE=1

Quickshellが繰り返し終了して再起動されていないことを確認するには、次を実行します。

pid1=$(pgrep -f 'quickshell.*omarchy/shell' | head -n1)
sleep 10
pid2=$(pgrep -f 'quickshell.*omarchy/shell' | head -n1)

printf '%s -> %s\n' "$pid1" "$pid2"

両方のPIDが空でなく同じ値であれば、少なくともこの10秒間はQuickshellが再起動されていないと判断できます。

今回の起動時に記録されたシェルのジャーナルも確認できます。

journalctl --user -b -t omarchy-shell --no-pager |
  tail -50

この回避策で確認できること、証明できないこと

この回避策によって、次のことが確認できました。

デスクトップが真っ黒でも、Hyprlandは動作していた。
OmarchyのQML設定は読み込まれていた。
QuickshellはWaylandのバッファーアタッチ処理中に終了した。
LIBGL_ALWAYS_SOFTWAREだけを変更すると、シェルが動作し続けた。
この環境では、完全な再起動後も回避策が機能した。

一方、次のことを証明するものではありません。

vmwgfxだけが問題のあるコンポーネントである。
Hyprlandだけが問題のあるコンポーネントである。
VMware上のOmarchyで発生するすべてのブラックスクリーンに、この原因が当てはまる。
ソフトウェアレンダリングにパフォーマンス上のコストがない。
シェルから起動したアプリケーションには、この変数が一切継承されない。

この継承上の制約があるため、回避策は変数の適用範囲を狭めることはできますが、完全に分離するものではありません。

この症状に当てはまるか

この回避策が特に有効なのは、次の5項目がすべて成立する場合です。

デスクトップが真っ黒、またはほぼ空になるものの、Super + Enterを押すとターミナルは開く。
QuickshellがConfiguration loadedまで到達する。
その後、Waylandの致命的なInvalid argumentエラーで終了する。
WAYLAND_DEBUG=1でinvalid arguments for wl_surface.attachが表示される。
LIBGL_ALWAYS_SOFTWARE=1を追加すると、シェルが動作し続ける。

これらの条件に一致しない場合は、永続的な回避策をむやみに適用しないでください。

元に戻す方法

ラッパーディレクトリを削除します。

rm -rf ~/.local/omarchy-workarounds

次に、以下のファイルからworkaround_bin / hl.env("PATH", ...)のブロックを削除します。

~/.config/hypr/hyprland.lua

再起動後、通常のシェルをもう一度テストします。

quickshell -p "$OMARCHY_PATH/shell"

LIBGL_ALWAYS_SOFTWARE=1なしで安定して動作するようになれば、この回避策は不要です。

結論

ブラックスクリーンという見た目が、問題の所在を分かりにくくしていました。

Hyprlandは起動していました。キーバインドは機能していました。ウィンドウも開けました。

表示されていなかったのはQuickshellベースのOmarchyシェルです。バッファーをアタッチしようとした際にWayland接続が切断され、シェルが終了していました。

有用だった診断の流れは次のとおりです。

ブラックスクリーン
→ Hyprlandは引き続き応答
→ Quickshellが終了
→ Waylandの致命的なInvalid argumentエラー
→ 解像度とスケールを変更しても同じ障害が継続
→ 使用中の描画経路がVMware SVGA II / vmwgfxであることを確認
→ WAYLAND_DEBUGでwl_surface.attachの失敗を特定
→ 変数を1つだけ変えたソフトウェアレンダリングテストが成功
→ ユーザーレベルに限定した回避策
→ 再起動後も回避策が機能

最も手早いテストは次のコマンドです。

LIBGL_ALWAYS_SOFTWARE=1 \
quickshell -p "$OMARCHY_PATH/shell"

これでバーが再び表示される場合は、モニター、スケール、自動起動の設定を手当たり次第に変更する前に、WAYLAND_DEBUGログ末尾のエラーを記録してください。

VMware Fusion、古いWorkstationビルド、またはほかの仮想GPUと比較する際にも、ここで挙げた診断情報が役立ちます。ホストOS、VMwareのビルド、ゲストドライバー、そして最後に発生したWaylandエラーを記録してください。

VMware Workstation 26H1でOmarchy 4の画面が真っ黒になる問題

まず試すこと：30秒でできるテスト

実際にテストした環境

最初に得られた有用なエラー

ディスプレイ設定を変えても改善しなかった

VMwareの描画経路が最有力候補に

`WAYLAND_DEBUG`で失敗箇所を特定する

単一変数のA/Bテスト

Omarchyのファイルを編集せず、再起動後も回避策を有効にする

ステップ1 — ラッパーを作成する

ステップ2 — ラッパーをOmarchyのbinディレクトリより前に置く

ステップ3 — 再起動して確認する

この回避策で確認できること、証明できないこと

この症状に当てはまるか

元に戻す方法

結論

次の仕事を支援する

コメント

まず試すこと：30秒でできるテスト

実際にテストした環境

最初に得られた有用なエラー

ディスプレイ設定を変えても改善しなかった

VMwareの描画経路が最有力候補に

WAYLAND_DEBUGで失敗箇所を特定する

単一変数のA/Bテスト

Omarchyのファイルを編集せず、再起動後も回避策を有効にする

ステップ1 — ラッパーを作成する

ステップ2 — ラッパーをOmarchyのbinディレクトリより前に置く

ステップ3 — 再起動して確認する

この回避策で確認できること、証明できないこと

この症状に当てはまるか

元に戻す方法

結論

次の仕事を支援する

コメント

アクセス解析の選択

`WAYLAND_DEBUG`で失敗箇所を特定する