Command

この記事を作った動機 ミンゲイインターネット にて見つけた記事である Windows 11 でローカルアカウントを作成する方法【2026年7月時点】 に対して散々書いたので、それに対して自分なりにどうしたいか書いてみる。 具体的には、記事で書かれている方法が機能するかどうか調べることと、sysprepを使った方法に対して、自分なりにやりたい方向性で手順を記述する。Windows 11 でローカルアカウントを作成する方法【2026年7月時点】 で書かれていることで嫌なこととして、内容がいちいち冗長で複雑で特別なスクリプトを実行させようとしてくるところがある。 簡単な方向性 今回は、Windows ADK を使って、簡易的な応答ファイルを作成し sysprep コマンドにそれをセットアップ時に指定して読み込ませるということをする。複雑なスクリプトなども不要になるよう、作成した応答ファイルはこのブログに掲示する。 各個人は、それをコピペするなりダウンロードして、xml として保存し、読み込ませれば使えるようにし、確認に過大な負荷を要する特殊な操作や特殊なスクリプトを排する。今回ブログに上げる応答ファイルのXMLを使えば、Windows ADK などの特殊なツールを使わずに作業を完結させられるはずである。 ADK は以下のリンクから得られるものを利用した。 Windows ADK をダウンロードしてインストールする | Microsoft Learn https://learn.microsoft.com/ja-jp/windows-hardware/get-started/adk-install (2026年9月12日) 応答ファイル テスト済みの環境リスト チェックがついているものがテスト済み、ついていないものがこれから。(基本的によほど制限があるエディションでなければ汎用に動くと思われる。) Win 11 Pro 25H2 26200.8037 Win 11 Home 25H2 26200.8037 Win 10 Pro 22H2 19045.2965 Win 10 Home 22H2 19045.2965 仕様 ユーザ名(管理者) Main パスワード pass 同意画面 隠す ローカルアカウント作成画面(OOBE) 隠す オンラインアカウント作成画面(OOBE) 隠す ダウンロード install.xml 生成した応答ファイルの全容 <?xml version="1.0" encoding="utf-8"?> <unattend xmlns="urn:schemas-microsoft-com:unattend"> <settings pass="oobeSystem"> <component name="Microsoft-Windows-Shell-Setup" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="NonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <OOBE> <HideEULAPage>true</HideEULAPage> <HideLocalAccountScreen>true</HideLocalAccountScreen> <HideOnlineAccountScreens>true</HideOnlineAccountScreens> <HideWirelessSetupInOOBE>true</HideWirelessSetupInOOBE> </OOBE> <UserAccounts> <LocalAccounts> <LocalAccount wcm:action="add"> <Password> <Value>cABhAHMAcwBQAGEAcwBzAHcAbwByAGQA</Value> <PlainText>false</PlainText> </Password> <Name>Main</Name> <Group>Administrators</Group> </LocalAccount> </LocalAccounts> </UserAccounts> </component> </settings> <cpi:offlineImage cpi:source="wim:c:/users/main/desktop/install.wim#Windows 11 Pro" xmlns:cpi="urn:schemas-microsoft-com:cpi" /> </unattend> ...

