味噌汁を飲みます

そんなに深く考えて書いていない twitter: siberiy4

情報学を修了した

日記・感想

大学院博士前期課程（修士）を修了することができました。
修士にふさわしい能力と実績と論文ができたかはわからないですが、自分としては卒業できたので一安心です。
学部を含めた6年間の振り返りと感想を書いていきたいと思います。

学部

入学時は他大を全部落ちて、後期試験でなんとか合格した状態だったのでかなり落ち込んだ状態でした。
無力感というか能力のなさを認識したので今まで何も情報の勉強をしたことがないけれど何か技術を身につけないと！ みたいな焦りが結構強く感じていた記憶。
HxSコンピュータ部と競技プログラミングサークルに参加してさいきょープログラマになるぞ。みたいなことを思ってた記憶があります。

競技プログラミング

1年後期から3年の前期までたまに触ってました。

うちの大学の学部には競技プログラミングサークルがあり、オフラインのイベントに参加するときに宿泊費の補助などをしてくれた記憶があります。（昔すぎて覚えていない。)
競プロは、なんか難しいことが簡単にできるようになるらしく、人ができないことができるのはかっこよさそう。といった動機ではいりました。
問題を解くこととか、先輩とかと集まってバチャコンをするのは楽しくてそれなりに通っていました。
立命館大のBKCで行われたオフラインコンテストに参加したり、ICPCも全然わからんわー、とか言いながらお菓子食べつつ1台のpcで問題を解くのはお祭りみたいで良かったです。
AtCoderもそれなりに出ていて、あんまり精進していなかったので緑止まりでした。
早解きでレートを稼ぐ競技プログラミングしていない人間だったので、今だとだいぶレートが低そう。

ただ、競技プログラミングをしていたおかげで 授業のプログラムを書くのにそこまで苦労しなくて済んだ気がします。
あと、就活のコーディングテストはAtCoderを触ったことがあるおかげで通過できたのは間違いないです。
個人的にはコンテストに参加しなくても、AtCoder Beginners Selection などのコンテストの常設中のコンテストをするのはよさそう。
3年生ぐらいでエネルギーが切れてコンテストに出なくなってしまったので年々プログラム書く力が落ちてる感じがある。

HxSコンピュータ部

1年から3年まで

なんとなくで入った部活だったが、LT大会とか講習会とかは楽しかったし、気づいたら会計になっていてお金の管理が面倒なことを学ばせてもらった。
学祭で一日中 焼き鳥を焼いたり、クリスマス会をしたり、バーガー祭とか言ってハンバーガーを山積みにしたのもいい思い出です。

ただ、一番インパクトがあったのはいらいざ と会ったことかなと思います。
自作CPU講座とか、自作言語講座とかを開いてくれたけれども手を動かす力が足りなくて途中離脱してしまってました。
ただ、アプリをシュッと作ったり技術を探求し続けるのを見て憧れというか、できることならここまでなりたい。 みたいには思ってみてました(なれませんでしたが)。

ネットワーク講座

1年から3年まで

勝男先輩 が授業に乱入してきて、告知していったことで興味を持ちました。
そもそもどんな技術があるかわからん。みたいな状態だったので、入門講座をしてくれると聞いて飛びついた。

なんかよくわからんから動くからﾖｼｯ みたいなのを繰り返すのは楽しかったです。
2年からは逆に講師をしたり、ゼミの勉強会に参加したりして自分としては頑張ってたようです。
ただ、ospfとbgpの基本機能使って実験して終わり。みたいなことしかしてなかったので、実ネットワーク構築とか商用ネットワークの勉強とか全然してなかったのでもったいなかった。

講座だけでなく、トラブルシューティング会もはじまったのでお手伝いしていました。
大学のホームページなどに載っていたんですが、運営人数の不足等で継続できなくなったのは残念です。
ひとつ、3年前期に蒸発してしまってよねやんに多大な迷惑をかけたのは今でも申し訳ないです。

ICTSC

2年まで参加者、それ以降は運営

参加者の間は、ほぼほぼ何もできないまま予選落ちでした。
そもそも、問題文を見てから利用されている技術を調べるような状態だったので全然ダメでしたが、こんな技術あるんだみたいな勉強にはなりました。

