Lycolog

検索条件

日付で絞り込み 2019年(1) 2021年(6) 2022年(5) 2023年(8) 2024年(7) 2025年(4) 2026年(13)

全44件 (3/9ページ) 一覧表示に切り替え記事本文を表示

2026/03/31(火)ARM版ノートPCはUbuntuの夢を見ないが、Windowsには光明あり

更新日：2026/04/02
投稿日：2026/03/31

ジャンル::ガジェットOS::Linux::UbuntuOS::Windows

以前、ARMとCore UltraのWindowsノートPCを軽く見て、バッテリー持ちと熱周りを比較してみたところ、かなりいい結果になったのでUbuntuを入れたいが、これができるのかどうかという話。結論から言うと無理らしい。

ラズパイで動くんだから動くんじゃね？と思っていたのだが、そんな都合のいい話はなかった。

x86やAMD64であれば、今時のLinuxは基本的に動作する。これは、これらのアーキテクチャがACPIをサポートしているからだ。ACPIと聞くと自作PC的には電源管理のイメージがあるが、Advanced Configuration and Power Interfaceの略であり、電源だけでなくハードウェアの攻勢も管理できる仕組みになっている。そしてARMにはこれが存在せず、標準化されたハードウェア管理方法がないというわけだ。

ではARMベースのPCではどうしているかというと、今のところOS側でハードウェア情報を持っておき、これを基に起動しているようだ。この情報のことはデバイスツリーと呼ばれているらしい。

例えば、gihyo.jpのそのSnapdragon X搭載PCでUbuntuを使えますか？によると、ARM版UbuntuではSMBIOSというものから端末情報を読み取って、あらかじめUbuntu側で決め打ちしているデバイスツリーを利用してOSを起動するといった手法がとられているようだった。ラズパイの場合も専用イメージがあるため、おそらくデバイスツリーが組み込まれているのだろう。

恐らくこれはARMの場合、基本的にSoCにすべて集約されているため、x86やAMD64のようにメモリやGPUなどが独立したCPUのように管理できないところがあり、ACPIで解決できず、デバイスツリーが必要という事態になっているのだと思われる。

ではWindowsはどうしているかというと、先ほどの記事にもあったがPlatform Extension Plug-ins(PEPs)を使っているとのことだ。これはLinuxでは今のところサポートされておらず、やっているプロジェクトもないようだ。

ならデバイスツリーを書けばよいとも思えてくるが、これは非常に忍耐が必要な作業で、ACPIコードやWindowsドライバのリバースエンジニアリングを行い、カーネルパッケージをビルドし、各ハードウェアが正しく動くかどうかを根気強くテスト、デバッグする作業になるようで、おいそれと気軽にできるものではないらしい。

つまり、ARM版ノートPCでUbuntuを動かすのは、公式にサポートされているもの以外は難しいだろうし、それさえきっちり動く保証はないだろうから今のところ難しそうだ。つまり、ARM版ノートPCを買う場合、重量やキーボードにこだわりのある私の場合、Windowsで運用する必要がありそうだ。何故なら日本のノートPCがサポートされる気がしないからである。

バッテリー持ちがいいのは魅力だが、Windowsにするとなるとメモリやストレージを多めにしないと厳しいので端末価格が上がってしまうのがネックだ。ただソフトウェアの互換性はよくなってきているらしく、出先で使うサブマシンとしてみた場合の実用性は十分にありそうにも思える。

マイクロソフトの案内でも、デバイスドライバやアンチウィルス、アンチチートソフトウェア以外の一般的なアプリケーションは動作するとあるため、この辺りは安心してもよいだろう。一部のソフトウェアの互換性についてはLinaroのWoA対応アプリ検索で確認することができ、例えばXnViewは動作することがわかる。XnVew MPは出てこないが、恐らく動くのではなかろうか？国産のソフトの動作状況はPC Watchの記事でも一部を確認できる。なおエミュレーションで単に動くだけなのか、パフォーマンスがいいかどうかは不明だ。

コメント（0件）

2026/02/13(金)Windows 11にnvmを入れてMSYS2のzshから使う

投稿日：2026/02/13

Node.js::その他OS::Windows

なんか気が付いたら動かなくなってた気がするので作業ログとして残しておく。

確認環境

Env	Ver
Windows 11 Pro	25H2 OS build 26200.8740
MSYS2	msys2-x86_64-20251213
zsh	5.8 (x86_64-pc-msys)
nvm-windows	1.2.2

MSYS2 msys2-x86_64-20210725でも動作を確認しているため、MSYS2のバージョンはほぼ関係ないと思われる。

前提条件

MSYS2とzshは既にあるものとする。
Node.jsは入っていないものとする。

やり方

nvm-windowsからインストーラーを落としてインストール
任意のシェルでnvm onを実行
nvm install ltsなり適当なインストールコマンドを叩く
node -v && npm -vで両方のバージョンが出ればOK

トラブルシューティング

nodeやnpmのコマンドが見つからない

nvm onを実行していないと上手くパスが通らないのでこれを実行する必要がある。

あとがき

