いままでやってきたことを含めて、解決に至るまでをまとめた。

状況

• システムのrootファイルシステムはmdadmで構成したRAIDデバイス（例：/dev/md/root）上にある
• ブート時にinitramfsがRAIDデバイスを正しく認識せず、rootマウントに失敗して起動できない
• initramfs内のソフトウェアRAIDモジュールの有無やロード状態に問題があると思われる/li>

原因調査のポイント

1. initramfsにmdadm（mdraid）関連モジュール・スクリプトが含まれているか
• lsinitrd コマンドでinitramfs内のmdraid関連ファイルを確認する
• もし含まれていなければ、dracut コマンド実行時のオプションで強制的にmdadm関連を追加する必要がある
2. rd.md.uuid= にRAIDアレイのUUIDが正しく指定されているか
• /etc/default/grub の GRUB_CMDLINE_LINUX に rd.md.uuid=... が必須
• ここで指定するUUIDは、mdadm --detail --scan のARRAY行に表示されるRAIDのUUIDであり、ファイルシステムのUUIDとは異なる
3. initramfsに反映されているか
• dracut -f や dracut --force --add raid1 などでinitramfsを再生成し、最新設定を反映させる
• kernelアップデート時に自動で正しくinitramfsが作られるよう、dracut の設定を確認・調整する

トラブルシューティングの手順例

1. RAID UUIDを確認する

mdadm --detail --scan

結果例：

ARRAY /dev/md/root metadata=1.2 UUID=89abcdef:01234567:98765432:a1abcdef ARRAY /dev/md/boot metadata=0.90 UUID=87654321:01ab23cd:89abcdef:b2abcdef ARRAY /dev/md/home metadata=1.2 UUID=a0b1c2d3:89abcdef:76543210:c3abcdef

2. /etc/default/grub にrd.md.uuidを設定する
rd.md.uuid= オプションには上記のRAID UUIDを指定する。

GRUB_CMDLINE_LINUX="rd.md.uuid=89abcdef:01234567:98765432:a1abcdef rd.md.uuid=87654321:01ab23cd:89abcdef:b2abcdef rd.md.uuid=a0b1c2d3:89abcdef:76543210:c3abcdef ..."

3. initramfsにraid1を含める

sudo dracut --force --add raid1

dracutでraidモジュールを強制追加して再生成する。raid1の部分は、使っているraidに合わせて指定する。raid4/5/6は一つのドライバだが、raid5などと指定すれば、当該ドライバがインストールされる。

4. initramfsにraid1が含まれたことを確認する

sudo lsinitrd | grep raid mdraid -rwxr-xr-x 1 root root 155 Aug 15 16:50 usr/lib/dracut/hooks/cleanup/99-mdraid-needshutdown.sh -rwxr-xr-x 1 root root 691 Aug 15 16:50 usr/lib/dracut/hooks/pre-mount/10-mdraid-waitclean.sh -rw-r--r-- 1 root root 6044 Aug 15 16:50 usr/lib/modules/(KERNEL-RELEASE)/kernel/crypto/async_tx/async_raid6_recov.ko.xz -rw-r--r-- 1 root root 25112 Aug 15 16:50 usr/lib/modules/(KERNEL-RELEASE)/kernel/drivers/md/raid1.ko.xz -rw-r--r-- 1 root root 2631 Aug 15 16:50 usr/lib/udev/rules.d/63-md-raid-arrays.rules -rw-r--r-- 1 root root 2259 Aug 15 16:50 usr/lib/udev/rules.d/64-md-raid-assembly.rules -r-xr-xr-x 1 root root 11896 Aug 15 16:50 usr/lib64/device-mapper/libdevmapper-event-lvm2raid.so lrwxrwxrwx 1 root root 44 Aug 15 16:50 usr/lib64/libdevmapper-event-lvm2raid.so -> device-mapper/libdevmapper-event-lvm2raid.so -rwxr-xr-x 1 root root 493 Aug 15 16:50 usr/sbin/mdraid-cleanup -rwxr-xr-x 1 root root 1831 Aug 15 16:50 usr/sbin/mdraid_start

5. grub設定の再生成と反映

UEFI環境の場合：

sudo grub2-mkconfig -o /boot/efi/EFI/rocky/grub.cfg

BIOS環境の場合：

sudo grub2-mkconfig -o /boot/grub2/grub.cfg

まとめ

1. rootファイルシステムがソフトウェアRAID上にある場合は、initramfsにmdraidモジュールが必須
2. rd.md.uuid= はRAIDのUUIDを指定し、正しくgrubのカーネルコマンドラインに含める
3. initramfsとgrub設定の再生成を忘れずに行う

過去、1,3は実施していたが、uuidの指定がファイルシステムのuuidを指定していたため、raidが再構築できていなかった。 この問題を修正した結果、RAID上のrootファイルシステムから正常に起動できるようになった。

