CentOS7.x の xfs_repair の実行に関してですが、
一番簡単なのが、 CentOS7 Live USB か、CentOS7 install USB のレスキューモードから
行うのが一番簡単です。
第３の方法としては、
GRUB のメニュー画面から シングルモードで起動して行う方法と、一度 テキストモード(run level 3) で
ログインてから、 init 1 (run leevel 1) へ移行して行う方法を順に行う方法があります。
1. GRUB から シングルモードで起動して、 ACTIVE な ロジカルボリュームを xfs_repair で修復します。
但しこの方法では、inactive なロジカルボリュームは、 ACTIVE に変更しても、xfs_repairを実行できません。
参考になるのは下記ページですが、
https://qiita.com/ysakkk/items/d2268bbe41de39a7c8aa
おんちゃんは、この方法では上手くいかなかったので、補足します。
1) GRUB のメニュー画面で、 'e' で編集モードになる。
2) linux16 の行で、 crashkernel=auto LANG=ja_JP.utf8 を削除して、init=/sysroot/bin/sh を追加します。
変更前
linux16 /vmlinuz-3.10.0-xxxxxx root=/dev/mapper/cl-root ro rd.lvm.lv=cl/root rd.lvm.lv=cl/swap rd.lvm.lv=cl/usr crashkernel=auto LANG=ja_JP.utf8
変更後
linux16 /vmlinuz-3.10.0-xxxxxx root=/dev/mapper/cl-root ro rd.lvm.lv=cl/root rd.lvm.lv=cl/swap rd.lvm.lv=cl/usr init=/sysroot/bin/sh
CTL-x で実行
:/#lvm lvscan
ACTIVE '/dev/cl/root'
ACTIVE '/dev/cl/swap'
ACTIVE '/dev/cl/usr'
inactive '/dev/cl/var'
inactive '/dev/cl/opt'
inactive '/dev/cl/tmp'
inactive '/dev/cl/home'
で、ここで、xfs_repair を実行出来るのは、/dev/cl/root, /dev/cl/usr です。
それぞれ unmount して、xfs_repair を実行します。
:/#umount /dev/cl/usr
:/#umount /dev/cl/root
:/#xfs_repair /dev/cl/usr
:/#xfs_repair /dev/cl/root
注)ここでunmount すると、sysimage の方のディレクトリーが現れるみたいです。
終了は、halt でしょうか?
:/#halt
2.次に、テキストモード(run level 3) でログインてから、 init 1 (run level 1) へ移行して行う。
テキストログインでログインして
#init 1
で、 runlevel 1 に移行するので、
#lvscan
ACTIVE '/dev/cl/home'
...
アンマウントして
#unmount /dev/cl/home
#xfs_repair /dev/cl/home
しかし、この1. 2.の方法では、/boot (/dev/sda1) は、xfs_repair をできません。
やはり、CentOS7 Live USB か、CentOS7 install USB のレスキューモード を使うのが、手っ取り早いと言うことです。
但し、壊れた、XFS 修復には、手間取るみたいです。
https://codeday.me/jp/qa/20181210/5130.html
多分、xfs は、マウント時に、ジャーナルが修復されるとあります。
https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/7/html/storage_administration_guide/migrating-ext4-xfs
なので、ここは、 CentOS7 Live USB で起動して、修復したいパーティションを、
一度、 CentOS7 Live USB の /mnt 下で mount と unmount を順に行って
その後で、 xfs_repair を行えば良い様ですが、そこでのトラブルなので厄介のようです。
そもそも、 HDD のハードの障害であれば、難しいかも?
取り敢えず、 badblocks コマンドでチェックしてから、その後
修復を行う方が良いと思いますが。
ext3 であれば、 badblocks と fsck を連動させて、不良セクターを使わないようにする方法があった気がしますが。