nvm onなんてしなくても動いていた気がしたが、久々にWindowsでnodeを叩こうとしたら動かなかったので、ついでに全部の環境を刷新するついでに書いた。

コメント（0件）

2026/02/13(金)Windows 11の新しいメモ帳を消して古いメモ帳を使う

更新日：2026/04/02
投稿日：2026/02/13

OS::Windows

Windows 11の新しいメモ帳は、CVE^[1]が出たり、Markdownをコピペしたら勝手にエスケープされたり、毎回新機能の設定をOFFさせられたりと、新しいメモ帳に愛想が付いてきたので古いメモ帳に戻すことにしたのでそのログ。

新しいメモ帳にはお亡くなり頂き、古いメモ帳だけにした。

やったこと

新しいメモ帳をアンインストール
- 実は普通にアンインストールできてしまう
Win+Rでファイル名を指定して実行を出し、notepadを叩く
「新しいバージョンのメモ帳が利用可能です」「インストール」とか帯が出るので帯の右にある×ボタンを押して消す
タスクバーにいるメモ帳を右クリックしてスタートにピン留めする
- この作業を行い、notepadと入力して起動、noteと入力して起動、nと入力して起動のように繰り返すことで、以後の起動が楽になる

トラブルシュート

テキストファイルの新規作成ができなくなった

以下のレジストリを登録することで出すことができるようになる。

[HKEY_CLASSES_ROOT\.txt\ShellNew]
"NullFile"=""

[HKEY_CLASSES_ROOT\txtfilelegacy]
"FriendlyTypeName"="テキストファイル"

新しいメモ帳を復活させたい

Microsoft StoreにあるWindows Notepadというやつが恐らく同じものだと思われるので、これを入れるといい。

実際にこれをインストールすると「メモ帳」が復活した。

あとがき

メモ帳なんかプレーンテキストが書ければそれ以上は要らないので昔のメモ帳に戻ってこれてよかった。

UIも無駄に場所を取っていたのがすっきりした。

CVE-2026-20841でWindows Notepad アプリのリモートでコードが実行される脆弱性 ↩

コメント（0件）

2025/11/12(水)Windows 11をWindows Updateでversion 25H2にしたら発生した問題と、その対処法

更新日：2026/08/05
投稿日：2025/11/12

OS::Windows

Windows 11でWindows Updateを行ったところ、色々壊れたので、その対処ログとして残す。

アップデートした内容

Windows 11 24H2→Windows 11 25H2

OSビルドまでは控えていないため不明。

発生した問題

根本原因の大半はファイアウォールのルールが激減したせいであることが分かった。

SSHDに繋がらなくなった

当該のWindows端末ではLAN内でファイル共有をする目的でSSHDを立てているのだが、これに繋がらなくなった。

原因としては単にファイアウォールのルールが消し飛んでいただけだった。

WindowsにSSHDを立てるでやった方法で穴あけしなおすことで解決した。

LAN内にあるサーバーにIPv6 GUAを利用した疎通が出来なくなった

これはWindowsからLAN内にあるUbuntuサーバーにIPv6 GUAを利用し接続しようとしたところ、接続できなくなった問題だ。WAN側、インターネット上のIPv6 GUAには問題なく接続できた。

これも単にファイアウォールのルールが消し飛んでいただけだったが、どのルールが原因だったのかは特定できていない。

私の環境では基本的にIPv6運用をしているため、例えば自宅でホスティングしている公開MastodonにローカルからアクセスするだけでもGUAを利用しているが、まずここに繋がらなくなった。PINGも通らなかった。但しサーバー側からWindows側へのPINGはFWに穴をあけると繋がった。

ひとまずパケットがサーバーに富んでいるかどうかを見るためにWiresharkで眺めてみることにした。

以下はファイアウォール有効時と無効時でそれぞれPINGを飛ばした時のものだが、有効時はIPアドレスが変換されていることがわかる。

FW有効時	FW無効時

ネットワークにはあまり詳しくないので何とも言えないが、帰りのパケットが届いているように見えることから、IPアドレスの変換が起きることによってステートフルインスペクションが機能不全を起こし、結果として正しく疎通しない状態になっていたのではないかと思う。

ステートフルインスペクションというのはパケットが出ていくときに、戻りのパケットを受け入れるためにポートを開けておく仕組みのことで、ここが塞がっていると戻りのパケットがFWで塞がれて入ってこれなくなる。今回は送信時のIPと、戻ってくるときのIPが異なるため、これが機能しなかったのではないかと考えている。

ステートフルインスペクションについて昔調べていたことがあったので、これはすぐに当たりがついてよかった。調べようとした動機としてはサーバーが待ち受けている場合はポートに穴がないとパケットを受けられないのに、応答はなぜポートに穴が開いてなくても抜けられるのか？と疑問に思ったことがあり、その時に調べていた。

MS Edgeがファイアウォールの許可要求を出すようになった

これは原因がよくわかっていないが、FWを許可してもセキュリティホールにしかならなさそうなので不許可でよいと思う。

ファイアウォールのルールが極端に減った

諸悪の根源はこいつだが、コマンドプロンプトを管理者権限で起動して以下のコマンドを叩くことで解決した。