運営に参加した動機としては、運営をするような強い人から刺激を受けるためでした。
えるとくん、たけみおくん等アプリもかけてインフラもできる みたいな人がいっぱい居て自分がこんなところにいていいのだろうかと思った記憶があります。
作問のためMPLSなどの勉強をしたり、トラコン予備校といって過去問を全国各地の学校で解説したり、K8s勉強させてもらったりと、一番成長させていただいた環境だと思っています。

作問

大学院

研究が得意でもないけど、研究とかできる人間になりたいからとりあえず院進するか。みたいな感じで学部3年の終わりに院進を選択しました。
残念ながら学部4年ぐらいからあまりタスクに取り組めない状態が院2年の12月まで続き、技術記事が読めないプログラムが書けないみたいな感じでした。
プチハッカソンの開催、AtCoderの灰diffと茶diffを解くなど気持ちを研究に向かう準備を試みたんですが、なかなか向いてくれず困ってました。
オーキャンの手伝いとか友人とキャンプに行ったりと気分転換を試みても改善なしでしたが、何とか提出することができました。
ただ単に僕が怠惰なだけなのかもしれないです。

ICTSC

ICTSCの運営は継続してやっていましたが、何をやっていたかほぼ覚えていないです。
ただ、運営人数が減って一人2問を作問するのはちょっと大変だった気がします。
僕としては初心者/触ったことがない人のファーストステップ用の問題(ansible問やIPv6 DHCP問)を作ることを心掛けていたんですが、今年の新規運営に「ansible問でansible初めて触りました！」って言ってもらえたので満足です。

作問

問題環境/問題文の作成

6年間の感想 ・今後

僕は運がよくて、いらいざ や勝男先輩にえるとくんやたけみおくん等の憧れ・刺激を与えてくれる人や 勉強させてもらえる環境に恵まれた6年間だったと思います。
結局手を動かせる人にはなれなかった気がするので、これからもっと精進して社会に置いて行かれないようにしたいです。

これから一応ITインフラエンジニアになれるらしいので、楽しみにしています。

Ubuntu2004でHTTP/3のNginxのスループット計測環境をたてる

medium.com

こいつの再現をするためにUbuntu2004に環境を作っていた

NginxのInstallはこれをやるだけ 第4章 実践HTTP/3 ～ 実装を触り、通信を観測し、理解を深める | gihyo.jp

h2loadはで nghttp2をbuildするだけ GitHub - nghttp2/nghttp2: nghttp2 - HTTP/2 C Library and tools

ただし、二つ問題がある 1. clang-14がubuntu2004にない。

llvmの公式のスクリプトはapt-add-keyが動かないので

llvm.sh not installing for Ubuntu 20.04 (focal) · Issue #54676 · llvm/llvm-project · GitHub

を参考に

sudo apt-get update -y
sudo apt-get install -y lsb-release wget software-properties-common apt-utils
wget -O - https://apt.llvm.org/llvm-snapshot.gpg.key|sudo apt-key add -
sudo add-apt-repository -y "deb http://apt.llvm.org/focal/ llvm-toolchain-focal-14 main"
sudo apt-get update -y
sudo apt-get install clang-14

にてInstall 可能

  1. libbpf-dev >= 0.7.0 がない

公式の通りに

 git clone --depth 1 -b v1.0.1 https://github.com/libbpf/libbpf
 cd libbpf
 PREFIX=$PWD/build make -C src install
 cd ..

にてBuildすると

libbpf/build/include/bpf/libbpf.h:70:54: error: ISO C++ forbids forward references to 'enum' types

みたいなエラーが出て利用できない。 これはlibbpfが動かないおそらくこれが関連する ので、v1.0.1からv0.8.1にダウングレードすることで動作する。

 git clone --depth 1 -b v0.8.1 https://github.com/libbpf/libbpf
 cd libbpf
 PREFIX=$PWD/build make -C src install
 cd ..

LinuxのSCTPのDPLPMTUDの探索は本当に線形探索なのか？

