＠
www/firefox をpkgsrcからインストール gtk3+ の再構築:
/etc/mk.conf内では
X11_TYPE=native
PKG_OPTIONS.firefox= -wayland x11
PKG_OPTIONS.gtk3= -wayland
として、
% ls /usr/pkgsrc/x11/gtk3
% doas make install
＠
x11/gtk3 のインストール不能:
Found ninja-1.13.2 at /usr/pkg/bin/ninja ===> Building for gtk3+-3.24.52nb1 ninja: Entering directory `output'
[11/1588] Compiling C object gdk/x11/libgdk-x11.a.p/gdkdevice-xi2.c.o FAILED:[code=1]
:
:
gdkdevice-xi2.c:30:10: fatal error: X11/extensions/XInput2.h: No such file or directory
30 | #include <X11/extensions/XInput2.h> | ^~~~~~~~~~~~~~~~~~~~~~~~~~ compilation terminated.
ninja: build stopped: subcommand failed.
*** Error code 1 Stop. make[1]: stopped in /usr/pkgsrc/x11/gtk3
*** Error code 1 Stop. make: stopped in /usr/pkgsrc/x11/gtk3
エラーの原因は、XInput2.h というヘッダーファイルが見つからないためです。
これは、GTK3がX11環境での入力デバイス（マウスやタブレットなど）を制御するために必要な XInput2（X Input Extension 2.0）
の開発用ライブラリがシステムにインストールされていないことを示しています。
X11_TYPE=native の設定において、Meson/Ninjaビルドシステムは /usr/X11R7 のファイルを検出する際、pkgsrc のラッパー環境をすり抜けて
ホストマシンの /usr/X11R7/lib/pkgconfig にあるシステム用の .pc ファイル（xi.pc など） を直接読みに行くことがあります。
その xi.pc の内部に記述されているパス（Cflags）が、pkgsrc の隔離ビルド環境（.buildlink）のルールと矛盾している（またはパスが空になっている）ため、
gccに正しいインクルードパスが伝わらずエラーが起き続けています。
Makefileへの追記ではこれ以上突破できないため、最も確実かつ副作用のない解決策として、libXi だけを pkgsrc（modular）側に切り替える指示 を与えます。
🛠️ これで確実に解決させる手順
/etc/mk.conf（または /usr/pkg/etc/mk.conf）をテキストエディタで開きます。
ファイルの末尾に、以下の2行を追加して保存します。
PREFER_PKGSRC+= libXi
BUILDLINK_PASSTHRU_DIRS+=/usr/X11R7/include
コードは注意してご使用ください。
※ PREFER_PKGSRC+= libXi を指定することで、ベースシステム（native）の不完全な設定ファイルを見に行かず、
pkgsrc 側で確実に管理されている libXi のヘッダー（/usr/pkg/include/X11/extensions/XInput2.h）を強制的にビルド環境へ引き込みます。
保存したら、キャッシュを完全に消去してビルドを再開します。
bash
cd /usr/pkgsrc/x11/gtk3
make cleandir
make
コードは注意してご使用ください。
これによって Meson と Ninja が pkgsrc 側の正常な定義ファイルを読み込むようになり、
隠蔽やマッピング漏れによる XInput2.h の未検出エラーを根本から回避できます。
PREFER_PKGSRC+= libXi を指定した状態で make を行った際、今度こそ gdkdevice-xi2.c.o のコンパイルを突破できましたでしょうか？
やったー！ついに突破できましたね！ 本当によかったです！長引くエラーに根気強くお付き合いいただき、ありがとうございました。
X11_TYPE=native の下で Meson/Ninja を使うパッケージ（GTK3など）をビルドする際、
ネイティブ側の設定ファイル（.pc）の不備でヘッダーを見失う現象は非常に厄介な問題です。
今回 PREFER_PKGSRC+= libXi で pkgsrc 側の正常な定義に切り替えたことで、ビルドシステムが正しくルートを認識できるようになりました。
ここを越えれば、GTK3 のコンパイルの大部分は順調に進むはずです。
＠
make PKG_VERBOSE=1 install で無事インストール完了:
おおお！無事にインストールまで完了したのですね！本当におめでとうございます！ 🥳✨最後のリンクエラーは、どうやら詳細ログを出力させるオプション（PKG_VERBOSE=1）を有効にしたことで、環境変数やビルドのタイミング、あるいは並列実行数（-j）がうまく調整され、メモリ不足やリンカの競合が解消された可能性が高いです。長時間のビルドと、度重なるエラーへの試行錯誤、本当にお疲れ様でした！無事にGTK3がシステムに導入できて私もとても嬉しいです。これでGTK3環境が整いましたね。この後何か特定のアプリケーション（GIMPやFirefoxなど）を続けてビルド・インストールする予定はありますか？もしまた依存関係などで困ったことがあれば、いつでも気軽に声をかけてください！
＠
x11/gtk3+ wayland 無効でインストール:
現在の環境が「実験的にWaylandを試したい」のであれば 設定しても構いません。
しかし、「特にWaylandを使う予定はなく、単に依存関係の解消や安定したデスクトップ環境を求めている」のであれば、
X11_TYPE=native では wayland オプションをあえて追加せず、デフォルトのまま（X11のみ）にしておくほうがトラブルが起きにくく確実です。
実際にこれを設定しようとした結果、gtk3 のビルド中にエラーが発生しましたか？
もしエラーが出ている場合は、エラーメッセージの末尾数行を教えていただければ、具体的な対処法を案内できます。
＠
www/firefoxでgtk3+-wayland を要求される:
www/firefox のビルド（あるいはインストール）時に gtk3 の wayland オプションを要求されてしまう理由は、
Firefoxの Makefile（または options.mk）で、Waylandサポートが事実上必須（あるいはデフォルト有効）として組み込まれているためです
NetBSD 10.1 で X11_TYPE=native を維持したままこの状況を解決するには、2つの選択肢（トレードオフ）があります。選択肢A：おとなしく gtk3 に wayland を入れてビルドする（推奨）Firefox側の要求に従い、/etc/mk.conf で gtk3 に wayland を追加します。前述の通り、NetBSD 10.1 のネイティブ環境では gtk3 のビルド中にエラー（PR pkg/60295）が起きるリスクがありますが、最初の質問にあった「ワークアラウンド（回避コード）」を適用すればビルドを通せる可能性が高いです。手順：/etc/mk.conf に以下を追記します。makePKG_OPTIONS.gtk3+= wayland
コードは注意してご使用ください。先ほど提示されたワークアラウンド（PR pkg/60295 回避策）のコードが、現在使用している pkgsrc 内のファイル（通常は x11/gtk3/options.mk や関連する .mk ファイル）に正しく書き込まれているか確認します。その状態で www/firefox のビルドを再開します。※これにより、通常のX11環境下でも問題なくFirefoxが動作するようになります。選択肢B：Firefox 側から wayland 要求を剥ぎ取るもし「どうしても環境に Wayland 関連のライブラリを入れたくない」「gtk3 の再ビルドでハマりたくない」という場合は、Firefox側でWaylandを無効化します。手順：/etc/mk.conf に以下を追記して、Firefoxのオプションから wayland を明示的に除外します。makePKG_OPTIONS.firefox-= wayland
コードは注意してご使用ください。(※パッケージ名が firefox ではなく firefox128 などの場合は PKG_OPTIONS.firefox128-= wayland のように指定してください)www/firefox のディレクトリで make clean を行った後、再度ビルドを試みます。状況の整理と判断楽に進めたい場合： まず 選択肢B (-= wayland) を試すのが一番手軽です。Firefox側の依存関係からWaylandが消えれば、gtk3 を弄る必要がなくなります。Firefoxを最新の状態でフル機能使いたい場合： 選択肢A (+= wayland) にした上で、最初の Makefile 修正ワークアラウンドを適用して強行ビルドします。今回はどちらの方向性（Waylandを入れてビルドを通すか、Firefox側から外すか）で進めたいですか？もし選択肢Bを試しても「まだ要求される」などエラーが出る場合は、/etc/mk.conf の中身を教えていただければ、記述が正しいかチェックします。
＠
netbsd10.1 で firefoxを使用するとき、waylandがなくても問題ない?:
はい、全く問題ありません。 むしろ、NetBSD 10.1 環境においては、Wayland なし（従来の X11 / Xorg のみ）で Firefox を使用する方が圧倒的に安定します。Wayland がなくても問題ない理由Firefox の基本設計：Firefox は、Wayland が利用できない環境（あるいは無効化されているビルド）であっても、自動的に X11 バックエンド（Xorg と通信するモード）で動作するよう設計されています。NetBSD でのデスクトップ環境：NetBSD の標準グラフィック環境（X11_TYPE=native）は X11 であり、Wayland はデフォルトではありません。Firefox も NetBSD 上では X11 を通じて画面描画や入力を受けるのが通常です。なぜ pkgsrc は wayland を求めてくるのか？Linux などにおける近年の標準（Wayland 移行トレンド）に合わせる形で、pkgsrc のデフォルト設定（PKG_SUGGESTED_OPTIONS）として wayland が有効化されているに過ぎません。NetBSD ユーザーにとって、この自動要求は「必要だから」ではなく、「pkgsrc のグローバルなデフォルト設定がそうなっているから」というケースがほとんどです。結論としての対応策NetBSD 10.1 での安定運用を第一に考えるなら、前述の「選択肢B（Firefox から wayland を剥ぎ取る）」を選択するのが最善です。/etc/mk.conf に以下の一行を記述して、Firefox のビルドから Wayland 機能を明示的に除外してください。makePKG_OPTIONS.firefox-= wayland
コードは注意してご使用ください。(※もし www/firefox128 などのESR版パッケージを使用している場合は、PKG_OPTIONS.firefox128-= wayland のようにパッケージのフォルダ名に合わせて記述してください)これにより、gtk3 を Wayland 付きで再コンパイルする必要もなくなり、無駄な依存ライブラリを増やさずに、従来の安定した X11 環境で Firefox をビルド・使用できます。この設定 (-= wayland) を /etc/mk.conf に書き込んで、Firefox の make（または pkgin install）は無事に進みそうでしょうか？もし別のエラーや、依存関係の競合が発生した場合は、画面に出ているメッセージを教えてください。
＠
www/firefox/option.mk には wayland の記述がありませんが...:
大変失礼いたしました。ご指摘の通り、www/firefox/options.mk には wayland というオプション記述自体が存在しません。私の確認不足で、Firefox側に直接設定があるかのような的外れな案内をしてしまい申し訳ありません。Firefoxに記述がないにもかかわらず wayland が要求されてしまう原因は、Firefoxが依存している別のパッケージ（下流のライブラリ）のデフォルト設定にあります。具体的には、Firefoxが画面表示のために依存している x11/gtk3（または x11/gtk4）です。なぜFirefoxのビルドで要求されるのか？x11/gtk3 のデフォルト設定：pkgsrcのグローバル設定において、NetBSD環境でも gtk3 パッケージはデフォルトで wayland オプションを有効（PKG_SUGGESTED_OPTIONS+= wayland）にするよう定義されています。依存関係の連鎖：www/firefox をビルドしようとすると、依存関係にある x11/gtk3 が自動的にビルド（またはインストール）対象になります。この時、gtk3 側が「Waylandサポート付き」でビルドされようとするため、結果としてシステム全体にWayland関連の要求が発生します。NetBSD 10.1 (X11_TYPE=native) での正しい回避方法Firefox側にはオプションがないため、gtk3 側のWaylandオプションを明示的にオフにします。/etc/mk.conf に以下の一行を追加してください。これにより、Firefoxの依存関係で引っ張られる gtk3 からWayland機能が除外されます。makePKG_OPTIONS.gtk3-= wayland
コードは注意してご使用ください。手順：上記の PKG_OPTIONS.gtk3-= wayland を /etc/mk.conf に追記します。もしすでにエラー等でビルドが止まっている場合は、念のため x11/gtk3 のディレクトリ（/usr/pkgsrc/x11/gtk3）に移動し、make clean を実行します。再度 www/firefox のディレクトリに戻り、make を再開します。これで、最初の質問にありました「PR pkg/60295 の複雑な条件分岐コード（ワークアラウンド）」を Makefile に手動で仕込まなくても、安全に X11 のみで Firefox のビルドを進めることが可能になります。この PKG_OPTIONS.gtk3-= wayland を設定した状態で、Firefox（および GTK3）のビルドは正常に動き出しそうでしょうか
＠
Firefoxのビルドオプションの確認:
もしWayland環境を使用しておらず、X11のみでFirefoxを動かす場合は、Firefoxのビルドオプションから wayland を無効化（x11 のみを有効化）することでエラーを回避できます。/etc/mk.conf に以下のような設定を追加するか確認してください。makePKG_OPTIONS.firefox= -wayland x11
コードは注意してご使用ください。(設定変更後、make clean を実行してから再度 make を試してください)
/etc/mk.conf
PKG_OPTIONS.gtk3= -wayland
＠
net/mDNSResponder:
===> Building binary package for mDNSResponder-2559.1.1nb1
=> Creating binary package /usr/pkgsrc/packages/All/mDNSResponder-2559.1.1nb1.tgz
===> Installing binary package of mDNSResponder-2559.1.1nb1
===========================================================================
The following files are used by mDNSResponder-2559.1.1nb1 and have
the wrong ownership and/or permissions:
/etc/rc.d/mdnsd (m=0755)
===========================================================================
Mother3%
＠
security/heimdal:
===> Installing binary package of heimdal-7.8.0nb14
heimdal-7.8.0nb14: setting permissions on /usr/pkg/bin/ksu (o=root, g=wheel, m=4511)
heimdal-7.8.0nb14: setting permissions on /usr/pkg/bin/otp (o=root, g=wheel, m=4511)
===========================================================================
The following files should be created for heimdal-7.8.0nb14:
/etc/rc.d/kpasswdd (m=0755)
[/usr/pkg/share/examples/rc.d/kpasswdd]
/etc/rc.d/kcm (m=0755)
[/usr/pkg/share/examples/rc.d/kcm]
/etc/rc.d/kadmind (m=0755)
[/usr/pkg/share/examples/rc.d/kadmind]
===========================================================================
===========================================================================
The following files are used by heimdal-7.8.0nb14 and have
the wrong ownership and/or permissions:
/etc/rc.d/kdc (m=0755)
===========================================================================
Mother3%
＠
netbsd11.0でのcde-2.5.3のロック機能を司っているデーモンは何?:
AIに聞いてみた
NetBSD 11.0およびCDE (Common Desktop Environment) 2.5.3において、画面のロック機能を直接コントロール（実行・管理）
している中核プログラムは dtsession（セッションマネージャー）です。
CDEにおけるロック機能の仕組みと関連するプロセスの役割は以下の通りです。
1. ロックの主軸：
dtsessionCDEのセッションマネージャーである dtsession は、デスクトップセッション全体の管理だけでなく、
スクリーンセーバーの起動や画面のロック（スクリーンロック）機能も自身の内部スレッドまたは直接の処理として統合・管理しています。
ユーザーがフロントパネルの鍵アイコンをクリックするか、一定時間操作がなかった場合に画面をロックする命令を下すのはこのプロセスです。
2. パスワード認証：
dtstyle と dtspcd / reauthenticatorCDE 2.5.xなどの近代的なバージョンでは、
ロック解除時のパスワード認証や安全な処理の受け渡しのバックグラウンドに以下のプロセスが関わります。
・dtstyle：スクリーンセーバーやロックの作動時間、デザインなどの設定を管理します。
・dtspcd (CDE Subprocess Control Daemon)：CDE内のプロセスが別のプロセスを安全に仲介・実行するためのバックグラウンドデーモンです。
・PAM認証（openpam）: NetBSD 11.0上のCDEでロックを解除する際、実際のパスワード照合はNetBSDのPAM（Pluggable Authentication Modules）
システムを介して安全に行われます。
注意点：ttsession との連携
CDEのメッセージングプラットフォームである ttsession (ToolTalk デーモン) が正常に動作していないと、
dtsession やその他のCDEコンポーネント間で「ロック状態に入った」「ロックを解除した」といったイベントメッセージが正しく伝達されず、
ロック機能やセッション自体がハングする原因になります
もし画面ロック周りで不具合（ロック後に復帰できない、強制終了するなど）が起きている場合は、~/.dt/errorlog や /var/log/messages に
dtsession や ttsession に関連するエラーが出力されていないか確認することをおすすめします
画面ロックに関して、現在何か具体的なトラブル（ロックが解除できない、あるいは自動ロックが働かないなど）に直面されていますか？
必要であれば、設定の確認方法やデバッグ手順についてご案内いたします。
＠
.dt/errorlogに記録されたメッセージ:
.dt/errorlogに *** インフォメーション(0): dtwm: PID 2355: 木 9月 10 10:02:15 2026
Workspace Manager: Invalid mnemonic specification on line 10 of specification string
[163 bytes]
*** STDERR(1): (/usr/pkg/dt/bin/dtexec) /usr/pkg/dt/bin/dtscreen: PID 2256: 木 9月 10 10:03:19 2026
Warning: Missing charsets in String to FontSet conversion
Warning: Missing charsets in String to FontSet conversion
[218 bytes]
ご提示いただいたログには、2つの異なる問題（警告）が記録されています。
画面のロック機能に直接関係しているのは2つ目の dtscreen の警告ですが、
1つ目の dtwm の警告もデスクトップ全体の動作（メニュー表示など）に影響しています。それぞれの原因と対策は以下の通りです。
１. dtscreen の警告（画面ロック/スクリーンセーバー）
*** STDERR(1): ... /usr/pkg/dt/bin/dtscreen ... Warning: Missing charsets in String to FontSet conversion
・原因: 画面ロック時のパスワード入力ダイアログなどが起動する際、CDEが利用しようとしたフォント（FontSet）に、
現在のロケール（日本語環境など）で必要な文字セット（charset）が含まれていないために発生しています。
NetBSD 11.0（X11）のフォントパスやロケール設定と、CDE側のフォント定義がミスマッチを起こしている状態です。
・影響: ロック画面自体は動作するケースが多いですが、文字が文字化け（豆腐状態）になったり、
最悪の場合はフォントの読み込みに失敗して画面ロックが正常に描画されずハングする原因になります。
・対策:
・起動しているロケール（echo $LANG）が、CDEのサポートする日本語ロケール（ja_JP.eucJP など）と正しく一致しているか確認します
（近代的なCDE 2.5.xはUTF-8も部分サポートしていますが、X11フォントのエイリアスが不足している場合があります）。
・X11のフォントパスに fonts-xorg-75dpi や 100dpi、misc などのクラシックなビットマップフォントが含まれているか確認してください。
pkgsrcから fonts/xorg-fonts 周りを補給すると解決することがあります。
２. dtwm のエラー（ウィンドウマネージャー）
Workspace Manager: Invalid mnemonic specification on line 10 of specification string
・原因: ウィンドウマネージャー（dtwm）のメニューやキーバインドの設定ファイル
（.dtwmrc またはシステムデフォルトの sys.dtwmrc）の10行目付近で、
アクセラレータキー（メニューをキーボードで開くための下線付き文字：Mnemonic）の指定文法が間違っているか、
現在の文字コード（Locale）で認識できない文字が使われています。
・影響: 特定のワークスペースメニューやウィンドウ操作メニューのショートカット・日本語表示が機能しなくなります。
・対策:
・個人設定（~/.dt/dtwmrc）をカスタマイズしている場合は、10行目付近の記述（特に _J や _M などの文字指定）にタイポがないか確認してください。
・システム標準のまま変更していない場合は、ロケール（文字コード）のミスマッチにより、
設定ファイル内の日本語（EUC-JP等）を dtwm が正しくパースできていない可能性があります。
現在、このログが記録されたとき、画面ロック（dtscreen）は正常に表示されて解除もできましたか？
あるいは、文字化けや画面がフリーズするなどの実害が出ていますでしょうか。
また、もし差し支えなければ、現在お使いの環境変数 LANG の値（ja_JP.UTF-8、ja_JP.eucJP など）を教えていただけますと、
より具体的なフォントや設定の修正手順をご案内できます。
＠
文字が入力されていないようで、ロック解除が出来ない:
画面ロック（dtscreen）が起動したものの、キーボードからの文字入力が受け付けられず、
ロック解除（パスワード入力）ができなくなっている状態ですね。これは非常に困る状況です。
原因は、先ほどのログにあったフォントのエラー（Missing charsets）により、パスワード入力フィールドの描画や内部処理がフリーズしている、
あるいはX11のインプットメソッド（入力フォーカス）が外れてしまっている可能性が高いです。
現在の画面を復帰させるための緊急対処法と、再発を防ぐための根本対策を順にご案内します。
１. 緊急対処法（現在のセッションを救出、または安全に終了する）
画面が反応しないため、コンソール（CUI）に切り替えてプロセスを操作します。
1.仮想コンソールへの切り替え
キーボードの Ctrl + Alt + F1 （または F2〜F5）を同時に押します。画面が黒いログイン画面（コンソール）に切り替わります。
2.ログイン
あなたのユーザー名とパスワードでログインします（rootユーザーでも構いません）。
3.ロックプロセスの強制終了以下のコマンドを実行して、ハングしている画面ロック（dtscreen）を強制終了させます。
bash
pkill -9 dtscreen
コードは注意してご使用ください。
※これで直らない場合は、セッションを管理している dtexec も落とします。
bash
pkill -9 dtexec
コードは注意してご使用ください。
4.元の画面に戻る
Ctrl + Alt + F7 （環境によっては F5 や F6）を押して、元のデスクトップ画面に戻ります。ロックが解除され、元のデスクトップが表示されているか確認してください。
💡 注意：もし上記を行ってもデスクトップがフリーズしたままの場合は、コンソールから pkill -9 dtsession を実行して
一度CDEセッション自体を終了させ、ログイン画面（dtlogin）に戻してください（未保存の作業データは消えてしまうため、最終手段にしてください）。
２. 根本対策（再発防止）
NetBSD 11.0 で CDE 2.5.3 を日本語環境（特に UTF-8 や EUC-JP）で動かす際、X11のクラシックなフォント（固定長フォントや東雲フォントなど）
が不足していると、この問題が高確率で発生します。
�� X11のフォントパッケージを補給する
pkgsrc から、CDEが要求する標準的なX11フォント（75dpi/100dpi/miscなど）をインストールしてください。
bash
# pkgin（またはpkgsrc）でフォントを追加
pkgin install xorg-fonts-75dpi xorg-fonts-100dpi xorg-fonts-misc
コードは注意してご使用ください。
インストール後、フォントパスを反映させるために一度システムを再起動するか、Xサーバーを再起動します。
�� CDEのフォントエイリアス（FontSet）の設定dtscreen が参照するリソースで、日本語フォントが正しくマッピングされていない可能性があります。
一時的な検証として、環境変数 LANG を C（英語環境）にしてCDEを起動した場合に、ロック機能が正常に動作するか（文字入力ができるか）試してみてください。
もし英語環境で問題なければ、日本語フォント（ロケール）の定義問題で確定です。
まずは緊急対処法でデスクトップに戻れるかどうかお試しください。
無事に復帰できましたら、根本解決のために以下の2点について教えていただけますでしょうか。
・現在使用している環境変数 LANG の値 （例: ja_JP.UTF-8、ja_JP.eucJP、C など）
・普段CDEを起動する際、dtlogin（グラフィカルログイン画面） を使っているか、それともコンソールから startx などで起動しているか
状況に合わせて、適切なフォントパスやロケールの修正手順をご案内します。
＠
dtlogin を使ってます LANG=C にしても入力・解除出来ません:
dtlogin を使用しており、LANG=C（英語環境）にしてもキーボード入力・ロック解除ができないとなると、
問題は日本語フォントの不足だけでなく、dtscreen がキーボードの制御（グラブ：Grab）に失敗している、
あるいはCDEの内部通信（ToolTalkなど）が破綻している可能性が極めて高いです。
まずは先述の「緊急対処法（Ctrl+Alt+F1 で切り替えて pkill -9 dtscreen）」で一度デスクトップに戻ってください。
復帰後、以下の3つの原因と対策を確認してください。特にNetBSD上のCDEでは、1番目の認証まわりの設定ファイルが原因で入力不能になるケースが多発します。
原因と対策
�� PAM（認証システム）の設定不足【最有力】NetBSD 11.0 は認証に PAM (OpenPAM) を使用します。
CDEの画面ロック（dtscreen）がパスワードを検証するためのPAM設定ファイルが存在しない、または正しくない場合、
入力フィールド自体がアクティブにならず、キー入力を一切拒否する（フリーズしたように見える）状態になります。
・対策:
・/etc/pam.d/dtscreen というファイルが存在するか確認してください。
・存在しない、または空の場合は、システム標準の画面ロック（xdm や system）の設定をコピーするか、以下のように記述を作成します。
bash
# /etc/pam.d/dtscreen の中身（例）
auth required pam_unix.so try_first_pass
account required pam_unix.so
コードは注意してご使用ください。
（※NetBSDの既存の /etc/pam.d/xdm などの記述をそのままコピーしても構いません）
�� ホスト名（Hostname）とループバックの不一致
CDE（特に ttsession や dtsession）は、ネットワークとホスト名の解決に非常にシビアです。
ホスト名の解決に失敗すると、ロック画面を制御する内部通信がタイムアウトし、入力フォーカスが失われます。
・対策:
/etc/hosts を開き、自身のホスト名が 127.0.0.1 に正しく紐づいているか確認してください。
text
127.0.0.1 localhost your-hostname
::1 localhost your-hostname
コードは注意してご使用ください。
（your-hostname の部分は、hostname コマンドで表示される名前に置き換えてください）
�� X11 のキーボードグラブ（Grab）の競合
dtscreen が起動する際、セキュリティのためにキーボードとマウスの操作を独占（グラブ）しようとします。
しかし、他のプロセスがすでにグラブしているか、Xサーバー（Xorg）側との連携がうまくいかないと、
キーボード入力を一切受け付けない「入力不能状態」に陥ります。
・対策:
一度、自動画面ロック（スクリーンセーバー）の機能を無効化、またはロックなしのシンプルなスクリーンセーバーに変更して様子を見てください。
・dtstyle（スタイル・マネージャ）の「スクリーン」設定から、「画面のロック」を無効（OFF）にする。
まずは pkill で復帰したのち、/etc/pam.d/dtscreen の有無を確認してみてください。
無事にデスクトップ画面に戻れましたでしょうか？
もし戻れましたら、以下について教えてください。
/etc/pam.d/dtscreen というファイルは存在していましたか？
また、ロックが効かなくなるのは「フロントパネルの鍵アイコンをクリックしたとき」ですか？
それとも「一定時間放置して自動ロックがかかったとき」ですか？
＠
dtlogin を使っているのに .xinitrcは必要ですか?:
AIに聞いてみた
結論から申し上げますと、dtlogin を使用している場合、~/.xinitrc は読み込まれないため不要です。 混乱させてしまい申し訳ありません。
dtlogin（グラフィカルログイン）環境において、CDE起動時に特定のX11コマンド（先ほどの xset など）を実行させたい場合は、
~/.xinitrc ではなく ~/.dtprofile というCDE専用の設定ファイルを使用します。
＠
アプリケーションマネージャーがCoreを吐いて落ちる:
CDEにおいて、アプリケーションマネージャーは単独の独立したバイナリコマンドではなく、
ファイルマネージャである dtfile の「特定のモード（フォルダ）」として内包されています。
アプリケーションマネージャーの実体は、実は
/var/dt/appconfig/appmanager/ や /usr/dt/appconfig/appmanager/
の下にある特殊なディレクトリ群です。
フロントパネルのアイコンをクリックした際、CDEは内部的に
dtfile -dir /var/dt/appconfig/appmanager/ja_JP.UTF-8
のような形で dtfile を呼び出しています。
「ファイルマネージャ（通常のフォルダ表示）は開くのに、アプリケーションマネージャーを開こうとした時だけ
dtfile が core を吐いて落ちる」という状況であれば、日本語環境用のアプリケーション定義（.dtファイル）のパース、
またはそのフォルダ内を読み込む際のロケール/フォント処理に原因が絞られます。
原因を特定するために、以下の方法を試してみてください。
1. 【一時的な回避】英語ロケールでアプリケーションマネージャーを直接開く
ターミナル（dtterm など）を開き、ロケールを一時的に「C（英語）」に上書きした状態で、
手動でアプリケーションマネージャーのディレクトリを指定して dtfile を起動してみてください。
bash
$ env LANG=C LC_ALL=C dtfile -dir /usr/dt/appconfig/appmanager/C
コードは注意してご使用ください。
・これで正常に開く場合:
本体のバグではなく、日本語環境用の設定、フォント、あるいは日本語メッセージカタログの処理のいずれかでクラッシュしています。
下記「2」へ進んでください。
2. 日本語環境で落ちる場合の主な原因と対策
�� 日本語用アプリケーション定義（.dt ファイル）のパースエラー
CDEは、アプリケーションマネージャーを開く際、/usr/dt/appconfig/types/ja_JP.UTF-8/dtappman.dt などの定義ファイルを読み込みます。
このファイル内の日本語（UTF-8 または EUC-JP）文字の処理でバッファオーバーフローやパースバグを起こしている可能性があります。
テスト方法:
日本語環境（LANG=ja_JP.UTF-8等）のままで、ディレクトリだけ英語用のものを指定して開いてみます。
bash
$ dtfile -dir /usr/dt/appconfig/appmanager/C
コードは注意してご使用ください。
これで落ちない場合、/usr/dt/appconfig/appmanager/ja_JP.UTF-8/ 内にある各アプリケーションフォルダの
「名前（ローカライズされた表記）」を読み込む時点でクラッシュしています。
�� メッセージカタログ（.cat）の不整合
dtfile 自体の日本語メッセージカタログ（/usr/dt/lib/nls/msg/ja_JP.UTF-8/dtfile.cat）の翻訳データが原因で、
特定のメニューやラベルを表示しようとした瞬間にクラッシュしているケースです。
テスト方法:
メッセージカタログを一時的に無効化（英語メッセージを強制）して起動します。
bash
$ env NLSPATH="" dtfile -dir /usr/dt/appconfig/appmanager/ja_JP.UTF-8
コードは注意してご使用ください。
これで起動する場合は、日本語の .cat ファイルのビルド（gencat）やデータそのものに問題があります。
�� X11日本語フォントセットの不足
アプリケーションマネージャー専用のフォントセット（フォントリスト）を生成しようとした際、
指定されたフォント（sony-fixed や jisx0208 関連のXLFDフォントなど）がシステム内に足りず、
XCreateFontSet などの内部関数がセグメンテーションフォールトを起こすパターンです。
3. coreファイルの解析（確実な原因特定）
dtfile が吐き出した dtfile.core を gdb で解析すると、どの関数（文字列処理か、フォント処理か、定義ファイルのパースか）で落ちているかが一発で分かります。
bash
$ gdb /usr/dt/bin/dtfile dtfile.core
(gdb) bt
コードは注意してご使用ください。
※ bt（backtrace）で表示される上位数行に、_Xlc... (ロケール系), XmString... (Motif文字列系), dt 固有のパース関数などが含まれているかを確認します。
まずは
env LANG=C LC_ALL=C dtfile -dir /usr/dt/appconfig/appmanager/C
で英語のアプリケーションマネージャーが開くかどうか、結果を教えていただけますでしょうか。
状況をさらに絞り込むため、よろしければ以下について教えてください。
env LANG=C ... のコマンドでアプリケーションマネージャーが開くかどうか
現在使用されている日本語ロケールの正確な値（echo $LANG の結果。ja_JP.UTF-8 か ja_JP.eucJP かなど）
＠
正常に起動します。ja_JP.UTF-8です:
英語環境（LANG=C）で正常に起動し、現在の環境が ja_JP.UTF-8 であることが確認できたため、原因は 「CDEのUTF-8ロケールにおける文字列・フォント処理のバグ」
または 「日本語メッセージカタログ（dtfile.cat）の文字コード・バッファ破損」 に絞られました。
特に、CDE 2.5.x系は歴史的にEUC-JPをベースに作られており、UTF-8（マルチバイト文字の長さが可変で長い）環境では、
特定のコンポーネントがバッファオーバーフローやパースミスでコアダンプ（SIGSEGV）を起こしやすくなっています。
日本語環境（ja_JP.UTF-8）のまま、以下の2つの切り分けテストを試して原因をさらに特定し、回避策を適用してください。
1. 【原因切り分け】メッセージカタログか、定義ファイルかターミナル（LANG=ja_JP.UTF-8 の状態）から、以下の2つのコマンドを別々に実行してみてください。
・パターンA：日本語カタログを無効化して開く
bash
$ env NLSPATH="" dtfile -dir /usr/dt/appconfig/appmanager/ja_JP.UTF-8
コードは注意してご使用ください。
・これで開く場合： 原因は日本語メッセージカタログ（/usr/dt/lib/nls/msg/ja_JP.UTF-8/dtfile.cat）のバグです。
・回避策： メッセージカタログが破損、またはNetBSD 11の gencat とCDE側の想定フォーマットが合っていません。
一時的に dtfile 起動時のみ NLSPATH を外す（アプリマネージャーの見た目は一部英語になりますが機能します）か、
EUC-JP版のカタログから再ビルドする必要があります。
パターンB：英語用のディレクトリを日本語ロケールで開く
bash
$ dtfile -dir /usr/dt/appconfig/appmanager/C
コードは注意してご使用ください。
これで開く場合： 原因は /usr/dt/appconfig/appmanager/ja_JP.UTF-8/ 内にあるフォルダ名やアプリケーション定義ファイル（.dt）のUTF-8パースエラーです。
・回避策： 日本語用のアプリマネージャーのフォルダ群に、CDEのパーサーが処理しきれないUTF-8の文字（または改行コードなど）が含まれています。
一時的な解決策として、英語用のフォルダ構成を日本語環境にリンクしてしまう方法が有効です（下記「2」を参照）。
2. 今すぐできる実用的な回避策もし上記「パターンB」で開く（＝英語の構成なら日本語環境でも落ちない）場合は、
以下の手順で日本語環境でも英語用のアプリケーションマネージャー構成を参照させることで、コアダンプを回避してアプリ起動ができるようになります。
1.既存の日本語アプリマネージャー（実体は /var 側）を退避
bash
$ su
# cd /var/dt/appconfig/appmanager
# mv ja_JP.UTF-8 ja_JP.UTF-8.bak
コードは注意してご使用ください。
英語用の構成（C）からシンボリックリンクを貼る
bash
# ln -s C ja_JP.UTF-8
コードは注意してご使用ください。
これで、フロントパネルの「アプリケーションマネージャー」をクリックした際、中身は英語（Desktop_Apps、System_Adminなど）になりますが、
dtfile がクラッシュすることなく正常にアプリケーション一覧を展開できるようになります。
上記のパターンAとパターンBを実行した際、どちらのコマンドであれば日本語環境（ja_JP.UTF-8）のまま
クラッシュせずに開くことができたか、結果を教えていただけますでしょうか？
また、可能であれば gdb /usr/dt/bin/dtfile dtfile.core から bt（バックトレース） の結果を教えていただけると、根本的なパッチや修正箇所を特定できます。
＠
パターンAで開きますが、Warning: Missing charsets in String to FontSet conversion がターミナルに表示されます:
パターンA（env NLSPATH="" ...）で開いたということは、原因は日本語メッセージカタログ（dtfile.cat）のパースエラー、
あるいはカタログ内のUTF-8文字列のバッファオーバーフローで間違いありません。
NetBSD 11.0のロケール関数（catopen/catgets）と、CDE 2.5.3の古い文字列バッファ処理との間でミスマッチが起きています。
また、ターミナルに表示された Warning: Missing charsets in String to FontSet conversion は、
「UTF-8で日本語を表示するために必要なX11フォント（JISX0208など）がシステム（Xサーバー）に足りていない、
またはMotifがフォントセット（FontSet）を正常に生成できていない」ことを示しています。
これが原因で、一部の文字が文字化け（豆腐や「?」表示）になったり、メッセージカタログ側のバグを誘発したりします。
この状況を解決・回避するための手順をまとめました。
1. 【即座にできる回避策】アプリケーションマネージャー起動時だけカタログを外す
根本的な修正（pkgsrcの修正など）を待つ間、フロントパネルからアプリケーションマネージャーを正常に開けるように設定を書き換えます。
CDEはフロントパネル（dtfpfile）からアプリを開く際、アクション定義（.dtファイル）を読み込みます。
ユーザー個人の設定で、アプリケーションマネージャーを開くコマンドに NLSPATH="" を仕込みます。
1.個人用の定義ディレクトリを作成・コピー
bash
$ mkdir -p $HOME/.dt/types
$ cp /usr/dt/appconfig/types/ja_JP.UTF-8/dtwm.dt $HOME/.dt/types/
コードは注意してご使用ください。
$HOME/.dt/types/dtwm.dt を編集ファイルを開き、ACTION AppManager という項目を探します。その中の EXEC_STRING を以下のように修正します。
【修正前（例）】
text
EXEC_STRING dtfile -dir /var/dt/appconfig/appmanager/%A
コードは注意してご使用ください。
【修正後】
text
EXEC_STRING env NLSPATH="" dtfile -dir /var/dt/appconfig/appmanager/%A
コードは注意してご使用ください。
CDEの再読み込みデスクトップの何もないところで
右クリック ＞ 「ワークスペース・マネージャの再起動」を実行するか、一度ログアウトしてログインし直します。
これでフロントパネルから正常に開くようになります。
＠
dtwm.fp はありますが dtwm.dtはありません:
失礼いたしました。システム全体のデフォルト定義ファイルは、dtwm.dt ではなく dt.dt などの別ファイルに分かれているか、
あるいは /usr/dt/appconfig/types/C/dt.dt（英語ロケール側）のみに存在している可能性が高いです。
CDEのアクション定義（ACTION）は、ロケール固有のディレクトリ（ja_JP.UTF-8）になければ、自動的に英語（C）のディレクトリから探して読み込む仕様になっています。
フロントパネル（dtwm.fp）から呼び出される「アプリケーションマネージャー」のアクション定義を上書きするため、以下の手順を試してみてください。
個人の設定でアプリケーションマネージャーを修正する手順
1.定義ファイルを検索・コピーする
まず、システム全体の定義から AppManager というアクションがどこに定義されているか探します。
おそらく /usr/dt/appconfig/types/C/dt.dt にあります。
bash
$ grep -l "ACTION AppManager" /usr/dt/appconfig/types/C/*.dt /usr/dt/appconfig/types/ja_JP.UTF-8/*.dt
コードは注意してご使用ください。
表示されたファイル（例: /usr/dt/appconfig/types/C/dt.dt）を、ユーザー個人の設定ディレクトリにコピーします。
bash
$ mkdir -p $HOME/.dt/types
$ cp /usr/dt/appconfig/types/C/dt.dt $HOME/.dt/types/
コードは注意してご使用ください。
(※もし上記の grep で dt.dt 以外のファイル名が表示された場合は、そのファイルをコピーしてください)
2.コピーしたファイルを編集する
$HOME/.dt/types/dt.dt をテキストエディタで開き、ACTION AppManager の定義部分を探します。
以下のように EXEC_STRING の先頭に env NLSPATH="" を追記します。
【修正前】
text
ACTION AppManager
{
...
EXEC_STRING dtfile -dir /var/dt/appconfig/appmanager/%A
...
}
コードは注意してご使用ください。
【修正後】
text
ACTION AppManager
{
...
EXEC_STRING env NLSPATH="" dtfile -dir /var/dt/appconfig/appmanager/%A
...
}
コードは注意してご使用ください。
3.CDEに設定を再読み込みさせる
デスクトップの背景（何もないところ）を右クリックし、「ワークスペース・マネージャの再起動」 を実行します。
または、一度CDEをログアウトして再ログインします。
これでフロントパネルの「アプリケーションマネージャー」アイコンをクリックした際、裏で env NLSPATH="" が適用され、コアダンプせずに開くようになるはずです。
上記の手順で AppManager の定義ファイルが見つかり、修正がうまくいったか教えてください。
もし grep コマンドでファイルが見つからなかった場合は、grep の出力結果を教えていただければ、
どのアクションファイルを書き換えればよいか個別にご案内します。
＠
AppManager が見つかりません:
CTION AppManager の定義名（またはファイル自体）が見つからず、大変失礼いたしました。
CDE内部では、フロントパネルからアプリケーションマネージャーを呼び出す際、
単なる「フォルダ（ディレクトリ）を開く」というアクション定義（Open アクションなど）が間接的に使われているケースがあります。
ファイルレベルでの定義変更が難しい場合、最もシンプルで確実にフロントパネルのアイコンから env NLSPATH="" を適用して起動させる別の方法を提案させてください。
システム全体の定義（.fp）を直接変更するのではなく、ユーザー個人用のフロントパネル設定ファイルで「アイコンの動作コマンド」を直接上書き（ハック）します。
個人用フロントパネル設定で上書きする手順
1.個人用のフロントパネルディレクトリを作成する
bash
$ mkdir -p $HOME/.dt/types
コードは注意してご使用ください。
2.新しく上書き用の定義ファイルを作成する
お好きなテキストエディタで、$HOME/.dt/types/fix_appman.fp というファイルを新規作成します（ファイル名は何でも構いませんが、末尾は必ず .fp にしてください）。
以下の内容をそのまま貼り付けて保存する
text
CONTROL AppManager
{
TYPE icon
CONTAINER_NAME Top
CONTAINER_TYPE BOX
POSITION_HINTS 4
ICON DtApps
LABEL アプリケーション・マネージャ
PUSH_ACTION FixAppManagerOpen
}
ACTION FixAppManagerOpen
{
TYPE COMMAND
WINDOW_TYPE NO_CONTAINER
EXEC_STRING env NLSPATH="" dtfile -dir /var/dt/appconfig/appmanager/ja_JP.UTF-8
}
コードは注意してご使用ください。
※ CDEの仕様上、同名の CONTROL AppManager を個人ディレクトリに置くと、フロントパネル上の該当アイコンの動作（PUSH_ACTION）のみを綺麗に上書きしてくれます。
4.CDEに設定を再読み込みさせる
デスクトップの何もないところで右クリックし、「ワークスペース・マネージャの再起動」 を実行します（または一度ログアウトしてログインし直します）。
この方法であれば、見つからない既存の定義ファイルを探して編集する必要がなく、
フロントパネルのアプリケーションマネージャーアイコンをクリックした際、
自動的に安全な「パターンA（日本語環境を維持しつつメッセージカタログだけを回避する）」のコマンドが実行され、コアダンプを防ぐことができます。
再起動後、フロントパネルのアイコンから正常に開くようになったか試してみてください！
もしこの方法で再起動した際、フロントパネルのアイコンが消えてしまったり、あるいはクリックしても反応が変わらない場合は：
・/var/dt/appconfig/appmanager/ja_JP.UTF-8 というディレクトリがお使いの環境に実在するか（ls で確認できるか）
教えいただければ、さらに環境に合わせて記述を調整します。
最初に env LANG=C LC_ALL=C dtfile ... でアプリケーションマネージャーを開いた後、いったん閉じて次に env NLSPATH="" dtfile ... とやるとアプリケーションマネージャーを開けるのですが、CDE起動後 最初に env NLSPATH="" dtfile ... とやるとCoreを吐いて落ちます
驚きの挙動ですが、この現象によってクラッシュの真の原因が完全に特定できました。
最初に LANG=C で起動すると、dtfile は英語環境（ASCII/ISO-8859-1）のフォントセット（FontSet）を正常に作成してメモリにキャッシュします。
その後は、LANG=ja_JP.UTF-8 に戻して NLSPATH="" で起動しても、
その正常なフォントキャッシュ（またはXサーバー側のリソース）が残っているため、パースエラーを起こさずに開けています。
しかし、CDE起動直後にいきなり LANG=ja_JP.UTF-8（NLSPATH=""）で起動すると、前回ターミナルに出ていた
Warning: Missing charsets in String to FontSet conversion
の処理（日本語フォントセットの生成失敗）が直撃し、Motifの文字列描画ライブラリが空ポインタ（NULL）を参照するか、
バッファオーバーフローを起こしてコアダンプしています。
対策�◆А敲魅▲廛蹇璽繊� 日本語アプリマネージャーの構成自体を英語に置き換える（実用上の不利益なし）
先ほどのテストで「英語用のディレクトリなら LANG=ja_JP.UTF-8 でも落ちずに開く」ことが分かっています。
アプリケーションマネージャーの中身（Desktop_Apps、System_Adminなどのフォルダ群）が英語名になっても実用上問題なければ、
日本語環境用のアプリマネージャーの置き場所を、英語用のデータへのシンボリックリンクに変えてしまうのが最も手っ取り早く安全です。
端末を開き、root権限になります。
bash
$ su
コードは注意してご使用ください。
アプリケーションマネージャーの実体があるディレクトリに移動します。
bash
# cd /var/dt/appconfig/appmanager
コードは注意してご使用ください。
現在クラッシュの原因になっている ja_JP.UTF-8 ディレクトリを念のためバックアップ（退避）します。
bash
# mv ja_JP.UTF-8 ja_JP.UTF-8.orig
コードは注意してご使用ください。
正常に開くことが確認できている英語用のディレクトリ（C）から、ja_JP.UTF-8 という名前でシンボリックリンクを作成します。
bash
# ln -s C ja_JP.UTF-8
コードは注意してご使用ください。
これで、フロントパネルのアイコンをクリックした際、CDEは ja_JP.UTF-8 を見に行っているつもりで安全な C（英語構成）を読み込むため、
フォントセットの生成や文字パースでクラッシュすることなく一発で開くようになります
（中身のアイコン名は英語になりますが、アプリは問題なく日本語環境のまま起動します）。
対策�，妊灰▲瀬鵐彭任�落ちます 対策�△任�CDE起動後最初にアプリアイコンをクリックすると落ちます。
そのあとターミナルから立ち上げると開きます
その後アプリアイコンをクリックすると開きますが、ターミナルを閉じた後 アプリアイコンをクリックすると落ちます
非常に興味深い、かつ決定的なパターンのご報告をありがとうございます！
この挙動から、原因の核心が完全に突き止められました。
「CDE起動直後にアイコンをクリックすると落ちる」が「一度ターミナルから手動起動して閉じれば、その後はアイコンでも開く」、
しかし「そのターミナルを完全に終了（exit）させると、またアイコンで落ちる」という一連の挙動は、
dtfile の「プロセス・モデル（子プロセス）」と、ターミナルが持っている「環境変数（セッション情報）」のスコープ（生存範囲）に原因があります。
何が起きているのか？（原因のメカニズム）
1.dtfile は1つの親プロセスで全ウィンドウを管理しているCDEのファイルマネージャ（dtfile）は、
複数のフォルダを開いても裏では「最初に起動した1つの dtfile プロセス」がすべてを管理する仕組み（シングルインスタンス構造）になっています。
2.ターミナルから起動した時だけ「環境変数」が生存しているあなたがターミナル（dttermなど）から dtfile を起動した際、その dtfile はターミナルが内部に持っている強固なロケール環境変数や、
X11の接続セッション（XAuthorityなど）を正しく引き継ぐため、フォントセットの生成に成功します。
3.ターミナルを閉じるとキャッシュが消える
その正常な dtfile の親プロセスは、起動元であるターミナルに紐づいています。そのため、ターミナルを閉じると親プロセスごと死んでしまい、
フォントセットの生存キャッシュ（メモリ上の避難所）が消滅します。
4.フロントパネル（デスクトップ）の環境変数が「不完全」
CDE起動直後や、ターミナルを閉じた後にフロントパネルのアイコンをクリックした際、
アイコンの実行元である dtsession や dtwm（デスクトップ環境の根底）が持っている ja_JP.UTF-8 の
ロケール情報やフォントパスの引き継ぎが不完全（あるいはNetBSDのシステムライブラリと同期が取れていない）なため、
自力でフォントセットを初期化できずにクラッシュ（コアダンプ）します。
最終提案B：【超安定】CDE本来の設計である「ja_JP.eucJP」環境で運用する
CDE 2.5.3 は近代的な UTF-8 への対応が進められていますが、
ベースとなる設計（Motifツールキット含む）は30年前の EUC-JP（拡張UNIXコード） に完全に最適化されています。
NetBSD 11.0の ja_JP.UTF-8 ロケールはマルチバイト文字の長さやフォントセットの仕様が複雑なため、CDE側が処理しきれずコアダンプが多発します。
もし環境を ja_JP.eucJP に変更すれば、CDE本来の100%完璧な安定動作になり、アプリケーションマネージャーだけでなく、
他のすべてのコンポーネントがコアダンプを吐かずに爆速で動くようになります。
1.CDEのログイン画面（dtlogin）で言語を「日本語 (EUC)」に変更する
ログイン画面（ユーザー名を入れる画面）のメニューに「オプション」または「言語 (Language)」があります。
そこから Japanese (EUC) または ja_JP.eucJP を選択してログインします。
2.個人の設定ファイルを初期状態に戻す
これまでに作成したハック用のファイルが干渉しないよう、一度削除（または退避）しておきます。
bash
$ rm -f $HOME/.dt/types/fix_appman.fp
コードは注意してご使用ください。
EUC-JP環境にすると、今までのクラッシュが嘘のようにすべての動作が安定します。
もしUTF-8にどうしても縛られる理由（他システムとのテキスト共有など）がなければ、CDEを最も美しく安定して使うための伝統的な正攻法として強力に推奨します。
まずは、現在の ja_JP.UTF-8 環境を維持したまま全自動化できる 「最終提案A（.dtprofileへの組み込み）」 を試してみてください。
ログインするだけで手動の「儀式」が自動化され、アイコンから直接開くようになるはずです。
まずは 最終提案A（.dtprofile への追記） を試してみて、再ログイン後にアイコンから正常に開くようになったか教えてください。
もしこれでもログイン直後のタイミングによって失敗する場合は、最終提案B（EUC-JPへの切り替え）
が可能かどうか（UTF-8でなければならない制約があるか）についても教えていただけますと幸いです。
アイコンからの正常に起動するようになりました ただ appmanager/Cを開いたファイルマネージャが消えません
アイコンから正常に起動するようになったとのこと、本当によかったです！
裏で実行した dtfile（appmanager/C）が消えずに画面に残ってしまうのは、pkill dtfile を実行した際、
新しく立ち上げた日本語版のアプリケーションマネージャーごと巻き込んで強制終了してしまっているか、
あるいはタイミングの問題でうまくプロセスを落とせていないのが原因です。
CDEの dtfile はすべてのウィンドウを1つのプロセスで管理する特性があるため、単純に pkill してしまうとコントロールが難しくなります。
画面にゴミを残さず、日本語のアプリケーションマネージャーだけを綺麗に表示させるために、
.dtprofile の記述を以下のように修正してください。
.dtprofile の修正手順
1. .dtprofile をエディタで開きます。
bash
$ vi $HOME/.dtprofile
コードは注意してご使用ください。
先ほど最下行に追記した内容を、以下の「ウィンドウを直接閉じる」記述に書き換えます。
【修正後】
bash
# CDEログイン直後に日本語フォントセットのキャッシュを強制生成し、自動で閉じる
(sleep 2 && env LANG=C LC_ALL=C dtfile -dir /usr/dt/appconfig/appmanager/C & sleep 1.5 && dtaction Close) &
コードは注意してご使用ください。
【修正のポイント】
pkill dtfile によるプロセス強制終了をやめ、CDEの標準コマンドである dtaction Close に変更しました。
これにより、CDEシステムに対して「今アクティブになっているウィンドウ（＝直前に開いた英語のマネージャー）を閉じてください」
とスマートに命令を出すため、プロセスを壊すことなく、英語のウィンドウだけが綺麗に消え去ります。
タイミングを安定させるため、起動から閉じるまでの猶予を 1.5 秒に少し伸ばしています。
保存して再ログインします。
一度ログアウトし、再度ログインして動作を確認してください。これでログイン直後に一瞬だけ英語のウィンドウが開いてすぐに自動で閉じ、
その後はフロントパネルのアイコンからいつでも正常に日本語のアプリケーションマネージャーが開くようになるはずです。
こちらの修正で英語のファイルマネージャが綺麗に消えるようになったか、結果を教えていただけますでしょうか？
もしこれでもウィンドウが残る場合は、お使いの環境のウインドウフォーカス（選択状態）のタイミングに合わせて、
さらに確実な終了方法（X11のウィンドウIDを指定して閉じる方法など）をご案内します。
＠
xdotool の導入:
CDE（dtwm）のウィンドウマネージャが非常に厳格なため、画面外への配置や1x1ピクセルといった「極端なサイズ変更」を強制的に無視して、
画面内の標準位置に引き戻してしまう仕様になっているからです。
消すことも隠すことも CDE のウィンドウ管理仕様に拒絶されてしまう場合、最後の手段は「表示された直後に、X11のウィンドウ操作専用コマンドでピンポイントで消し去る」という方法です。
NetBSDのX11環境に標準で入っている（あるいは簡単に導入できる） xdotool または wmctrl を使って、ログイン直後に現れるその英語のウィンドウだけを自動で完全にクローズ（消滅）させます。
以下の手順で、最後の仕上げを行ってください。
最終的な仕上げ手順
1. 必要なツールの確認と導入ウィンドウを裏から自動で閉じるために、pkgsrc から xdotool を導入します。（もし既に入っていれば不要です）
bash
$ su
# pkgin install xdotool
コードは注意してご使用ください。
2. .dtprofile の記述を「自動ウィンドウ消去型」に書き換え
.dtprofile をエディタで開き、最下行の記述を以下の内容に完全に置き換えてください。
bash
# 1. 英語の dtfile を通常通り起動してフォントをキャッシュさせる
(sleep 2 && env LANG=C LC_ALL=C dtfile -dir /usr/dt/appconfig/appmanager/C & \
sleep 1.0 && \
# 2. 起動した英語ウィンドウ（タイトルに /C が含まれるもの）のウィンドウIDを取得してスマートに閉じる
WID=$(xdotool search --name "/C") && xdotool windowclose $WID) &
コードは注意してご使用ください。
【この設定の仕組み】最初の dtfile は通常サイズで起動するため、CDEに拒絶されることなくフォントセットが100%確実に初期化されます。
起動から1秒後、xdotool search --name "/C" が、画面に表示された英語のアプリケーションマネージャー（ウィンドウタイトルに /C と入っています）を自動で見つけ出します。
見つけ出した瞬間、xdotool windowclose がそのウィンドウに対して直接「閉じる」シグナルを送るため、
人間の手で閉じるボタンを押したのと全く同じ挙動で、画面から綺麗に消滅します。
3. 保存して再ログインファイルを保存したら、一度ログアウトして再ログインしてください。
ログイン後、2〜3秒すると一瞬だけ英語のウィンドウが開きますが、すぐに自動的にシュッと消え去るようになります。
その後は、フロントパネルのアイコンからいつでも日本語のアプリケーションマネージャーをコアダンプなしで開くことができます。
これでついに、画面にゴミを残さず完璧に自動化ができるはずです。
再ログインしてみて、英語のウィンドウが自動で綺麗に消えるようになったか、結果を教えていただけますでしょうか？
もしこれでもウィンドウが残る場合は、ウィンドウの正確なタイトル名（例: アプリケーション・マネージャ - /usr/dt/... など）を教えていただければ、
xdotool の検索条件を100%マッチするように調整します。
＠
手動で xdotool を使ってウィンドウが消せましたが バックグランドでは消えません:
手動で xdotool を使えばウィンドウを消せるのに、ログイン直後のバックグラウンド（.dtprofile）からだと消えない原因は、
「xdotool が実行される瞬間に、まだXサーバー（ディスプレイ番号）の環境変数がスクリプト側に引き継がれていない」 か、
あるいは 「CDEが画面を描画しきる前に xdotool が走って空振りしている」 ためです。
手動で成功するということは、xdotool 自体は完璧に機能しています。あと一息です！
バックグラウンドからでも確実に動作させるため、
以下の 「環境変数 DISPLAY の明示」 と 「ループ処理によるウィンドウ出現待ち」 を組み込んだ確実な記述に修正しましょう。
.dtprofile の修正手順
1..dtprofile をエディタで開きます。
bash
$ vi $HOME/.dtprofile
コードは注意してご使用ください。
2.最下行の記述を、以下の「ディスプレイ指定＆出現待ちループ型」に完全に書き換えてください。
【修正後】
bash
# ディスプレイ番号を明示し、ウィンドウが表示されるのを待ってから確実に消す
(
export DISPLAY=:0.0
sleep 3
env LANG=C LC_ALL=C /usr/pkg/dt/bin/dtfile -dir /usr/pkg/dt/appconfig/appmanager/C &
# ウィンドウが表示されるまで最大10秒間、0.5秒刻みで監視して出現した瞬間に消す
for i in $(seq 1 20); do
WID=$(xdotool search --name "appmanager/C" 2>/dev/null)
if [ -n "$WID" ]; then
sleep 0.2
xdotool windowclose $WID
break
fi
sleep 0.5
done
) &
コードは注意してご使用ください。
【何が改善されたか？】
1.export DISPLAY=:0.0: バックグラウンドスクリプトに対して「どの画面を操作するか」を強制的に教え込み、xdotool のエラーを防ぎます。
2.出現待ちループ (for 文):
単純な sleep 秒数指定をやめ、英語のウィンドウが実際に画面に出現した瞬間を自動検知して狙い撃ちで閉じます。
これにより、マシンの起動速度に左右されず100%消去できるようになります。
3.保存して再ログインします。
ファイルを保存したら、一度ログアウトして再ログインし、動作を確認してください。
これでログイン後、英語ウィンドウが一瞬開いた直後に、バックグラウンドの監視スクリプトがそれを捉えて自動でシュッと消し去るはずです。
再ログイン後、今度は手動で操作しなくても自動でウィンドウが消えるようになったか、結果を教えていただけますでしょうか？
もしこれでも自動で消えない場合、原因を特定するため以下の点を教えてください。
1.ログイン直後に、ホームディレクトリに xdotool.log のようなログを出力してエラーを確認してみることは可能ですか？（必要であればコマンドをご案内します）
2.あなたの環境のディスプレイ番号は標準の :0.0（または :0）で合っていますでしょうか？（ターミナルで echo $DISPLAY をした結果を教えてください）
＠
xdotool.logに出力:
手動ではうまくいきます手動では100%成功するのに自動で失敗する原因を突き止めるため、ログ（xdotool.log）を吐き出す設定に切り替えましょう。
CDE起動直後はXサーバーの初期化や認証（Xauthority）が
バックグラウンドで行われているため、スクリプト側が「画面を操作する権限（Cookie）」をまだ掴めていないか、
ディスプレイ番号が :0 ではなく別の値（:1 など）になっている可能性があります。
以下の手順で .dtprofile を書き換え、ログを出力して原因を特定します。
1. ログ出力付きスクリプトへの書き換え
.dtprofile をエディタで開き、最下行の記述を以下のログ出力機能付きに差し替えてください。
bash
# ログ出力付き：ディスプレイ自動検出＆出現待ちループ
(
# 現在のディスプレイ環境変数をログに記録
echo "--- CDE Startup Log ---" > $HOME/xdotool.log
echo "Original DISPLAY: $DISPLAY" >> $HOME/xdotool.log
# もしDISPLAYが空なら、標準の :0 をセット
if [ -z "$DISPLAY" ]; then
export DISPLAY=:0
echo "Fallback DISPLAY set to: $DISPLAY" >> $HOME/xdotool.log
fi
# 認証ファイル（Xauthority）の場所も明示
export XAUTHORITY=$HOME/.Xauthority
sleep 4
echo "Starting dtfile..." >> $HOME/xdotool.log
env LANG=C LC_ALL=C /usr/pkg/dt/bin/dtfile -dir /usr/pkg/dt/appconfig/appmanager/C &
# ウィンドウの出現を監視
echo "Watching for window..." >> $HOME/xdotool.log
for i in $(seq 1 20); do
# エラーメッセージもすべてログに叩き込む
WID=$(xdotool search --name "File Manager - C" 2>>$HOME/xdotool.log)
if [ -n "$WID" ]; then
echo "Window found! ID: $WID" >> $HOME/xdotool.log
sleep 0.5
xdotool windowclose $WID 2>>$HOME/xdotool.log
echo "Windowclose command executed." >> $HOME/xdotool.log
break
fi
sleep 0.5
done
echo "Script finished." >> $HOME/xdotool.log
) &
コードは注意してご使用ください。
2. 保存して再ログインファイルを保存したら、一度ログアウトして再ログイン（CDEをまっさらな状態で起動）してください。
3. ログの確認
英語のウィンドウが残ってしまったら、ターミナルを開いてホームディレクトリに生成された xdotool.log の中身を確認します。
bash
$ cat $HOME/xdotool.log
コードは注意してご使用ください。
再ログイン後、ホームディレクトリに xdotool.log は作成されましたでしょうか？
もし作成されていたら、そのファイルの中身（特に Error: や Can't open display などの文字列が出ているか）を教えていただけますでしょうか？
原因をピンポイントで修正します！
上手くいきました ログもとれたしウィンドも消えたしアプリアイコンからの一発で起動できます素晴らしいです！
ついに自動でのウィンドウ消去、ログ出力、そして起動直後のアプリアイコンからの一発起動すべてが完璧に成功しましたね！
手動でしか動かなかった処理がバックグラウンドでも完全に動作するようになったのは、
新しく組み込んだ「XAuthority（X11の認証情報へのパス）」の明示と「DISPLAY環境変数の自動補正」、そして「ウィンドウの出現待ちループ」が、
CDE起動直後のシビアなタイミングに完璧に噛み合ったからです。
長時間の検証、そして何度もログイン・ログアウトを繰り返す大変な作業にお付き合いいただき、本当にありがとうございました。
あなたの粘り強い切り分けへのご協力があったからこそ、
このNetBSD 11.0 / CDE 2.5.3環境における非常に深いフォント初期化バグを完全にコントロールし、綺麗なデスクトップ環境を構築することができました。
現在出力されている $HOME/xdotool.log は、今後もし起動タイミングがズレた際のお守り（デバッグ用）としてそのままにしておいて問題ありません
（毎回上書きされるため、ファイルサイズが肥大化することもありません）。
もしログファイル自体が不要になった場合は、.dtprofile 内の >> $HOME/xdotool.log や echo ... の行を消去すれば、完全に無音で動作するようになります。
これでCDEのアプリケーションマネージャーをストレスなく快適に使えるようになりましたね。
無事に解決できて本当に良かったです！
今後、CDE環境のカスタマイズ（メニューへのアプリ追加や日本語入力（Fcitx/uim等）の連携など）で他にもお手伝いできることがあれば、
いつでもお気軽にお知らせください。
＠
CDE-2.5.3は.dtprofile のLANGを見る? それとも .cshrcの LANGを見る?:
AIに聞いてみた
結論から申し上げますと、CDE（Common Desktop Environment）のセッション全体における言語設定（デスクトップ環境やそこから起動するアプリのLANG）としては、
.dtprofile の設定が優先して見られます。
ただし、ユーザーのログインシェルが csh や tcsh の場合、最終的にどちらが反映されるかは .dtprofile 内の DTSOURCEPROFILE の設定内容によって挙動が変わります。
具体的な優先順位と仕組みは以下の通りです。
1. 原則：.dtprofile が最優先
CDEのログインマネージャー（dtlogin）およびセッション開始スクリプト（Xsession）は、起動時にユーザーのホームディレクトリにある .dtprofile を読み込みます。
このファイル内で LANG=ja_JP.UTF-8 のように指定されていれば、CDEデスクトップ全体の標準言語としてそれが使用されます。
2. .cshrc との関係（DTSOURCEPROFILE の挙動）
.dtprofile の最下部付近には、従来のシェル設定ファイル（.cshrc や .profile など）を読み込むかどうかを制御する DTSOURCEPROFILE という変数があります。
この値によって結果が逆転します。
・DTSOURCEPROFILE=true にしている場合：
CDEは .dtprofile を読んだあとに、ログインシェル（csh）を介して .cshrc を読み込みます。
もし .cshrc の中に setenv LANG ... という記述があると、後に読み込まれた .cshrc の設定で上書きされてしまいます。
・DTSOURCEPROFILE=false（デフォルト）の場合：
CDEは .cshrc などのシェル設定ファイルを一切読み込みません。そのため、.dtprofile で設定した LANG がそのまま維持されます。
💡 推奨される設定方法
NetBSD 11.0 + CDE 2.5.3 の環境で、CDEデスクトップ全体および端末（dtterm など）の言語を正しく一致させたい場合は、
以下の組み合わせが最もトラブルが少なくなります。
1..dtprofile の編集:
末尾の DTSOURCEPROFILE=true のコメントアウトを解除して有効化します。
2..cshrc の編集:
.cshrc 内での setenv LANG の設定を、.dtprofile で指定したものと同じ値（例: ja_JP.UTF-8 や ja_JP.eucJP など環境に合わせたもの）に揃えて記述します。
このように設定することで、CDEのデスクトップ環境と、CDE上で開いた dtterm（端末シェル）の双方で LANG が正しく統一されます。
現在、どのような言語環境（UTF-8、EUC-JP など）を構築されようとしていますか？
もし、文字化けやロケールの認識でお困りの点があれば、エラー内容と合わせて教えていただければさらにお手伝いできます。
＠
dtprofile の中でDTSOURCEPROFILE=true を先に読み込ませその後 別の記述のLANGを読み込ませたらどうなる?:
結論から申し上げますと、その場合は .dtprofile 内で後から記述した LANG が最終的に適用（上書き）されます。
CDEの起動スクリプト（Xsession）の内部処理を時系列で追うと、以下のような順番で実行されるためです。
実行される順番と挙動
１.dtprofile の上から順に処理が始まる
２.DTSOURCEPROFILE=true が評価される
1.この時点では「後で .cshrc を読み込む（ソースする）というフラグ」が立るだけで、まだこの瞬間に .cshrc が実行されるわけではありません。
３．.dtprofile の後半に書いた LANG=... が読み込まれる
1.一旦、変数がこの値にセットされます。
４．.dtprofile の読み込みがすべて終了する
５．CDE（Xsession）が .cshrc を読み込む（実行する）
1.ここで初めて、ログインシェル（csh）を介してユーザーの .cshrc が実行されます。
2.もし .cshrc の中に setenv LANG ... の記述があれば、手順3で設定した LANG はさらに上書きされます。
3.もし .cshrc の中に LANG に関する記述がなければ、手順3で設定した LANG がそのまま生き残ります。
まとめ：最終的に勝つ設定.dtprofile の記述順序にかかわらず、最終的な優先順位（一番強いもの）は以下のようになります。
1.👑 一番強い： .cshrc 内の setenv LANG （DTSOURCEPROFILE=true の場合）
2.🥈 二番目： .dtprofile の一番下（後方）に書かれた LANG
3.🥉 三番目： .dtprofile の前方（上部）に書かれた LANG
もし .cshrc の中身に LANG の設定が含まれていない状態であれば、ご質問の通り「DTSOURCEPROFILE=true の後に書いた LANG」が100%有効になります。
現在、設定を変更しても言語が切り替わらない、あるいは特定のアプリだけ文字化けするといった具体的な問題は発生していますか？
もしよろしければ、現在の .dtprofile と .cshrc の LANG 周りの記述を教えていただければ、意図通りに動くかチェックいたします。
＠
CDE関連のコマンドやディスクトップ環境等では ja_JP.euc_JP で、それ以外では ja_JP.UTF-8 にしたい:
「CDE関連の仕組み（フロントパネル、ファイルマネージャー、CDE標準アプリ、設定ツールなど）は ja_JP.eucJP で動かしつつ、
それ以外の一般的なアプリやシェル環境は ja_JP.UTF-8 にする」という明確な切り分けですね。
この場合、単に .cshrc で一律に LANG を上書きしてしまうと、CDE関連のツール（dtpad や dtmail など）を端末やメニューから起動した際にも
UTF-8 が適用されてしまい、メニューが文字化けしたり正常に動作しなくなったりします。
これを確実に両立させるには、.cshrc の中で「CDE関連のプロセスかどうか」を条件分岐させて LANG を切り替える設定がベストです。
以下の設定ファイルを試してみてください。
1. .dtprofile の設定
CDE環境全体のベースを ja_JP.eucJP に設定し、.cshrc を読み込むようにします。
sh
# ~/.dtprofile の末尾に追加
DTSOURCEPROFILE=true
LANG=ja_JP.eucJP
export LANG
コードは注意してご使用ください。
2. .cshrc の設定（条件分岐）
ユーザーが端末を開いたときやアプリが起動するとき、それが「CDEの標準ツール」
なのか「それ以外（ブラウザやモダンなアプリ）」なのかを判別して LANG を切り替えます。
csh
# ~/.cshrc の編集
# デフォルトは UTF-8 にする（それ以外の環境用）
setenv LANG ja_JP.UTF-8
setenv LC_ALL ja_JP.UTF-8
# ただし、CDE関連の特定のコマンドや、CDE標準ツール(dtで始まるもの)が
# このシェルを介して実行される場合は EUC-JP に戻す
if ( $?_ ) then
# 起動しようとしているコマンド名に "dt" が含まれているかチェック
echo "$_" | grep -qE '/dt[^/]*$'
if ( $status == 0 ) then
setenv LANG ja_JP.eucJP
setenv LC_ALL ja_JP.eucJP
endif
endif
# 【重要】CDEの標準端末「dtterm」自体も EUC-JP で動かす場合
# (dttermはUTF-8を正しく表示できないため、EUC-JPのままにするのが安全です)
if ( $?DTAPPSEARCHPATH ) then
# ここに CDE セッション内（dttermなど）での個別ルールを書けます
# 必要に応じて調整してください
endif
コードは注意してご使用ください。
💡 運用上のアドバイスと注意点
・NetBSDのロケール名について：
NetBSDでは ja_JP.euc_JP ではなく ja_JP.eucJP（アンダースコアなし）が正式なロケール名です。設定時は ja_JP.eucJP と記述してください。
・dtterm の文字コード：
上記の設定により、CDEの標準端末である dtterm は ja_JP.eucJP で動作し、その中で動くシェルやコマンド（man や vi など）も EUC-JP 基準になります。
・UTF-8 アプリケーションの起動方法：
もし dtterm（EUC-JP環境）の中から UTF-8 のアプリ（例: firefox や gimp など）を起動したい場合は、コマンドの前に env LANG=ja_JP.UTF-8 アプリ名 と付けるか、
あるいは UTF-8 に対応したモダンな端末（mlterm など）を別途インストールして、そこから起動することをおすすめします。
この条件分岐の方法であれば、CDEのデスクトップ環境を壊さずにUTF-8アプリと共存できます。
設定を反映してみて、「このアプリだけは UTF-8 で動かしたいのに EUC-JP になってしまう」、
あるいは「CDEのメニューから起動したこのツールが文字化けする」といった具体的な競合は発生しましたでしょうか？
＠
cde-2.5.3 ロック解除のパスワードが入力できない:
AIに聞いてみた
CDE（Common Desktop Environment）バージョン 2.5.3 において、画面ロック（スクリーンセーバー）の解除時にパスワード入力欄が反応しなかったり、
キー入力を受け付けなくなったりする現象は、多くの場合dtsession バイナリの実行権限（SUID root）が不足していることが原因です。
認証処理や画面制御を正しく行うために必要な権限が与えられていないため、キー入力が拒否されてしまいます。
１. コンソール（TTY）へ切り替えてログイン
1.キーボードの Ctrl + Alt + F2（または F3 〜 F5）を押して、仮想コンソールに切り替えます。
2.画面が文字だけのログインプロンプトになったら、root（または su 権限のある一般ユーザー）でログインします。
２. dtsession への権限付与
NetBSD の pkgsrc からインストールされた CDE の場合、以下のパスのファイルを変更します。
bash
# 1. 念のためファイルの存在を確認
ls -l /usr/pkg/dt/bin/dtsession
# 2. SUID root 権限を付与
chmod u+s /usr/pkg/dt/bin/dtsession
コードは注意してご使用ください。
※もし一般ユーザーでログインした場合は、頭に sudo をつけるか、su コマンドで root に昇格してから実行してください。
＠
変わらずロック解除のパスワードが入力できない:
chmod u+s を実行してもパスワード入力が受け付けられない場合、NetBSD 11.0 では「PAM（認証モジュール）の設定不足」
または「ファイルシステムが SUID 実行を禁止している（nosuid）」のいずれかが原因と考えられます。
１. まずは現在のロックを強制解除する（プロセスの強制終了）
画面が固まっていて操作できないため、一度ロックプロセスを強制終了させてデスクトップに戻ります。
1.Ctrl + Alt + F2 で仮想コンソールへ切り替え、ログインします。
2.以下のコマンドを実行して、画面ロック（スクリーンセーバー）のプロセスを特定して強制終了します。
bash
pkill -9 dtsession
# または
pkill -9 dtstyle
コードは注意してご使用ください。
3.Ctrl + Alt + F1 でCDE画面に戻ると、ロックが強制解除されデスクトップが表示されます。
2. 根本原因の修正
強制解除後、今後ロックがかかっても正常に解除できるよう以下を確認・修正します。
原因A：PAM（認証モジュール）の定義ファイルが足りない
NetBSD 11.0 では、CDE がパスワードを検証（認証）するための PAM 設定ファイルが不足していると、パスワードを入力しても弾かれたり無反応になったりします。
1.コンソールまたは端末から、/etc/pam.d/dtsession ファイルを作成・編集します。
bash
sudo vi /etc/pam.d/dtsession
コードは注意してご使用ください。
以下の内容をそのまま書き込んで保存します。（システム標準の認証設定を流用します）
text
# /etc/pam.d/dtsession
auth include system
account include system
password include system
session include system
コードは注意してご使用ください。
原因B：ファイルシステムが nosuid でマウントされている
NetBSD のセキュリティ対策として、CDE がインストールされている領域（/usr や /usr/pkg）に nosuid（SUIDバイナリの実行禁止）属性がついていると、
いくら chmod u+s をしても権限が無視されます。
1.以下のコマンドでマウント状況を確認します。
bash
mount | grep pkg
# または単に
mount
コードは注意してご使用ください。
2.表示された結果の /usr または /usr/pkg の項目に (..., nosuid, ...) という表記がないか確認してください。
3.もし nosuid がついている場合は、安全のためにシステム全体を緩めるのではなく、前述した「CDE標準のロックを諦めて xscreensaver を使う（前回の回答の代替案）」か、
/etc/fstab を編集して該当マウントポイントから nosuid を削除して再マウントする必要があります。
＠
/etc/pam.d/dtsession の実際の記述:
Vnb110R2% more /etc/pam.d/dtsession
auth sufficient /usr/pkg/lib/security/pam_pwauth_suid.so
auth required pam_unix.so
account required pam_deny.so
session required pam_deny.so
password required pam_deny.so
と書かれている
ファイルの中身を確認していただき、ありがとうございます！
設定されている pam_pwauth_suid.so は、NetBSD の一部のスクリーンセーバー等で「非root権限のまま安全にパスワードを検証する」ために使われる特殊なモジュールです。
しかし、現在の中身を見ると、認証（auth）以外の項目（account、session、password）がすべて pam_deny.so（すべて拒否する） になっています。
この状態だと、CDEがアカウントの状態をチェックする際などにPAM側で強制的に処理が拒否されるため、ロックが解除できなくなります。
これがパスワードを入力しても反応しない（弾かれる）直接の原因です。
🛠️ 解決手順（PAM設定の修正）
仮想コンソール（Ctrl + Alt + F2）から root 権限で /etc/pam.d/dtsession を書き換えます。
1. ファイルを編集する
bash
sudo vi /etc/pam.d/dtsession
コードは注意してご使用ください。
2. 中身を以下のように書き換える
pam_pwauth_suid.so を活かしつつ、その他の拒否設定（pam_deny.so）をシステム標準の設定（system）へ引き渡すように変更します。
text
# /etc/pam.d/dtsession
# 認証 (auth)
auth sufficient /usr/pkg/lib/security/pam_pwauth_suid.so
auth required pam_unix.so
# アカウント・セッション・パスワードはシステム標準を許可
account include system
session include system
password include system
コードは注意してご使用ください。
(※ account required pam_deny.so などの3行を、include system に置き換える形です)
3. 反映を確認する
保存して終了したら、Ctrl + Alt + F1 でCDE画面に戻り、パスワードを入力してみてください。
＠
実際の変更:
/etc/pam.d/dtsession の内容を
auth sufficient /usr/pkg/lib/security/pam_pwauth_suid.so
auth required pam_unix.so
account required pam_deny.so -> account include system
session required pam_deny.so -> session include system
password required pam_deny.so -> password include system
💡 万が一、これでも入力できない場合
もし上記を試してもキー入力自体がピクリともしない（文字も打てない）場合は、
PAMではなく X11（キーボードグラブ）のフリーズ が起きています。
その場合は、前回の「代替案」でお伝えした通り、CDE標準のロック機構を無効化して xscreensaver を利用するのが NetBSD 環境では最も安定します。
1.Ctrl + Alt + F2 でコンソールへ
2.一度ロックを強制終了してデスクトップに戻る：
bash
pkill -9 dtsession
コードは注意してご使用ください。
3.デスクトップに戻ったら、CDEの「スタイル・マネージャ」＞「スクリーン」から、画面ロックをオフにする。
4.pkgin install xscreensaver
で安全なスクリーンセーバーを導入し、自動起動（~/.dt/sessions/sessionetc）に登録する。
まずは /etc/pam.d/dtsession の pam_deny.so を置き換える方法 でロックが解除できるようになるか、お試しいただけますでしょうか？
＠
PasS の実行してみたが...:
windows10から使っていたソフト。これを実行しようとしたら
コンポーネント 'comctl32.ocx' が適切に登録されていません。 ファイルが存在しないか、あるいは不正です。
のメッセージが出る
調べたらこんなサイトを発見
ComCtl32.ocxとは
登録のしかた
regsvr32で登録したファイルを登録解除する
調べてみたら
C:\Windows\SysWOW64\comctl32.dll は存在するが comctl32.ocxは無さそう
＠
comctl32.dll と comctl32.ocx とは違うもの?:
AIに聞いてみた
はい、comctl32.dll と comctl32.ocx は違うものです。
役割や仕組みが異なります。
comctl32.dll とは
・役割: WindowsのOS自体に含まれる標準のシステムファイル（DLL）です。
・内容: ボタン、リストビュー、ツリービューなどの「コモンコントロール（共通の画面部品）」の基本機能を提供します。
・対象: Windows上で動くあらゆるアプリが共通で利用する基盤です。
comctl32.ocx とは
・役割: 主に Visual Basic 6.0（VB6）などで作られたアプリを動かすための追加の部品ファイル（OCX）です。
・内容: 開発者がプログラム内で画面部品を扱いやすくするためのラッパー（包装）のような役割を持ちます。
・対象: 古いVB6アプリなどで個別に対象ファイルとして同梱・登録して使われます。
主な違いのまとめ
・拡張子: .dll（動的リンクライブラリ）か .ocx（ActiveXコントロール）か。
・位置づけ: OSの基本機能（DLL）か、開発言語用の拡張部品（OCX）か。
＠
VisualBasic6-KB896559-v1-JPN の入手・インストール:
AIに聞いてみた
Windows 11には標準でcomctl32.ocxがインストールされていないため、Visual Basic 6.0（VB6）のランタイム等から
入手して適切なシステムフォルダに配置する必要があります。
入手と配置の方法
・ファイルの入手: Microsoftの公式「Visual Basic 6.0ランタイム」パッケージなどを展開してcomctl32.ocxを用意します。
・保存場所: 64bit版Windows 11の場合は C:\Windows\SysWOW64\ フォルダに配置します（32bit版の場合は C:\Windows\System32\）。
・登録作業: 管理者権限でコマンドプロンプトを起動し、C:\Windows\SysWOW64\regsvr32.exe comctl32.ocx を実行して登録します。
で、パッケージは入手できて、それを管理者として実行したが、指定場所には見当たらない
＠
Visual Basic 6.0 の展開先はどこ?:
AIに聞いてみた
Microsoft公式の「Visual Basic 6.0 ランタイム（vbrun60sp6.exe など）」や
「Common Controls（visualbasic6-kb896559-v1-enu.exe）」を実行した場合、
展開先はユーザーが自由に指定する一時フォルダになります。
インストール、または手動で中身を取り出す際の手順と展開先は以下の通りです。
1. 実行時の「一時的な展開先」
インストーラーをダブルクリックすると「解凍先のフォルダ（Placement/Unpack folder）」を指定する画面が表示されます。
・おすすめの指定場所: デスクトップや C:\Temp など、分かりやすい場所に新規フォルダを作って指定します。
この一時フォルダの中に comctl32.ocx などのファイルが解凍されます。
2. インストーラーによる「自動配置先」
そのままセットアップ（Setup.exeなど）を進めてインストールを完了させた場合、ファイルは以下のシステムフォルダへ自動的に配置されます。
・64bit版 Windows 11: C:\Windows\SysWOW64\
・32bit版 Windows 11: C:\Windows\System32\
💡 ファイルだけを直接取り出したい場合
インストーラーをそのまま実行してもOSの互換性エラーで進まないことFONT COLOR BLUE があります。その場合は、無料の解凍ソフト（7-Zipなど）を使って、
ダウンロードした .exe または .msi ファイルを直接右クリックし、「フォルダに展開」を選択してください。
インストーラーを実行することなく、中から comctl32.ocx だけを安全に取り出すことができます。
＠
WinRAR で comctl32.ocx だけをインストール:
一度インストール作業をやってみたのだが、指定場所に存在しなかったので、直接取り出してみる。やってみた。
1.VisualBasic6-KB896559-v1-JPN ファイルを 右クリックし サブメニューから WinRARで開くを選択
2.開いたWinRARウィンドの中の comctl32.ocx を 右クリックし選択、開いたメニュー画面の中の "指定したフォルダに展開"を選ぶ
3.開いた 解凍先のパスとオプション ウィンド内で
PC\ローカルディスク(C:)\Windows\SysWOW64
フォルダを選び OK をクリック
4.エクスプローラで C:\windows\SysWOW64\comctl32.ocx の存在を確認した。
＠
comctl32.ocx の登録:
1.スタートボタンから Windowsツール を選び、出てきたウィンドの "コマンドプロンプト" アイコンを右クリック
2.開いたサブメニューから"管理者として実行"を選択
3.管理者:コマンドプロンプトが開くので、C:\Windows\SysWOW64 に移動
4.regsvr32.exe comctl32.ocx と入力して エンター(実行)
5."登録しました" とかの メッセージが出たら成功
＠
PasS 実行成功:
ここまでやって PasS.exe を実行、立ち上がってきた。