この記事を作った動機 ミンゲイインターネット にて記事を漁っていると、Windows 11 でローカルアカウントを作成する方法【2026年7月時点】 という記事が見つかっため読んでみたところ、気になることがあったのでそのことについてまとめたい。 あと経過観察として、msoobe bypassnroが機能したかも記録したい。ちなみに全ては Pro エディションを対象としており HOME は対象としていない。個人的には HOME やそれに類似するエディションを使うことは推奨していない。 前回の記事 OOBE（Windowsのセットアップ画面） をスキップする 次の記事 OOBE（Windowsのセットアップ画面） をスキップする-2 (sysprepを使う方法) 関連する記事とか LLM の利用状況の現状 コマンドライン経由で windows をインストールする パスワードを無期限で利用できるようにする msoobe bypassnro経過観察 2026/9/12 Pro 公式から入手できるISO 26200.8037 機能した UUP dump からダウンロードした ISO (26H2 Preview 26300.9539) 機能した Home 公式から入手できるISO 26200.8037 機能した Windows 11 でローカルアカウントを作成する方法【2026年7月時点】 の記事についての疑問点 Bypassnro ができないという記述について 対象のブログに以下のような記述があることが気になった。しかし私が現時点では検証したうえでは、これは本当ではなさそうである。bypassnro.cmd というスクリプトがなくなるくらいならあり得る気もしたが、それも仮想マシンで試したところ存在していることが確認できた。 なぜローカルアカウントが作れないのか Windows 11 のセットアップは、途中で Microsoft アカウントへのサインインを要求します。ここでネットワークをつないでいると、ローカルアカウントを作る選択肢が表示されません。 以前は回避方法がいくつかありました。 oobe\bypassnro.cmd を実行する start ms-cxh:localonly を実行する しかしこれらはすでに削除されており、2026 年 7 月現在は使えません。Microsoft が意図的に塞いでいる領域です。 ちなみに以下は、公式から入手できるISOで試したときの様子である。ビルド番号も対象のブログが出しているものと同じである。 ...

この記事を作った動機 最近ニコニコ動画を久しぶりに見てみて、動画をいくつか yt-dlp コマンドによってダウンロードしようとしたところ、パスワードとユーザ名によるログイン機能がうまく機能しない場合があることが分かった。 普段であれば、誰かが勝手に issue でも立てるだろうと放置していただろうが、何を血迷ったのか issue を自分で立てたので、そのことについて記録したい。Issue に関してはすでに yt-dlp の方を見ればわかることなので、周辺情報について適当に書きたい。 前回の記事 yt-dlpコマンドで、年齢制限を何とかする yt-dlpコマンドで、年齢制限を何とかするの追記 issue へのリンク [niconico] Unable to log in: HTTP Error 404: Not Found (caused by <HTTPError 404: Not Found>) · Issue #17667 · yt-dlp/yt-dlp https://github.com/yt-dlp/yt-dlp/issues/17667 (2026年9月11日) yt-dlp をコンパイルする 前提条件として、すでに作業ディレクトを作成して移動しており、anaconda 環境であることと、Linux 環境であることを置く。ニコニコ動画に関していくつか API エンドポイントの URL について候補があり試したかったというのがあり、コードを改変したあと、コンパイルする必要がったことが背景にある。結局どれもうまくいかなかったが。 リポジトリをクローン git clone https://github.com/yt-dlp/yt-dlp.git cd yt-dlp 環境を作成 conda create -n ytDlp conda activate ytDlp conda install python conda install pip 依存関係のインストールやコンパイル、バイナリ生成 yt-dlpリポジトリのコンパイルの項目を参考に、以下のようにして yt-dlp のバイナリを生成する。 ...

この記事を作った動機 簡易的に GTX 1080 Ti と Linux 環境において、Virtio(OpenGL) や Venus(Vulkan) による GPU アクセラレーションを利用する方法について、今まで諦めていた。それでも諦めきれずに定期的に調べていたところ、対処方法が見つかった。それについて、簡易的に症状とやったことを記録したい。 デモ 以下の動画は、RDP 経由で Venus による 仮想 GPU を利用して Vulkan や OpenGL のアプリが動作している事を示している。マインクラフトの操作については、今回の RDP セットアップの仕様上、絶対座標しか送られておらず視点を動かすことができていなかったり、VPN など遠隔地から RDP 接続をして動かしているため、ラグが大きくぎこちないものとなっている。 前座 Virtio における GPU 加速 Virt-Manager において標準で利用できる仮想 GPU である。AMD や Intel の GPU 環境では特別なことをしなくても、私個人の体験としては利用できたが、Nvidia 環境ではそうならなかった。 Venus における GPU 加速 最近あたらしい GPU 加速手段の一つとして実装されたもので、デフォルトでは Virt−Manager などからはまだ利用できるようにはなっていない模様である。これについては直接 QEMU をコマンドラインから起動することが私が現在できていることであり、Virt-Manager からは XML の設定をいじってみたものの成功していない。 今回犠牲になっている事 今回提示する解決策は、最低限 仮想 GPU が Nvidia の GTX1080Ti において動作するようにする事を目的としており、以下の負担や犠牲がある。 ...