LinuxのSCTPのDPLPMTUDの探索は本当に線形探索なのか？

この記事は、 404 Advent Calendar 2022の16日目の記事です。

DPLPMTUとは

MTUはあるホストが受け取り転送できるIPパケットの最大サイズをMTUという。 NWのインターフェースごとに設定でき、デフォルトは1500だがたいていの機器は9000まで設定可能である。
また、送信元から送信先までのMTUの最小値をPath MTUという。

ある機器に到達したパケットのサイズがMTUを超えていると、フラグメンテーション（パケットの分割）やパケットのドロップを行う。
IPv6はデフォルトでフラグメンテーション不可であるし、UDPもフラグメンテーション不可だ。
そのため、Path MTUを調べてそのサイズ以上のパケットを送らないようにする必要がある。

万が一MTUより大きいパケットが来た場合、そのホストはパケットをドロップする際にICMPのエラーでドロップしたパケットの送信元にドロップしたホストのMTUを通知します。この仕組みをPath MTU Discoveryといいます。
しかし、世界では何らかの理由でICMPを拒否するネットワークがあるため送信元までICMPのエラーメッセージが到達しない可能性があります。これをICMPブラックホールといいます。

ICMPブラックホールを避けてPath MTUを計測するために、実際にその大きさのTCPパケットを送信先に投げつけて探索していこうという、Packetization Layer Path MTU Discovery (PLPMTUD) という仕様である。
これのUDPバージョンをDatagram Packetization Layer Path MTU Discovery (DPLPMTUD) という。

本題

昨日、翻訳にかけたブログ 元記事 翻訳かけたやつ

にて、DPLPMTUDの探索アルゴリズムは、失敗するまで32ずつ上昇させて失敗後は4ずつ上昇させて、それでも失敗したらPath MTUを見つけたとして探索を終わると記載がある。

GitHubのリポジトリを覗いたところ、ここが探索時の暫定のPath MTUを上昇させる部分である。
329行目の

t->pl.probe_size = min(t->pl.probe_size + SCTP_PL_BIG_STEP,
                           SCTP_MAX_PLPMTU);

にて SCTP_MAX_PLPMTU(9000byte)より小さい場合は32byteずつ上昇させている。 t->pl.probe_highに値が入らない限り上のしょりが行われる。
では、逆に値が入る条件というのは、ここである。
/* Normal probe failure. */とあるのでprobeに失敗した(投げたPath MTU確認用パケットの応答が送信先から3回なかった)ときのようである。
ここで値が入っているので、SCTP_PL_MIN_STEP(4byte)ずつ増えるこの処理はprobe失敗後の処理であることが分かる。

334行目から342行目の条件分岐は、SCTP_PL_MIN_STEP(4byte)追加後に失敗したprobeのパケットサイズ以上であれば探索のしようがないので探索を終了している。

これらから、RedHatのDeveloperブログにあった

DPLPMTUDの探索アルゴリズムは、失敗するまで32ずつ上昇させて失敗後は4ずつ上昇させて、それでも失敗したらPath MTUを見つけたとして探索を終わる という仕様は本当だった。 という結論にいたりました。

以上、ありがとうございました。

PLPMTUD delivers better path MTU discovery for SCTP in Linux(邦訳)

前書き

PLPMTUD delivers better path MTU discovery for SCTP in Linux | Red Hat Developer

RedHat Developerの上記記事を勝手に訳しました。
自分が読むため用のやつです。途中で力尽きました。
問題があれば消します。（ありそう）
基本はFirefoxの Google翻訳拡張、Mouse Dictionary拡張での翻訳ですが意訳しようとするので間違っているところがあると思います。

PLPMTUD はLinuxのSCTPでよりよい Path MTU Discoveryを 提供する。

Path MTU Discoveryとはなんなのか？

maximum transmission unit (MTU)は、 あるネットワークコネクションにおいて転送可能な単一パケットの最大パケットサイズのことである。 // MTUではなく Path MTU の説明であると思われる

それぞれのネットワークノードは、Path MTU Discovery(PMTUD) と呼ばれる規格をもとに送信するパケットのMTUを定義します。
PMTUD の目的は、受信者に到達できる最も効率的なパケットサイズを選択することです。
この記事では、Linux のSCTP の実装においてどのように機能するかを学習します。