機種変更時のAuthenticaterの移行方法のメモ

最初、ここを参考にしていたが、「サインイン中に問題が発生しました」と表示されて入れない。調べたら、この方法は企業など独自のEntra-IDなどの場合の手順だった。

個人のアカウントの場合は、バックアップからアカウントの資格情報を復元するを実施する必要があった。

新しいPCは、WiFi 6Eに対応している。なのでWiFiルーターも更新することにした 。

WiFi 5からの目玉機能としてはメッシュWiFiがあるが、現在のWi-Fiルーターおよび中継器はWiFi 4相当なのでメッシュ機能に対応していない。 なので、ルーターとして使っているAterm WG2600HSと、メインの中継器であるAterm WG2200HPをAterm WX5400T6とAterm WX11000T12に更新した。

WiFi 6Eでは6GHzをバックホールとして使うことができ、LANの高速通信が期待できるので、ルーターをT6に、主に利用する環境のAPをT12にして普段の接続の高速化を狙った。 メッシュ化はマニュアルどおりに実施することで特に問題なく完了。リンク速度は2.4Gbpsがでており期待通りとなった。

しかしながら、従来の中継器を別の場所のレピータ(有線LAN延長)に使用しようとしたら問題が発生。 どうやら完全子機としては使えず、WiFiを中継器仕様とするため、無線LANの競合がおこり、電波をとめてしまっている模様。 バンドステアリングをoffにして電波帯ごとに個別のSSIDを割り振れば使えるのかもしれないが、ssidは一つにしたいので、保管していたAtermWL300NE-AGを引っ張りだすことに。 こちらはちゃんと子機として認識してリピーターとして使用できた。

T460sがWindows 11にアップデートできないため、X13 Gen5を購入。 Tシリーズが好きだったが構成的に気に入った形が選べなかったので一回り小さいXシリーズを購入した。

いろいろアップデートしていたたら、ディスプレイが暗くなってしまい、OS設定やキーボードから変更しても明るくならなくなった。 Intelのドライバー&サポートアシスタントですべてのドライバーを更新したのが原因だった。

レノボのサポートサイトからドライバーをダウンロードして元に戻して修復完了。 今まで20年以上ThinkPadを使い続けてきたが、インテルドライバーで問題なかったので初めての事象だった。

Shuriken 2018ならShuriken TLS設定ツールで対応できるのだが、2016なので繋がらない。 なので、stunnelで、rocky linuxのサーバにproxyを立てて、TLS 1.0 <-->TLS 1.2のバージョン変換をすることにした。 stunnelはwindows版もあるので、サーバーではなくPCそのものにインストール・設定してもつかえるかもしれない。
参考にしたのは、このページ。
stunnelはパッケージがあるので、dnf install -y stunnelでインストール。 設定ファイルは、/etc/stunnelにおけば名前はなんでも良いようだが、慣例にしたがってstunnel.confとした。記述内容は以下のとおり。

# /etc/stunnel/stunnel.conf # Log settings output=/var/log/stunnel.log service=stunnel # connect to sonet [TLS_proxy_connector] client = yes accept = 127.0.0.1:2525 protocol = smtp connect = mail.so-net.ne.jp:587 sslVersion = TLSv1.2 # connect from shuriken [TLS_proxy_listener] accept = 9025 protocol = smtp key = /etc/letsencrypt/live/jp-oota.net/privkey.pem cert = /etc/letsencrypt/live/jp-oota.net/cert.pem CAFile = /etc/letsencrypt/live/jp-oota.net/fullchain.pem connect = 2525

[TLS_proxy_connector]のセクションは、so-netへ接続させるためのもの。参考にしたページは証明書のverifyをしていたが、ルート証明書の指定と管理が面倒なのでverifyは行わないこととした。
sslVersionの設定は最初はしていなかったが、接続できなかったので追加した。 しかしながら、接続できなかったのは後述の「STARTTLSを使用」の設定の問題かもしれず、不要の可能性もあるが未検証。現時点では実害はないはずなので、そのまま。
[TLS_proxy_listener]のセクションは、shurikenからの接続を受けるためのもの。9025ポートでlistenして、2525ポートにforwardしている。 このポート番号は[TLS_proxy_connector]セクションのAcceptで受けているポートと合わせる必要がある。
証明書ファイル類は、letsenvryptでwebサーバ用に作成したものを指定した。 なので本当のファイル名はちょっと違し、メールサーバらしからぬFQDN。
また、firewallで不要なポートは閉じていたので、/usr/lib/firewalld/serviceに、9025ポートのservice定義を書いてfirewall-cmdでポートを開けた。

これで、shurikenのアカウント登録設定の「送信(SMTP)サーバの名前」にstunnelが動作しているサーバ名(SSL証明書と一致するもの)、「送信サーバのポート番号」に9025を指定し、「SSLを使用」を「する」に、「STARTTLSを使用」を「しない」にすることで、メール送信が可能になった。