netsh advfirewall reset

アップデート直後の状態は確かこんな感じだったと思う。なおこの画像は微妙にルールを追加したあとに、追加した記憶のあるルールを消しているので内容が正確でない可能性がある。

解決した方法

コマンドプロンプトを管理者権限で起動して以下のコマンドを叩き、SSHDについてはWindowsにSSHDを立てるでやった方法で穴あけし直し。

netsh advfirewall reset

MS Edgeがファイアウォールの許可要求を出すようになった件については対処法が不明なので、とりあえずFWはブロックにしている。

雑感

どうも今回のアップデートでファイアウォールのルールが大きく書き換えられるようで、特にLAN内でIPv6 GUAを利用するときに著しい障害が発生することが分かった。

このクラウド全盛期に自宅サーバーを立てていたり、一般的に避けられがちなIPv6運用を軸にしている人間が少ないこと、ネットがクソみたいなAIコンテンツで溢れていることなどもあり、中々解決に手間取ったが、IPv6を使った自宅サーバー運用者としてIPv6で接続できないのは屈辱的だし、WAN上のIPv6には問題なくつながっており、MSもこんな致命的なバグを長らく放置はしてないだろうから、どこかに抜け穴があるはずと調べていたらどうにか見つけることができた。

調べたといっても、私はネットワークの知識に乏しく、手掛かりになるキーワードを持たないので無料のMS Copilotに聞いただけではあるが、いい収穫が得られた。

参考までに以下のプロンプトを投げた。

Windows 11でWindows Updateをしました。 Updateした端末をクライアントとし、GUAを利用してLAN内のサーバー端末にIPv6接続できなくなりました。

Firewallのルールがすべて削除されていたので、試しにFirewallを無効化すると接続できました。

有効にした場合、LAN内の端末にIPv6 GUA接続した場合に、宛先のIPアドレスを書き換えているようです。これはどうすれば解決できますか？ IPアドレスが書き換えられるため接続ができないものとみられます。

例えば2400:4153:8f01:c800:c14b:3f7a:2b54:353aに接続しようとするとff01::1:ff54::353aに書き換えられます。ファイアウォールを無効化した場合、書き換えられません。

コメント（0件）

2025/09/30(火)GitHubのリポジトリをSSH認証経由で扱えるようにする

更新日：2026/04/07
投稿日：2025/09/30

Webサービス::GitHubソフトウェア::SSHOS::Linux::UbuntuOS::Windows

なんか突如としてGitHubにHTTP経由で繋ぐのが面倒くさくなったのでSSHで繋げるようにしたときのメモ。

確認環境

Windows 11 Pro 25H2
Ubuntu 24.04.3 LTS
RLogin 2.30.8

やり方

SSH鍵の作成

RLoginを開き、サーバーに接続→新規→サーバー→プロトコルを開く
認証キーボタンを押しED25519辺りで適当な名前で鍵を作成する
適当な場所に秘密鍵をエクスポートする。ここでは便宜上github.secとする
鍵を右クリックし、公開鍵をコピーして、どっかにメモっておく

GitHubへの登録

GitHubを開き、アカウント設定に移動、SSH and GPG keysを開く
SSH keys→New SSH Keyを開く
Titleに適当な名前を設定
Key typeはAuthentication Keyにする
RLoginで作った
コピーした公開鍵をKeyに貼り付ける
Add SSH keyボタンを押す

# 鍵束への登録
eval "$(ssh-agent -s)"
ssh-add ~/.ssh/github.sec

# 接続確認
ssh -T git@github.com

SSH Configを書く

Windowsの場合

ここではWindowsのSSHクライアントを利用する。

Gitに利用するSSHクライアントの設定をする

git config --global core.sshCommand "C:/Windows/System32/OpenSSH/ssh.exe"

作成したSSH鍵をC:/Users/<ユーザー名>/.ssh/に置く
C:/Users/<ユーザー名>/.ssh/configを開き、次の内容を記述
```
Host github.com
    User <ユーザーID>
    Hostname github.com
    IdentityFile C:/Users/<ユーザー名>/.ssh/github.sec
```
パス表現に%USERPROFILE%は通用しないので注意

Ubuntuの場合

作成したSSH鍵を~/.ssh/github.secに置く
chmod 600 ~/.ssh/github.secとかして自分しか見れないようにする

~/.ssh/configを開き、次の内容を記述

Host github.com
    User <ユーザーID>
    Hostname github.com
    IdentityFile ~/.ssh/github.sec

既存のリポジトリをSSH対応にする

ここではoriginがリモートであるとして進める。

git remote -vでリモートリポジトリの状況を確認
git remote remove originでHTTP通信になってるのを消す
git remote add origin git@github.com:Hoge/piyo.gitでSSH通信に書き換える
git fetchが通ればOK

トラブルシューティング

Permission Denied (publickey)が出る

鍵のパーミッションが600、.ssh/のパーミッションが700なのを確認する
ssh -T git@github.comで繋がるか確認する。繋がらなければこれまでの手順が何か漏れないか確認する
ユーザー名が間違っていても出る

コメント（0件）