Linux SCTP は、RFC 8899 で説明されている Datagram Packetization Layer Path MTU Discovery (DPLPMTUDもしくはただ単に PLPMTUD と表現される) とよばれるアルゴリズムを使用します。
以前の PMTUD とは異なり、この方法は ICMPの Packet Too Big(PTB)メッセージの受信と検証に依存しません。 //つまりICMPブラックホール耐性がある。さらに、Probeに実際のパケットを使用するため実際の経路のPMTUを計測できる
したがって、この新しい実装は従来のPMTUD よりも堅牢です。

SCTP 用の PLPMTUD は、数か月前に Linux カーネルに実装され、Red Hat Enterprise Linuxのバージョン8.6および9.0でサポートされる予定です。

PLPMTUD の背後にある一般的な戦略は、カーネルのパケット化レイヤー (PL) で実行されます。
さまざまなパケット サイズを使用してプローブ パケットを送信し、ネットワーク パスを介して送信できるフラグメント化されていないデータグラムの最大サイズを決定します。
(PL によって決定された)プローブ パケットが正常に配信された場合、 PLPMTUは成功したプローブのサイズに引き上げられます。
ブラック ホールが検出された場合(つまり、一定のサイズのパケットがの応答が繰り返し受信されない場合)、PLPMTU を減らします。

調査と確認

RFC 8899 では、Probeパケットの内容と受信者から返される確認応答(ACK)が定義されています。
各プローブ パケットは、SCTP 共通ヘッダーとそれに続くHEARTBEATチャンクとPADチャンクで構成されます。
HEARTBEATチャンクにより、受信者はプローブが成功したことを確認するためにHEARTBEAT ACKパケットを送り返します。PADチャンクは、プローブ パケットの長さを指定します。

HEARTBEATチャンクは、PROBED_SIZE フィールドのプローブ パケットのサイズを含む Heartbeat Information パラメータも運びます。
受信者は HEARTBEAT ACK パケットでこの値を返すため、送信者は元のプローブのサイズを特定でき、したがって、以降の通信トラフィックのパケット サイズとして割り当てても安全です。
成功した交換の PROBED_SIZE フィールドが PLPMTU よりも大きい場合、送信者はより大きなサイズの使用を開始できます。
//Heartbeat Information パラメータのPROBED_SIZE フィールドにprobeパケットのサイズを含んでいて、受信者はprobeが届いたことを示すHEARTBEAT ACK パケットにPROBED_SIZEを含める必要がある。このHEARTBEAT ACK のPROBED_SIZEが現在の送信上限として保持しているPLPMTUより大きければ、PLPMTUをPROBED_SIZEに変更する。

Linux での実装では、次のサブセクションで説明するタイマーと変数を使用します。

タイマー

トランスポートごと//たぶん宛先ごとに 1 つのタイマーがあります。このタイマーは、Path MTU ディスカバリーが Search Complete 状態の場合は RFC で定義されている PMTU_RAISE_TIMER として使用され、それ以外の状態では PROBE_TIMER として使用されます。
// Search CompleteはPath MTUを探索しきった状態で、経路変更などによって現状ののPLPMTUより大きい値のPath MTUになっていないかPLPMTUより大きいProbeパケットを投げる。

PLPMTUD が有効になり、Path MTU ディスカバリーがベース状態になると、タイマーが開始されます。
タイマーは PROBE_INTERVAL ごとにタイムアウトするため、ノードは応答がなかったために失われたであろうプローブ パケットを再送信します。

Search Complete 状態になると、タイマーは 30 PROBE_INTERVAL 周期ごとにタイムアウトします。その後、ノードはSearch 状態に戻り、必要に応じてタイマーを使用して再送信をトリガーします。

変数