この記事を作った動機 libvirt の仕様を理解していなかった結果、大量の時間を溶かすことがあったので記録したい。具体的には、仮想マシンに対してRDPのためにポート転送を設定しようとしたが、libvirtが作成する、defaultネットワークに属している、virbr0ブリッジはnftablesをいじっても言うことを聞かないほど、ガチガチに守られていて使うべきではないという結論に至った。 今回はそこに至るまでの経緯と、実際に機能する事を確かめた対処方法について記録する。機能する対処方法の概要としては、libvirt以外に、手動でブリッジを専用に作成し、それに対してfirewalldでNATやDNATを構成し、仮想マシンにそのブリッジを使うように設定する事をする。 機能した対処方法 仮定 仮想マシンを動かしているホストマシンは、firewalldのpublicゾーンを使用している ホストマシンは、ブリッジに対して192.168.150.1/24のIPを持つ 仮想マシンのIPは手動で192.168.150.25/24を割り当て、ゲートウェイにはホストマシンに向けて192.168.150.1と設定する sysctl -w net.ipv4.ip_forward=1が設定されており、カーネルが異なるインタフェース間のパケットの行き来を許可していること ブリッジを作成 sudo brctl addbr virt sudo ip link set virt up sudo ip addr add 192.168.150.1/24 dev virt 仮想マシンを作成したブリッジを使うように設定 firewalld でNATとDNATを構成する # ゾーンとポリシー(NAT用)を作成 sudo firewall-cmd --new-zone=virt --permanent sudo firewall-cmd --zone=virt --add-interface=virt --permanent sudo firewall-cmd --zone=virt --new-policy=nat --permanent sudo firewall-cmd --policy=nat --add-ingress-zone=virt --permanent sudo firewall-cmd --policy=nat --add-egress-zone=public --permanent sudo firewall-cmd --policy=nat --add-masquerade --permanent # ポート転送設定(DNAT) sudo firewall-cmd --zone=public --add-forward-port=port=33890:proto=tcp:toport=3389:toaddr=192.168.150.25 --permanent sudo firewall-cmd --zone=public --add-forward-port=port=33890:proto=udp:toport=3389:toaddr=192.168.150.25 --permanent # NATが機能するようにマスカレードと転送を設定 sudo firewall-cmd --zone=public --add-masquerade --permanent sudo firewall-cmd --zone=virt --add-forward --permanent sudo systemctl restart firewalld 問題至るまでの経緯 今までの構成を見直す 今まで仮想マシンへのRDPアクセスは、無理やりVPN経路を通じて同じLAN内に仮想マシンを参加させることで動かしていた。接続が不安定であり定期的にVPNが接続できなくなったり、ネットワークトポロジ的にも循環経路を形成しかねないように見受けられた。VPNを介さずにホストマシンを直接介させることで、仮想マシンに対してRDPを行うために、今回は仮想マシンのRDPポートである、3389に対してポート転送を行う事を考えた。 ...

