おボえとケよ - Linux 設定日記

2025.08.15

mdadmソフトウェアRAIDが、initramfsステージの起動時に再構築されない(解決)。

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

状況

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

原因調査のポイント

initramfsにmdadm（mdraid）関連モジュール・スクリプトが含まれているか

lsinitrd コマンドでinitramfs内のmdraid関連ファイルを確認する
もし含まれていなければ、dracut コマンド実行時のオプションで強制的にmdadm関連を追加する必要がある

rd.md.uuid= にRAIDアレイのUUIDが正しく指定されているか

/etc/default/grub の GRUB_CMDLINE_LINUX に rd.md.uuid=... が必須
ここで指定するUUIDは、mdadm --detail --scan のARRAY行に表示されるRAIDのUUIDであり、ファイルシステムのUUIDとは異なる

initramfsに反映されているか

dracut -f や dracut --force --add raid1 などでinitramfsを再生成し、最新設定を反映させる
kernelアップデート時に自動で正しくinitramfsが作られるよう、dracut の設定を確認・調整する

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

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

/etc/default/grub にrd.md.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 ..."

initramfsにraid1を含める

sudo dracut --force --add raid1

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

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

grub設定の再生成と反映

UEFI環境の場合：

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

BIOS環境の場合：

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

まとめ

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

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

2023.08.14

clamdscanをrootで実施しているのに、Access deniedやParmission denidのログが残る。

ここを参考に、/etc/cron.daily/clamdscanを修正。

--- /etc/cron.daily/clamdscan.orig      2023-08-15 09:15:11.496374765 +0900
+++ /etc/cron.daily/clamdscan   2023-08-15 09:05:23.429737649 +0900
@@ -5,7 +5,7 @@
 CLAMSCANLOG=`mktemp`
 QUARANTINEDIR=/tmp/clamdscan-quarantine-$(date +%Y%m%d)
 mkdir -p ${QUARANTINEDIR}
-clamdscan -c ${CONFIG} --move=${QUARANTINEDIR} / > ${CLAMSCANLOG} 2>&1
+clamdscan -c ${CONFIG} --move=${QUARANTINEDIR} -fdpass / > ${CLAMSCANLOG} 2>&1

 # ウイルス検知時、root宛にメール通知
 if [ -z "$(grep FOUND$ ${CLAMSCANLOG})" ]; then

追加したのは、fdpathオプション。このオプションは、manによると、

    --fdpass
        ファイルディスクリプタの権限をclamdに渡します。
        これは、clamdが異なるユーザーとして実行されている場合に役立ちます。
        ファイルをclamdにストリーミングするよりも高速です。local(unix)ソケット経由でclamdに接続されている場合にのみ使用可能です。

元ネタは英文だったので、ChatGPTに翻訳してもらった。

2023.08.13

systemd メッセージ (Created slice, Starting Session) でログがいっぱいになる

redhatの公式Kkowledgebaseにある通りではあるが、それだけでは足りなかったので。
一通りRedhatのナレッジの通りやった後、以下を追加。

/etc/rsyslog.d/ignore-systemd-session-slice.confに下線部を追加。

if $programname == "systemd" and ($msg contains "Starting Session" or $msg contains "Started Session" or $msg contains "Created slice" or $msg contains "Starting user-" or $msg contains "Starting User Slice of" or $msg contains "Removed session" or $msg contains "Removed slice User Slice of" or $msg contains "Stopping User Slice of" or $msg contains ".scope: Succeeded.") then stop

一応念のため、redhat公式にあるtestuserは、以下のような実際にログを参照して、それぞれUIDのユーザ名に、user@1000.service.dの1000の部分はログに残っているUIDに読み替えが必要です。

Starting User Manager for UID 1001...

ついでに、clamdのSelfCheck: Database status OK.も大量に出るので、rsyslogdで抑止。以下の内容で/etc/rsyslog.d/ignore-clamd-session.confを作成して、rsyslogdを再起動。

if $programname == "clamd" and ($msg contains "SelfCheck: Database status OK.") then stop

2023.03.23

rainloopの認証をotp化したら何度も再認証が要求される

rainloopで自サーバにためたメールを外からみれるようにした。認証として、mod-auth-otpを使用して、rainloopのディレクトリに対してotpでの認証をするようにした。最初は問題無かったが、5分ほどたつと再認証を要求される。

最初はrainloopがキャッシュフォルダを作成すると、そのフォルダに対して再度認証が発生するのかと思い、認証対象をphpとhtmlに限定してみたが、状況は変わらない。 apacheのログをみると、

[Thu Mar 2 20:45:28.673569 2023] [:error] [pid 2308149:tid 140698380637952] [client 192.168.107.2:57102] can't new open OTP users file "/etc/httpd/conf.d/users.otp.new": Permission denied, referer: XXXXX
[Thu Mar 2 20:45:34.860612 2023] [:notice] [pid 2308149:tid 140697961232128] [client 192.168.107.2:57110] user "XXXX" provided the wrong OTP (2 consecutive), referer: XXXX

のようなエラーメッセージが出ていた。 users.otpのファイルには、apahceからのアクセス権があるが、ディレクトリに対してはないため、新しいファイルが作成できないようだ。エラーメッセージで検索すると、githabに「Authentication should fail if users file is not writable (but is readable)#26」というスレッドがあり、以下のコマンドでユーザログインの認証の更新を確認するように指示があった。確認した結果、構築時に認証した時間から更新されていないようだった。

    # watch -d cat /etc/httpd/conf.d/users.otp

users.otpファイルを置くディレクトリを変更し、そのディレクトリに対して、apacheユーザからの書き込み権限を許可したところ、事象が改善したように見える。