次の変数は、Linux パス MTU ディスカバリーで値と状態を観察します。 - PLPMTU : 確認できた 最新のPROBED_SIZE を保持します。 PLPMTU とpath MTU - sizeof(IP/IPv6 ヘッダー)は等しい。Path MTU ディスカバリーが Search Complete 状態になると、送信に使用されるPath MTU は PLPMTU + sizeof (IP/IPv6 ヘッダー) の値に更新されます。 - PROBE_COUNT: 送信したが連続して失敗したprobeパケットの数のカウント。probe パケットが確認されると、値はゼロに設定されます。 - PROBE_INTERVAL: PLPMTUD probe timerのスケジュールに使用される時間間隔 (ミリ秒単位)。この期間が経過してもノードがプローブ パケットに対する確認応答を受信できなかった場合、タイマーは期限切れになります。この変数は、プローブ検索が行われるときの現在のPath MTU のprobe間の時間間隔でもあります。 - PROBED_SIZE: PL で決定された現在のprobe パケットのサイズ。この値は PLPMTU の暫定的な値であり、承認による確認を待っています。 //つまり実パケットサイズではなく、probeパケットのサイズ
- PTB/PTB_SIZE: 前述のように、PTB は Packet Too Big の略です。これは、Fragmentation Neededと呼ばれることもあります。 PTB_SIZE はPath MTU に関連していますが、IP ヘッダーの長さが値から差し引かれています。

定数

  • BASE_PLPMTU: ほとんどのパスで機​​能すると予想されて設定されたサイズ。1200 に設定されている。 PLPMTUD は、この値を PROBED_SIZE としてプローブを開始します。実際の PLPMTU がより小さいことが判明した場合、カーネルはエラー状態に入り、IP フラグメンテーションを許可します。
  • MAX_PROBES: PROBE_COUNT カウンターの最大値。任意のサイズのprobeの連続試行がこの値を超えると、状態が変化し、異なるリズムでprobeを開始する可能性があります。この定数は 3 に設定されています。
  • BIG_STEP,MIN_STEP: プローブが成功したときに PROBED_SIZE に追加される増分。 BIG_STEP は、検索状態の開始時に使用されます。プローブが失敗した場合は、代わりに MIN_STEP が使用されます。 BIG_STEP は 32 に、MIN_STEP は 4 に設定されています。

Path MTU 検出のオプションを設定するコマンド

システム管理者または開発者は、このセクションのメカニズムを使用してランタイム パラメータを変更できます。 - sysctl sysctl コマンドは、新しいソケットの PROBE_INTERVAL 値のデフォルト値を提供します。

 sysctl -w net.sctp.plpmtud_probe_interval=1

このパラメーターは、ネットワーク名前空間 (netns) に対して設定されます。新しいアソシエーションはソケットから値を取得し、新しいトランスポートはそのアソシエーションから値を取得します。このパラメーターへの変更は、その後に作成されるソケットのみに影響します。

  • setsocketopt PROBE_INTERVAL をきめ細かく設定するために、このシステム コールはソケット、アソシエーション、さらにはトランスポートの値を変更できます。
 setsocketopt(SCTP_PLPMTUD_PROBE_INTERVAL, interval)

Path MTU Discoveryのステートマシンとステップ

図 1 は、パス MTU ディスカバリーの段階と、それらの間でノードがどのように移動するかを示しています。

図 1: Path MTU Discoveryの段階(引用: PLPMTUD delivers better path MTU discovery for SCTP in Linux )

Base → Search → Search Complete

通常のProbeは Base 状態から開始し、BASE_PLPMTU (1200) のPath MTU でProbeします。
パケットが確認応答されると、Path MTU DiscoveryはSerch状態に入ります。次のprobeは、PROBED_SIZE を BIG_STEP (32) ずつ増加することによって開始されます。

この probe-ack-increment-probe シーケンスは、probe パケットの確認応答が失敗するまで続きます。その場合、ノードは、PROBE_INTERVAL ミリ秒待機した後、同じ PROBED_SIZE でさらに 追加で MAX_PROBES-1回 (デフォルトでは 2 回) プローブを再送信します。

これらのprobeが成功しない場合、ノードは PLPMTU でprobeを開始し、毎回 MIN_STEP (4) ずつインクリメントします。これは、以前と同じ方法で 1 つのprobeが失敗するまで続きます。
ノードは、適切な PLPMTU が見つかったと想定します。ノードはトランスポート時にパス MTU を更新し、Search Complete 状態に入ります。