このページは、まだ未完成です。。。 nicotalk＆キャラ素材配布所 http://www.nicotalk.com/charasozai_kt.html （2024年5月16日） この記事を作った動機 最近、Google (Gmail) とかに深く関係があるのは嫌であることや、中央集権的な SAAS サービスへの不信がある。そこで、自前のメールサーバを持ちたいと思い、Mailcow を使おうとしたので不完全でいいので作業過程の記録を取りたい。 前提条件 Arch Linux 環境で作業を行い、Mailcow 公式サポートはない状態である 専用の物理 PC を割り当てる クリーンインストールで、Gnome デスクトップ環境や最低限のパッケージが入った、Arch Linux 環境 スリープを無効化している。-> gnomeの設定のメモ ⚙ firewalld は導入していないこと -> Prepare your system - mailcow: dockerized documentation できれば yayコマンド を導入する NetworkManager を使っている。 DNS サーバにクラウドフレアを使っている。 設定要件 自分の LAN (VPN) 環境のみからメールの送信を受け付け、グローバル IP 空間からはメールの送信を受け付けない メールの受信についての対策は、Mailcow 標準に頼りたい 利用者は自分や自分が許可した少数の身内のみ メールサーバ自体は直接グローバル IP 空間には晒さず、VPN や LAN のネットワーク空間を転送するようにして利用する。 ネットワーク構成 ネットワーク構成としては、通常のメールサーバではグローバル空間に配置してファイヤウォールに必要な分だけ慎重に穴を開けるなどのスタンスを取ると考えられるが、今回のはセキュリティーの観点から、そうはしなかった。 基本的には、メールサーバは直接グローバル空間には晒さず、かつNAT環境下にある自宅の専用に用意したサーバを使うという観点から、別の専用にグローバル空間とつながっていて固定IP持っている中継サーバ(VPS)で、ポート転送などを行うという形態を取った。また、セキュリティの観点から メールを送受信したり、サーバを管理できるユーザは、VPNによって自宅のLAN内にアクセスできる人間のみとし、グローバル空間からは、SMTPポートだけ、晒して、メールは送受信できるようにしつつ、外部の人間は今回構築するメールサーバに対して、リレーとして使ったり、送信を命令することはできないようにしている。メールを送信できる人は、メールサーバと同じLANに属しているユーザだけであり、メールの受信はどこからでもスパムでないこと、不正でないことを前提に、スパムフィルターで弾かれなかったものが受け付けられるという形態を取る。 中継には VPS を使い、メールサーバとVPS間は専用に用意したVPNネットワークで接続される。これにより、NAT超えも実現しながら、メールサーバを直接グローバル空間に晒さずに済むというものである。注意点としてはメールサーバ側のルーティングや、VPS側のファイヤウォール、転送設定がを間違っていると、セキュリティリスクになる点を留意する。 イメージ用の図いろいろ ネットワーク構成の概要 大まかなルート構成 VPSにおけるポート転送と特別なルーティング(nftables)で成立 通常のSMTPとして成立するルート 外部のメールサーバからの見え方 メール送受信のためのフロントエンドアクセスが出来る範囲 SMTP 関連パケットのルーティングについて メール受信時の経路 メール送信、SMTP における応答通信時における経路 不正な SMTP パケットの経路 ネットワーク設定 VPS プロバイダの設定 VPS の設定 メールサーバ本体の設定 説明用の仮定 メールアドレス xxxx@your.domain.comのようにする。 メールサーバについて mx.your.domain.comにホストすることにする。 IPアドレスを160.251.xxx.xxxとして仮定する。 Mailcow のインストール docker 環境の導入 # 必要なパッケージのインストール (jq は mailcow の依存関係) yay -Sy docker docker-compose jq # sudo pacman -Sy docker docker-compose jq # サービスの有効化 sudo systemctl enable --now docker # 必要であれば管理用ユーザを docker グループに追加し、権限を付与する sudo usermod -aG docker [targetUser] # 念のため再起動 sudo systemctl reboot IP アドレスの固定 今回は、NetworkManager を Gnome 環境に組み合わせた状態なので、Gnome の GUI から設定を行った。 ...

