Windows Server 2022 Essentials、Windows Update後の再起動から、ドットくるくる画面のまま起動しない。休日に再起動して24時間以上このまんまのようだ。
SSDへのアクセスも止まっているようなので、これ以上は進行しない状況と判断して強制電源断。

セーフモードの起動も、セーフモードとコマンドプロンプトも、起動時マルウェア対策ドライバー無効も試したが、全てくるくる途中で停止（くるくるすら出ないことも）。停止した判定ラインを5分として考えたので時間がかかる…
さらには復元ポイントも作られておらず、まぁどうしようもない。

ドットくるくる画面から進まない状況は、Windows Updateの中途半端なやつが引っかかってるらしく、それを解消すれば直るよ！ということらしいので、まぁDell公式にも書いてるしやってみる。

修復環境（Windows REだかPEだか）でコマンドプロンプトへ進む。一応chkdskもかけるが問題なし。どうやらハードウェア障害ではなく、windows上の論理的な衝突が原因であるようだ。
ということで指示通りDISMで回復を試みる。修復環境では起動ドライブがX:、回復パーティションがC:になったのか、Windows本体はD:になっていたので、ドライブ指定を行う。

DISM /Image:D:\ /Cleanup-Image /RevertPendingActions

作業領域が足りないなどと出るので、データドライブで確保していたE:を割当。

DISM /Image:D:\ /Cleanup-Image /RevertPendingActions /ScratchDir:E:\scratch

これがエラー 0x800f082f で終了してしまう。
下記コマンドで個別にWindows Updateのパッケージをリストから見て指定することもできるようだが、今回はそちらには至れず。Get-Packagesも同様に0x800f082fエラーを出していた気がする。

DISM /Image:D:\ /Get-Packages
DISK /Image:D:\ /Remove-Package /PackageName:(packagename)

このDISMのRevertPendingActionsでやっていることは、レジストリに残っているUpdate途中だよという記録を消すことらしく、DISMコマンドが成功しないなら手動でやるような手もあるとのことで、試してみる。
レジストリをロードして、regeditで「HKEY_LOCAL_MACHINE\Offline_Software\Microsoft\Windows\CurrentVersion\Component Based Servicing\PackagesPending」を確認して中身を削除、レジストリを書き出すという手順だったが、途中のregeditで見てみると、PackagesPendingキーの下にサブフォルダが数百個あった。これはくるくる状態で無限に増えたりしていたのではないか…？
とりあえずコマンドラインで全削除を行い、元キーも空で作り直すことにした。

reg load HKLM\Offline_Software D:\Windows\System32\config\SOFTWARE
reg delete "HKEY_LOCAL_MACHINE\Offline_Software\Microsoft\Windows\CurrentVersion\Component Based Servicing\PackagesPending" /f
reg add "HKEY_LOCAL_MACHINE\Offline_Software\Microsoft\Windows\CurrentVersion\Component Based Servicing\PackagesPending"
reg unload HKLM\Offline_Software

さらに保留ファイル pending.xml も念のためリネームして削除扱いにする。

cd d:\Windows\WinSxS\
ren pending.xml pending.xml.bank

この状態で再起動してもまだドットくるくる。再度DISM /Cleanup-image を試すも 0x800f082f は変わらず。
どこかもっと奥での衝突状態のようだ。
いい加減に時間ばかりが過ぎてしまうので別の策を考える。幸いディスクの中身は保全されているので、修復環境のままできるだけのファイルを外部USB-SSDに書き出す。40GB程度で済んだのでこれもまぁ幸い。

別PCでMicrosoftのサイトからWindows Server 2022のisoイメージをダウンロード、rufusを使って起動可能なUSBメモリを作成。再インストールして全部やりなおすことにした。

WindowsインストーラーUSBメモリから起動した画面には「今すぐインスト-ル」の他に「修復」的なメニューもあり、一応こちらも試してみるが、回復ポイントも無いし、結局「Windowsに進む」以外の選択ができなかった。

が！

そしたら元のWindowsがすんなり起動してくれてしまいました＼(^O^)／

ドライバ関係も⚠マーク出たりしてないし、念のため再度再起動しても問題ナシ。
あとは衝突ナシでwindows updateが通ってくれることを願う…

ということで、修復環境じゃダメでも外部USBメモリ起動からならなんとかなるかもしれない？という結論。そうか、そうですか…。

Celeron N2830搭載のIntel NUCにCentOS Stream9を入れて使っておりましたが、ある日しばらくやっていなかったアップデートを行って再起動すると、bootloader画面すら出ない、Intel NUCのBIOS起動画面から固まって先に進まなくなってしまいました。再起動直後にF2でUEFI Setup画面には入れるので、bootloaderに入った直後に固まってしまっているのでしょう。

■Centosは私のNUCで起動できません : r/CentOS

Redditのこのトピックそのまんま。
ということはこの解決法を試せばそれでいけるはず。

Secure Bootはoffになっている。Legacy Bootを試そうにもUEFIインストールされていたので起動デバイスの選択肢に出てこない。CentOS Stream9のインストーラーUSBメモリがあったのでそれで起動して、rescue起動。

CentOS Stream9のrescueは、自動的に既存インストールのファイルシステムを /mnt/sysroot にマウントしてくれているので、上記Redditを参考に下記を実施。

mount --bind /dev /mnt/sysroot/dev && mount --rbind /sys /mnt/sysroot/sys && mount -t proc /proc /mnt/sysroot/proc
chroot /mnt/old /bin/bash
mount -a
dnf install grub2-efi-x64-modules.noarch
/usr/sbin/grub2-install --force

途中grub2-installを実行しようとしたら /usr/lib/grub/x86_64-efi/modinfo.sh doesn’t exist. とエラーが出たが、dnf install grub2-efi-x64-modules.noarchで必要なファイルが入る。
またsecure boot無効な環境ではgrub2-installが警告を出してくるので –force でそのまま実行。

exitでrescueを抜けると自動で再起動。無事に起動しました。
冷や汗かいたー