Search Complete → Search → Search Complete

Search Complete 状態では、ノードは、データの再送信に気付かない限り、PROBE_INTERVAL ミリ秒の 30 間隔の間待機します。

データの再送信があるか、30 の PROBE_INTERVAL 期間が満了すると、ノードは検索状態に入ります。 PROBED_SIZE+MIN_STEP の大きさでprobeでprobeが開始されます。
このprobeが確認されると、次のprobeでサイズが BIG_STEP ずつ増加します。
新しい適切な PLPMTU が見つかると、ノードはトランスポート パス MTU をその値で更新し、Search Complete 状態に再び入ります。

Search/Search Complete → Base

検索中に、PROBED_SIZE が PLPMTU に設定された状態でプローブが失敗すると、「ブラック ホールが検出されました」というエラーが発生し、ノードがBase状態に戻ります。

BASE_PLPMTU を使用してもprobeが失敗した場合、ノードはエラー状態になり、IP フラグメンテーションが許可されます。

パケットが大きすぎるか、断片化が必要です

PTB パケット処理中に、PTB_SIZE が PLPMTU と PROBED_SIZE の間にある場合、次のプローブは PROBED_SIZE が PTB_SIZE に設定された状態で開始されます。これにより、適切な PLPMTU を見つける際のプローブの回数を節約できます。

Path MTU Discoveryのシナリオ例

このセクションには、Linux SCTP のさまざまなシナリオで PLPTUD プローブ中に PROBED_SIZE がどのように変化するかを示す例が含まれています。例は、図 2 のトポロジに基づいています。トポロジには、2 つのクライアントと 2 つのインターフェイスを持つルーターがあります。 - link1_1 のホスト (クライアント) は、link1_2 インターフェイスでルーターとパケットを交換します。 - link2_2 のホスト (サーバー) は、link2_1 インターフェイスでルーターとパケットを交換します。

図 2: この例のネットワーク トポロジ(引用: PLPMTUD delivers better path MTU discovery for SCTP in Linux )

まず、クライアントからサーバーへの SCTP 接続を開始します。

sctp_darn -H 192.168.2.1 -P 8888 -l  # on Server
sctp_darn -H 192.168.1.1 -P 8888 -h 192.168.2.1 -p 8888 -s  # on Client

以下の各シナリオでは、Path MTU Discoveryの変更をトリガーするシステム管理コマンドと、カーネルがPath MTU を設定するための手順を示します。

基本シーケンス

Path MTU Discoveryの多くのシーケンスは、このセクションのものに戻ります。シーケンスは、次のコマンドでトリガーできます。

  iptables -A INPUT -p icmp -j DROP  # on Client, disable the classical PMTUD
  ip link set link2_1 mtu 1400  # on Router