この記事を作った動機 最近、XPS 13 2in1 (intel 8th) を使っていて、バッテリーが完全に放電しきった状態で放置していることがあった。それで、通常であれば、CMOS 電池が設定内容を保持していて、UEFI の変数などのデータを保持しているはずだが、今回は違った。PC を充電器に繋ぎ、起動すると CMOS リセット時に見られる挙動である何度か再起動をするということになった。ようやく動いたかと思ったら、普段の設定とは異なって、Dual Boot 構成にしていた Windows がのそのそと起動し始めた。あまりのストレスに PC を投げ出したくなったが、結局色々調べて振り回されたことがあったので、記録したい。 経緯 PC が完全に2日程度放置していて、放電しきっていることに気づく。 Windows が起動しようとしてイライラする Linux 環境を立ち上げようとして、UEFI の設定画面でエントリを作成し起動を試みるも、“no resume device found"と言われ起動しない GURB の設定を編集しresume=と書かれているところを消すも、症状が改善せず。 起動するために USB を用意するもDD コマンドによる起動可能な USB 作成において説明される問題により、一度失敗する ローカルLLM である Gemma4 に投げるも、通常のターミナル環境を起動できないから困っているにもかかわらず、ターミナルを使えだの的はずれなことばっか出力してきて爆発しそうになる。例えばresume=noneにしたら上手くいくと出力してくるが、機能しなかった。 DD コマンドによる起動可能な USB 作成により、最終的に正しく起動する USB メモリを作成し、ようやくライブ環境の端末が起動する ドライブモードが RAID になっていることに気づき、AHCIに設定する しかし奇妙なことに最初ライブ環境を起動したとき、肝心の Linux 環境が入っている NVME SSD が見えず、もう一度 CMOS がリセットされた状態にして、再トライすることになる もう一回 AHCI に設定する ようやくライブ環境から SSD が見えるようになり、initramfs から resume の hooks を吹き飛ばすことと、GRUB の resume 設定をなしにして起動設定を再生成させる ようやく PC が正常に Linux 環境に起動するようになる。 今回の問題を起こした主犯であると思われる、CMOS 電池について調べる。 ポイント “no resume device found” で Linux 環境が起動しない 完全には確かめられていないが、どうも AHCI でもともと動かしていた物を、CMOS リセットが起こった時点で、RAIDになっていたために、それで起動しようとした結果起動できなかったということっぽい？しかし、USB のライブ環境に入れるようになってから、AHCI にドライブのモードを設定することは試したため、本当にそれが問題かは謎である。Linux 環境なら元からドライバは入っていそうなものだし、考えられることとしては、RAID モードであるときと、AHCI モードであるときで、パティーションの UUID が異なってしまうのかな？とは考えた。 ...

この記事を作った動機 最近 Linux 環境を使っていると、noto-fonts-cjk をインストールしているにもかかわらず、それが機能しないことがあった。具体的には、中華系フォントが日本語フォントとして優先されて表示され、読めないことはないが、地味に見慣れない文字になってしまう。今までは、Linux 環境のフォントは読めればいい、映ればいいで放置していたが、流石にそれはないなと思ったので、設定をしていた。 当然いちいち設定するときに調べるのはしんどいので、まとめが欲しいと思い記録を取ることにした。今回は、GNOME に関する設定と、fontconfig に関する設定の 2 つについて記録を取る。 前提 Linux 環境 GNOME を使っている GNOME-Tweaks の項目のみにおける制限 設定後は再起動する。 システム全体の変更の反映は管理者権限を使うことを前提としている。(sudo) フォントの配置場所と更新 システム全体 通常はこのフォルダは標準で何もしなくてもあるはずである。ない場合は、別の場所にフォントが保存されているか、インストールした OS が崩壊している可能性がある。 /usr/share/fonts ユーザ単体 ない場合はフォルダを新規作成する。 ~/.local/share/fonts 新しく配置したフォントの反映 sudo fc-cache -fv GNOME-Tweaks gnome-tweaks をインストールし、単に GUI を開いてポチポチするだけである。GNOME 環境ではすでにフォントがある程度デフォルトで固定されており基本的に崩れにくいため、デフォルトで満足しているならそのままでも良いと思われる。その場合は特別な設定が少なくとも GNOME に関しては、必要ないということである。 yay -Sy gnome-tweaks # sudo pacman -Sy gnome-tweaks Fontconfig 設定配置場所 システム全体 ない場合は、テキストファイルとして新規作成する。 ...