Path MTU Discovery のステップ(Base → Search → Complete):

  1. Probed size: 1200 (BASE_PLPMTUで開始)
  2. Probed size: 1200 (BIG_STEP での増加)
  3. Probed size: 1232 → 1264 → ... → 1356
  4. Probed size: 1388 (IPヘッダを付けると1400を超えるので3回のパケロス)
  5. Probed size: 1356 (MIN_STEPでの増加)→ 1360 → 1364 → ... → 1380
  6. Probed size: 1384 (3回のprobeパケロス,1380に戻る )
  7. Probed size: 1380 ( 確認。Complete状態になる、Path MTUにセット）
  8. Probed size: 1380 (raise-timerを超す,Serch状態になる、MIN_STEPでの増加)
  9. Probed size: 1384(3回のprobeパケロス、,1380に戻る)
  10. Probed size: 1380 ( 確認。Complete状態になる、Path MTUにセット） ...

そろそろ飽きたので終わり。

VSCodeでaddrinfo がエラーになる

上の画像のようにaddrinfoの変数にエラーが出る。
実際にはコンパイルできるが、エラーが邪魔である。

github.com

解決方法は、上記issueの通り、

  1. ctrl + shift + P で C/C++ : Edit Configuretions を開く(UI/JSONどちらでもよい)
  2. Definesの項目を見る
  3. 以下のように書き換え
- "defines": [
- ],
+ "defines": [
+      "__linux__",
+     "__x86_64__",
+     "_GNU_SOURCE"
+ ],

{
    "configurations": [
        {
            "name": "Linux",
            "includePath": [
                "${workspaceFolder}/**"
            ],
            "defines": [
                "__linux__",
                "__x86_64__",
                "_GNU_SOURCE"
            ],
            "compilerPath": "/usr/bin/gcc",
            "intelliSenseMode": "linux-gcc-x64",
            "cStandard": "c11",
            "cppStandard": "c++17"
        }
    ],
    "version": 4
}

UIの場合はこう

Windows11でNVMe SSDからSATA SSDにクローンしたら inaccessible boot device で起動できなかったのを直した話 + Crucialのクローンソフトがアンインストールできなかった話

タイトル通りです。 利用しているノートPCのストレージが128GBでしたが、手狭だったため家で余っていた512GBのSATA SSDにクローンしました。

ストレージのクローンの仕方自体は簡単でUbuntuのインストール用USBを用意して、Try Ubuntuを選択したうえでddコマンドでクローン。必要に合わせて gpartedなどでパーティションのサイズを変えてあげればよい。

基本的には下記サイト通りにすればよい。 クローンディスクの作り方 (1) Linuxの場合 - 虎之助の徒然記 gpartedで1MBの隙間ができるのは、拡張したパーティションじゃないほうが勝手に1MB減らされてます。治してあげればよいです。

ただ、私はCrucialでクローンソフトが使えたのを思い出したのでそちらを使いました（これは失敗）

問題

クローン自体はつつがなく終わったが クローンして作ったSSDが inaccessible boot deviceでブートしてくれない。雰囲気としてセキュアブートかなという気持ち。 GPTのパーティションの修復・ブートローダーの再構築・修復など inaccessible boot deviceで検索して出てきた一通り試したが駄目だった。

解決方法

おそらくセーフモードでの起動によってブートできるようになる。 正確に私が実行した手順としては、 inaccessible boot deviceの画面が２回出ると、シャットダウンかトラブルシューティングかを選べる。
トラブルシューティングを選びWindowsアップデートの機能アップデートをアンインストールを実行した。こちらはディスクにアクセスできないのようなエラーが出たためできず。
品質管理アップデートをアンインストールしたところ、こちらはアンインストールに成功した。
そのうえで、セーフモードで起動したところアップデートの適応に失敗したので復元します。という画面になった。
一度再起動したのち、セーフモードの低画質ではなく通常の画質で同じ画面が出てきたあとログインできるようになった。

アップデートの適応に失敗したので復元します。という画面はなかなか時間がかかったのでほっておいて待つしかなさそう。

Crucial SSDの場合使える Acronis True Image が付属のuninstallerだとuninstall できない問題

ようは、Acronis True Image の uninstallerをHPからダウンロードしてくる必要がある。 レジストリエディタでいらないものも探す必要があるらしいが、私は見つからなかった。

Acronis Cyber Protect Home Office, Acronis True Image: クリーンアップユーティリティ | Knowledge Base

Windows11 でインストール時にローカルアカウントを作成する。

PCトラシュー

インストール時にローカルアカウントの作成を何とかして阻止しようとてくるWindowsですが、昨日試してみたのでそれのメモ

私が見たときにはインストール開始をしていてWIFIに接続してしまっていました。

ローカルアカウントで「Windows 11 Home」をセットアップする方法 - やじうまの杜 - 窓の杜

Impressの記事にある２つの方法を試したがどちらもMicrosoftアカウントのログインに戻される。

Impressに記載されていたツイートの引用RTにこのようなものがあった。

Shift + F10でコマンドプロンプトを起動後

netsh wlan show profile

で設定したWiFiのプロファイルを探し、

netsh wlan delete profile name="プロファイル名"

でプロファイルを削除してしまう。 すると、ローカルアカウント作成画面に入れ替わる(なければ前の画面にもどる<- ボタンを押してください)

有線ではどうなるかわからないのでそのうち調べたい