この記事を作った動機 CMOS リセット時に GRUB インストール時にデフォルトで作成される UEFI 設定が一緒に消えてしまう。結果として、はじめから Linux 環境を起動してほしいときに、意図した通りに起動しないことがあった。 そこでしばらくは BIOS から直接 Linux 環境がインストールされた環境をわざわざ選択して起動したり、UEFI設定から直接エントリを作成して、Linux を起動するようにするなど、面倒くさい事を繰り返していた。 今回は、それに対してefibootmgrというコマンドを使い、systemd によって一度起動したら自動でエントリがない場合に起動エントリを追加するようにした。その内容について記録を取りたい。 efibootmgr の使い方 インストール yay -Sy efibootmgr # sudo pacman -Sy efibootmgr エントリを追加する例 ブートローダである UEFI アプリケーションのパスを指定するとき注意が必要である。Linux 環境側から見て、/bootに EFI パティーションをマウントしていて、/boot/EFI/arch/grubx64.efi に対象のアプリファイルが配置されている場合の例について考える。この場合、efibootmgr で指定すべきパスは、/boot/EFI/arch/grubx64.efi ではなく /EFI/arch/grubx64.efi である。もしここで間違ったパスを指定していると、UEFI アプリケーションの起動に失敗し、UEFI の設定画面に飛ばされるなどの症状になる。 sudo efibootmgr -c -L ArchLinux -l /EFI/arch/grubx64.efi -d /dev/nvme0n1p1 fdisk で Linux 環境がインストールされたディスクを確認 sudo fdisk -l # Disk /dev/nvme0n1: 476.94 GiB, 512110190592 bytes, 1000215216 sectors # Disk model: SAMSUNG MZVKW512HMJP-000H1 # Units: sectors of 1 * 512 = 512 bytes # Sector size (logical/physical): 512 bytes / 512 bytes # I/O size (minimum/optimal): 512 bytes / 512 bytes # Disklabel type: gpt # Disk identifier: # # Device Start End Sectors Size Type # /dev/nvme0n1p1 2048 2097152 2095105 1023M EFI System # /dev/nvme0n1p2 2099200 964689920 962590721 459G Linux filesystem # /dev/nvme0n1p3 964691968 1000214527 35522560 16.9G Linux swap ...

この記事を作った動機 Intel Arc で音声からの文字起こしができる Whisper を動かせることが分かったので記録したい。Whisper は PyTorch を使っているが、それを XPU に対応したものに差し替えることで動作が確認できたことに関して、具体的に作業内容を記録したい。 Whisper を使った文字起こしでは、Vibe を使うことでもできるが、Nvidia の CUDA 環境で無い限り、Intel Arc 環境においては、Vulkan を使ってしまう。PyTorch 環境においては XPU を使わなければ、Intel Arc の GPU 性能を使い切れていない気がすると思ったのもある。 ただ実際に試してみると、今のところそこまで早いとは言えず、むしろ Vulkan で動かしているときより遅い気もした。設定次第なのかもしれないが、そこまでは詳しく試していない。 環境の前提 Intel Arc を使っている Conda 環境を導入済み Linux 環境 記事の作業内容のまとめ conda create -n whisper conda activate whisper conda install pip pip install -U openai-whisper pip uninstall torch pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/xpu Whisper のインストール conda 環境を専用に作る conda create -n whisper conda activate whisper conda install pip whisper を pip でインストール 一旦 Nvidia 環境用の pytorch などがインストールされてしまうが、一旦はインストールを終わらせる。 ...