HDDシングル構成からRAID[mdadm]構成に移行する

移行前に検証した時の手順を記録

0. 目次

  1. 検証環境
  2. 手順

1. 検証環境

  • 仮想環境(KVM)
  • OS:Rocky Linux 8.6
    • 4.18.0-372.9.1.el8.x86_64
  • RAIDはRAID5で構築

2. 手順

  1. インストールディスクから起動
    起動後、Troubleshooting > Rescue a Rocky Linux system > 3) Skip to shell の順に選択する。


  2. ディスクの情報
    移行先のディスクは移行後を想定してパーティションを切る必要がある。(以下はすでに済んでいるもの)
    移行元:/dev/vda
    移行先:/dev/vdb, /dev/vdc, /dev/vdd
  3. RAID構築
    今回はRAID5で構築
    マウントPath
    md0:/boot
    md1:/var
    md2:swap
    md3:/
  4. RAIDデバイスをフォーマット
    mkfsコマンド、またSWAP領域はmkswapコマンドを利用してフォーマットする。
  5. 移行元から移行先に転送
    以下のコマンドで、対応するデバイスについて移行元から移行先に転送する。

    # mount /dev/md0 /mnt/frm
    
    # mount /dev/vda1 /mnt/dst
    
    # rsync -avu --progress /mnt/frm/ /mnt/dst/
  6. 移行先のfstab、grubの情報を修正
    例では/mnt/をTopに移行先のRAIDデバイスをマウントする。
    また、proc, /dev, /sys をマウントし、chrootする。

    RAIDデバイス(ファイルシステム)のUUIDをblkidコマンドで確認して、/etc/fstab ファイルを新しいUUIDで書き換える。

    RAIDデバイスのUUIDを調べ、「/etc/default/grub」ファイルを修正する。

  7. 起動イメージ再作成
    RAIDデバイスを起動時に読み込めるようにするため、カーネルモジュールを起動イメージに追加する必要があるため、initramfsを再作成する必要がある。
  8. 【任意】SELinuxを利用している場合
    rootファイルシステムに 「.autorelabel」というファイル名で空ファイルを作成し、次回起動時にリラベル処理を行うようにする必要がある。
    これを行わないと正しいIDとPWを入力してもログインが行えなくなる。。。

HP Microserver N54L – Rocky Linux 8 のeSATAドライブが認識しない

0. 目次

  1. 環境
  2. 事象
  3. 原因
  4. 解決法

1. 環境

  • ハードウェア:HP Microserver N54L
  • OS:Rocky Linux 8.6
    • Kernel Version:4.18.0-372.26.1.el8_6.x86_64

2. 事象

HP Microserver N54LにCentOS 7 を入れて使用していたが、Rocky Linux 8 に移行した。
元々eSATAを利用してバックアップを取得していたが、同様に接続をしてもHDDが認識されなかった。

3. 原因

Redhat系は古いハードウェアのドライバが削除されているみたいです。
RHEL 8で削除されたドライバの一覧はこちら

HP Microserver N54LはODD用のSATAポートとeSATAポートのAHCIは無効化されているらしく、つまりIDEの古い規格の接続であり、古いドライバが削除されているため認識されていないのだと考え、そのあたりで色々と調べたところ以下のページを見つけた。

https://bugs.centos.org/view.php?id=16898

このページで記載されているlshw -class disk -class storageコマンドを実行したところIDEのコントローラーに「UNCLAIMED」と記載されており、ドライバが存在しないことが原因だった。

# lshw -class storage
  *-sata
       description: SATA controller
       product: SB7x0/SB8x0/SB9x0 SATA Controller [AHCI mode]
       vendor: Advanced Micro Devices, Inc. [AMD/ATI]
       physical id: 11
       bus info: pci@0000:00:11.0
       logical name: scsi0
       logical name: scsi1
       logical name: scsi2
       logical name: scsi3
       version: 40
       width: 32 bits
       clock: 66MHz
       capabilities: sata msi ahci_1.0 bus_master cap_list emulated
       configuration: driver=ahci latency=64
       resources: irq:25 ioport:d000(size=8) ioport:c000(size=4) ioport:b000(size=8) ioport:a000(size=4) ioport:9000(size=16) memory:fe6ffc00-fe6fffff
  *-ide UNCLAIMED
       description: IDE interface
       product: SB7x0/SB8x0/SB9x0 IDE Controller
       vendor: Advanced Micro Devices, Inc. [AMD/ATI]
       physical id: 14.1
       bus info: pci@0000:00:14.1
       version: 40
       width: 32 bits
       clock: 66MHz
       capabilities: ide isa_compat_mode pci_native_mode bus_master
       configuration: latency=0
       resources: ioport:1f0(size=8) ioport:3f6 ioport:170(size=8) ioport:376 ioport:ff00(size=16)

4. 解決法

ELRepoで古いドライバを提供してくれているため、それを利用して解決した。

以下のページに記載されている手順で、必要なファイルを特定しインストールを実施。

http://elrepoproject.blogspot.com/2019/08/rhel-80-and-support-for-removed-adapters.html

4-1. 手順

  1. ELRepoでドライバが提供されているか確認
    どのドライバを導入すればよいかの確認にもなる。
    3のlshw -class storageで「UNCLAIMED」となっていたproduct名を使用してデバイスIDを調べる。
    以下の結果から [1002:439c]とわかる。

    # lspci -nn | grep "SB7x0/SB8x0/SB9x0 IDE Controller"
    00:14.1 IDE interface [0101]: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 IDE Controller [1002:439c] (rev 40)

    このページでデバイスIDを検索して存在すれば提供されており、今回の場合「pata_atiixp.ko」を導入すればよいことがわかる。

  2. ドライバのダウンロード
    以下のURLから1の手順で特定した「pata_atiixp」のものをダウンロードする。
    https://elrepo.org/linux/dud/el8/x86_64/
  3. ドライバのインストール
    2のドライバはISO形式で提供されているので、以下のコマンドでマウントする。
    mount -t iso9660 ./dd-pata_atiixp-0.4.6-3.el8_6.elrepo.iso /mnt/iso/
    マウントした場所から「rpms/x86_64」に移動すると「kmod-pata_atiixp-0.4.6-3.el8_6.elrepo.x86_64.rpm」というファイルが存在するのでこれをインストールする。
    # dnf localinstall kmod-pata_atiixp-0.4.6-3.el8_6.elrepo.x86_64.rpm
  4. カーネルモジュール読み込み
    以下のコマンドを実行し、カーネルモジュールを読み込む
    modprobe pata_atiixp
    読み込んだ後にlshw -class storageコマンドを実行すると以下のように「UNCLAIMED」が消えコントローラが利用できるようになった。

    # lshw -class storage
      *-sata
           description: SATA controller
           product: SB7x0/SB8x0/SB9x0 SATA Controller [AHCI mode]
           vendor: Advanced Micro Devices, Inc. [AMD/ATI]
           physical id: 11
           bus info: pci@0000:00:11.0
           logical name: scsi0
           logical name: scsi1
           logical name: scsi2
           logical name: scsi3
           version: 40
           width: 32 bits
           clock: 66MHz
           capabilities: sata msi ahci_1.0 bus_master cap_list emulated
           configuration: driver=ahci latency=64
           resources: irq:25 ioport:d000(size=8) ioport:c000(size=4) ioport:b000(size=8) ioport:a000(size=4) ioport:9000(size=16) memory:fe6ffc00-fe6fffff
      *-ide
           description: IDE interface
           product: SB7x0/SB8x0/SB9x0 IDE Controller
           vendor: Advanced Micro Devices, Inc. [AMD/ATI]
           physical id: 14.1
           bus info: pci@0000:00:14.1
           version: 40
           width: 32 bits
           clock: 66MHz
           capabilities: ide isa_compat_mode pci_native_mode bus_master
           configuration: driver=pata_atiixp latency=64
           resources: irq:17 ioport:1f0(size=8) ioport:3f6 ioport:170(size=8) ioport:376 ioport:ff00(size=16)
  5. 自動読み込み
    4の手順を再起動しても不要にするため設定ファイルを作成する。
    「/etc/modules-load.d/」以下に任意のファイル名.confで「pata_atiixp」の一行を記載したものを配置する。

    echo pata_atiixp > /etc/modules-load.d/ide.conf
  6. 【任意】起動イメージへ適用(起動ディスクに使用する場合などに必要と思われる)
    現在読み込んでるカーネルのバージョンを調べ、dracutコマンドを使用して起動イメージ(initramfs)を再作成する。
    この手順は、カーネルアップデートする際に適用される。

    # uname -r
    4.18.0-372.26.1.el8_6.x86_64
    
    # mv /boot/initramfs-4.18.0-372.26.1.el8_6.x86_64.img /boot/initramfs-4.18.0-372.26.1.el8_6.x86_64.img.bak
    
    # dracut /boot/initramfs-4.18.0-372.26.1.el8_6.x86_64.img 4.18.0-372.26.1.el8_6.x86_64

     

[Linux]ddを使用せずLVMのHDD交換方法

1.環境

OS : CentOS Stream release 8 [4.18.0-348.el8.x86_64]
※KVM上で動作

2.やること

LVM構成のLinuxで新しいHDDに交換する。
同じ容量、移行に多くのの時間をかけることができれば、ddコマンドを利用するのが単純で楽だが、少し手間が増えるがLVMの機能を利用すると停止時間を短く移行できる可能性がある。

LVMを使用していないシステムとは違い、リカバリディスクは不要

前提として、移行対象のマシンは停止できることとGrub2を利用していること

3.手順

  1. 移行対象のマシンをシャットダウンし、移行先のHDDを接続する
  2. 通常通り起動する
  3. 移行先のHDDのパーティションを切る
  4. 移行先の/boot用パーティションをフォーマットする
  5. 移行先の/bootをマウントする
  6. 移行元から移行先へ/boot以下をコピーする
  7. /etc/fstabがUUIDで記載されている場合移行先のHDDのものに修正する
  8. 移行先HDDをLVMに追加し移行操作を行う
  9. 再起動する
  10. grubのconfigファイルを生成する
  11. 移行先HDDにgrubをインストールする
  12. シャットダウンし、移行元ディスクを取り除いたら起動確認を行う

以上

4.手順詳細

1.移行対象のマシンをシャットダウンし、移行先のHDDを接続する

2.通常通り起動する

3.移行先のHDDのパーティションを切る

fdisk, parted, gdiskなどを利用して移行先HDDのパーティションを作成する。とくに構成を変える必要がなければ移行元と揃えるのが楽

・移行元のパーティション情報

# fdisk -l /dev/vda

・移行先のパーティション作成

[root@develop ~]# fdisk /dev/vdb

fdisk (util-linux 2.32.1) へようこそ。
ここで設定した内容は、書き込みコマンドを実行するまでメモリのみに保持されます。
書き込みコマンドを使用する際は、注意して実行してください。

デバイスには認識可能なパーティション情報が含まれていません。
新しい DOS ディスクラベルを作成しました。識別子は 0x1ef41471 です。

コマンド (m でヘルプ): n
パーティションタイプ
   p   基本パーティション (0 プライマリ, 0 拡張, 4 空き)
   e   拡張領域 (論理パーティションが入ります)
選択 (既定値 p): p
パーティション番号 (1-4, 既定値 1): 
最初のセクタ (2048-268435455, 既定値 2048): 
最終セクタ, +セクタ番号 または +サイズ{K,M,G,T,P} (2048-268435455, 既定値 268435455): 2099199

新しいパーティション 1 をタイプ Linux、サイズ 1 GiB で作成しました。

コマンド (m でヘルプ): n
パーティションタイプ
   p   基本パーティション (1 プライマリ, 0 拡張, 3 空き)
   e   拡張領域 (論理パーティションが入ります)
選択 (既定値 p): p
パーティション番号 (2-4, 既定値 2): 
最初のセクタ (2099200-268435455, 既定値 2099200): 
最終セクタ, +セクタ番号 または +サイズ{K,M,G,T,P} (2099200-268435455, 既定値 268435455): 

新しいパーティション 2 をタイプ Linux、サイズ 127 GiB で作成しました。

コマンド (m でヘルプ): a
パーティション番号 (1,2, 既定値 2): 1

パーティション 1 の起動フラグを有効にしました。

コマンド (m でヘルプ): t
パーティション番号 (1,2, 既定値 2): 
16 進数コード (L で利用可能なコードを一覧表示します): 8e

パーティションのタイプを 'Linux' から 'Linux LVM' に変更しました。

コマンド (m でヘルプ): w
パーティション情報が変更されました。
ioctl() を呼び出してパーティション情報を再読み込みします。
ディスクを同期しています。

[root@develop ~]# fdisk -l /dev/vdb
ディスク /dev/vdb: 128 GiB, 137438953472 バイト, 268435456 セクタ
単位: セクタ (1 * 512 = 512 バイト)
セクタサイズ (論理 / 物理): 512 バイト / 512 バイト
I/O サイズ (最小 / 推奨): 512 バイト / 512 バイト
ディスクラベルのタイプ: dos
ディスク識別子: 0x1ef41471

デバイス   起動 開始位置  終了位置    セクタ サイズ Id タイプ
/dev/vdb1  *        2048   2099199   2097152     1G 83 Linux
/dev/vdb2        2099200 268435455 266336256   127G 8e Linux LVM

4.移行先の/boot用パーティションをフォーマットする

# mkfs.xfs /dev/vdb1

5.移行先の/bootをマウントする

# mount /dev/vdb1 /mnt

6.移行元から移行先へ/boot以下をコピーする

cp、rsyncなどを利用してコピー、cp の場合は -p 、rsync の場合は -a オプションなどを利用して所有者、パーミッションなどが変わらないようにする。

# cp -p /boot/ /mnt/

or

# rsync -avu --delete --progress /boot/ /mnt/

7./etc/fstabがUUIDで記載されている場合移行先のHDDのものに修正する

# blkid /dev/vdb1

8.移行先HDDをLVMに追加し移行操作を行う

# vgs
VG #PV #LV #SN Attr VSize VFree
cs 1 3 0 wz--n- <127.00g 0

# pvcreate /dev/vdb2 # vgextend VGNAME /dev/vdb2

# pvs
PV VG Fmt Attr PSize PFree
/dev/vda2 cs lvm2 a-- <127.00g 0
/dev/vdb2 cs lvm2 a-- <127.00g <127.00g
# pvmove /dev/vda2 /dev/vdb2
/dev/vda2: Moved: 0.07%
/dev/vda2: Moved: 0.36%
/dev/vda2: Moved: 0.63%
/dev/vda2: Moved: 0.88%
:
:
/dev/vda2: Moved: 99.81%
/dev/vda2: Moved: 100.00%

# pvs
PV VG Fmt Attr PSize PFree
/dev/vda2 cs lvm2 a-- <127.00g <127.00g
/dev/vdb2 cs lvm2 a-- <127.00g 0
# vgreduce VGNAME /dev/vda2
# pvremove /dev/vda2

9.再起動する

# reboot

10.grubのconfigファイルを生成する

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

11.移行先HDDにgrubをインストールする

# grub2-install /dev/vdb

12.シャットダウンし、移行元ディスクを取り除いたら起動確認を行う

無事起動確認完了

以上

[Linux]ddを使用せずLVMでないHDD交換方法

1.環境

OS : CentOS Linux release 7.9.2009 (Core) [3.10.0-1160.45.1.el7.x86_64]
※KVM上で動作

2.やること

LVM構成していないHDDを新しいHDDに交換する。
同じ容量、移行に多くのの時間をかけることができれば、ddコマンドを利用するのが単純で楽だが、パーティションの構成変更や、ファイルシステム変更、容量の少ないHDDに移行は難しい。これらを実現するためにddコマンドを利用しないHDD移行手順について説明する。

前提として、移行対象のマシンは停止できることとGrub2を利用していること

3.手順

  1. 移行対象のマシンをシャットダウンし、移行先のHDDを接続する
  2. インストーラディスクを利用してメンテナンスモードやライブモードで起動する
    ※インストーラーディスクはLinuxが起動できればなんでもいいが、できれば同じディストリビューション、バージョンがあると望ましい
  3. 移行先のHDDのパーティションを切る
  4. 移行先のパーティションをフォーマットする
  5. 移行元、移行先をそれぞれマウントする
    ※移行元は読込専用でマウントするのが望ましい
  6. 移行元から移行先へコピーする
  7. 5,6をパーティションの数だけ繰り返す
  8. /etc/fstabがUUIDで記載されている場合移行先のHDDのものを修正する
  9. シャットダウンし、移行元HDDを取り外す
  10. 2と同様、インストーラディスクを利用してメンテナンスモードやライブモードで起動する
  11. 移行先HDDを/mnt以下にfstab通り+αをマウントする
    ※Swapは不要
  12. chrootし、grubのconfigファイルを生成する
  13. 移行先HDDにgrubをインストールする
  14. シャットダウンし、インストーラーディスクを取り除いたら起動確認を行う

以上

4.手順詳細

1.移行対象のマシンをシャットダウンし、移行先のHDDを接続する

2.インストーラディスクを利用してメンテナンスモードやライブモードで起動する

インストーラーディスクはLinuxが起動できればなんでもいいが、できれば同じディストリビューション、バージョンがあると望ましい。
例ではCentOS7のインストーラディスクを利用して説明する。

・Troubleshootingを選択する

・Rescue a CentOS systemを選択

・マウントは手動で行うので 3 を選択肢 shell に移動する

・キーマップが英字になっているので、日本語に変更すると作業しやすい。

# localectl set-keymap jp106

3.移行先のHDDのパーティションを切る

fdisk, parted, gdiskなどを利用して移行先HDDのパーティションを作成する。とくに構成を変える必要がなければ移行元と揃えるのが楽

・移行元のパーティション情報

# fdisk -l /dev/vda

・移行先のパーティション作成

4.移行先のパーティションをフォーマットする

例では、/dev/vdb3のみ swap 、レガシーBootの場合はその他のパーティションは任意のファイルシステムで問題ない。しかし、UEFIの場合はbootパーティションはfatにする必要がある。

# mkfs.ext4 /dev/vdb1
# mkfs.ext4 /dev/vdb2
# mkswap /dev/vdb3

5.移行元、移行先をそれぞれマウントする

※移行元は読込専用でマウントするのが望ましい

# mkdir /mnt/vda
# mkdir /mnt/vdb
# mount -r /dev/vda1 /mnt/vda
# mount /dev/vdb1 /mnt/vdb

6.移行元から移行先へコピーする

cp、rsyncなどを利用してコピー、cp の場合は -p 、rsync の場合は -a オプションなどを利用して所有者、パーミッションなどが変わらないようにする。

# cp -p /mnt/vda/ /mnt/vdb/

or

# rsync -avu --delete --progress /mnt/vda/ /mnt/vdb/

7.5,6をパーティションの数だけ繰り返す

※Swapは除く

8./etc/fstabがUUIDで記載されている場合移行先のHDDのものを修正する

blkidコマンドで調べたUUIDでfstabのUUIDの箇所を修正する。

# blkid /dev/vdb1
# blkid /dev/vdb2
# blkid /dev/vdb3

例:fstabにblkidコマンドの結果を貼り付けた結果

・以下のように書き換える

9.シャットダウンし、移行元HDDを取り外す

 

10.2と同様、インストーラディスクを利用してメンテナンスモードやライブモードで起動する

手順2を参照

11.移行先HDDを/mnt以下にfstab通り+αをマウントする

※Swapは不要

・ここの例では以下のようにマウントする

# mount /dev/vda2 /mnt
# mount /dev/vda1 /mnt/boot

・proc, dev, sysをマウント、バインドする

# mount -t proc proc /mnt/proc
# mount -B /dev /mnt/dev
# mount -B /sys /mnt/sys
# mount -B /run /mnt/run

12.chrootし、grubのconfigファイルを生成する

・レガシーBootの場合、EFIの場合はgrubのconfigファイルの場所が違うので注意

# chroot
# grub2-mkconfig -o /boot/grub2/grub.cfg

13.移行先HDDにgrubをインストールする

※レガシーBootの場合

# grub2-install /dev/vda

エラーなし「Installation finished. No error reported.」と表示されれば問題なし

14.シャットダウンし、インストーラーディスクを取り除いたら起動確認を行う

無事起動確認完了

 

以上

ownCloudのカレンダーアプリでタイムゾーンが認識されない

1. 事象

ownCloudのカレンダーでタイムゾーンがうまく認識されず表示がおかしくなる。
「タイムゾーン[Etc/GMT-9]が不明なため、代わりにUTCを使用します。」

正しく表示された場合は以下のようになる。

2. 環境

ownCloud : 10.8.0
– calender : 1.6.4

クライアント(再現を確認したもの)

Google Chrone : 92.0.4515.131(Windows)
Firefox : 91.0(Windows)

※LinuxのGoogle Chromeでは発生しない

3. 解決策

すでに参考に挙げたリンク先で議論されており、パッチも存在していた。ブラウザ側のバグだとも考えられるが、一向に修正される気配がないのでパッチを適用することにした。

【参考】

https://github.com/clear-code/statistics/issues/189

https://github.com/nextcloud/calendar/issues/496#issuecomment-326791894

3-1. 修正方針

パッチを適用してビルドしたファイルのうち問題箇所の「TimezoneService」が定義されている以下の3ファイルを置き換える。

OC/apps/calendar/js/public
・app.js
・app.min.js
・app.min.js.map

3-2. 修正手順

3-2-1. カレンダーアプリのコードを取得

git clone https://github.com/owncloud/calendar.git

3-2-2. パッチを適用する

クローンしたカレンダーのディレクトリに移動して以下の差分を参考に修正する。

$ git diff
diff --git a/js/app/service/timezoneService.js b/js/app/service/timezoneService.js
index 3c90ed0e..d5d7f371 100644
--- a/js/app/service/timezoneService.js
+++ b/js/app/service/timezoneService.js
@@ -43,7 +43,10 @@ app.service('TimezoneService', function (TimezoneDataProvider, Timezone) {
         * @returns {string}
         */
        this.current = function () {
+               const dateTimeFormat = Intl.DateTimeFormat;
+               Intl.DateTimeFormat = function() {return {resolvedOptions: function() {return {};}};};
                const tz = jstz.determine();
+               Intl.DateTimeFormat = dateTimeFormat;
                let tzname = tz ? tz.name() : 'UTC';
 
                if (TimezoneDataProvider.aliases[tzname]) {

以下を参考にしています。

https://github.com/Hakuyume/nextcloud-calendar/commit/ea1c314e6c4e925d440a64d2ca0d52d9a18812e2

3-2-3. ビルド

makeではうまくいかなく、原因探すのがめんどくさかったので手動でコマンドを実行した。

$ npm install yarn
$ npm run build

3-2-4. 配置

ビルドが成功すると以下のファイルが出来ているのでこれを取得しサーバのファイルを置換する。

./js/public
・app.js
・app.min.js
・app.min.js.map

4. 修正結果確認

正しく表示されるようになった。

以上

terminalからのパスワード入力にパスワードの入力画面を使用しないようにする

いつからか、terminalで実行する一部のアプリケーションでパスワードの入力時にGUIのパスワード入力画面が表示されるようになった。例えばGitのプライベートリポジトリからcloneするときなどは右図の画面が表示される。この方式はあまり好きではないので、昔ながらのterminal内でパスワードの入力を行えるようにする。

 

1. 環境

  • CentOS8
  • KDE
  • Konsole

2. 設定方法

パスワードの入力を求めるときに、環境変数(SSH_ASKPASS)に設定されているアプリケーションを呼び出しているみたいなので、この環境変数を削除する。

2-1. 環境変数(SSH_ASKPASS)の内容

$ echo $SSH_ASKPASS
/usr/bin/ksshaskpass

2-2. 環境変数(SSH_ASKPASS)の削除

~/.bashrc などに次の内容を追加する

unset SSH_ASKPASS

3. 参考サイト

同じことを思っている人がいましたので、こちらを参考にしました。

Git Windows Disable password prompt UI but get password prompt from shell

以上

HDDのS.M.A.R.Tエラーを解消する

この題材は非常に多くの人が実施し、記事にもなっていますが手元にCurrent_Pending_Sector(代替処理保留中のセクタ数)が発生したHDDがあったので不良セクタの代替え処理を試し、S.M.A.R.Tのエラーを解消してみようと思います。

注意

今回ここで使用するコマンドはやっていることの内容を理解せずに実行するとデータを消失する可能性があります。やっていることの内容を理解し、自己責任で操作するようにして下さい。

ここで使用するHDDは何もデータが入っていないものを使用しています。データが入っているHDDの場合は更に多くの手順を実施する必要があります。

1. 環境

・ハードディスク
種類:Western Digital Red[2TB]
接続:SATA(マザーボードに直結)

・OS
種類:Linux(CentOS8)

2. HDDの状況

smartctlの結果はこんな状態です。4年くらい前にサーバーで使用していたもので短命なHDDだったなと思っていたのですが、最近WD Redを購入してサーバーに組み込んだら1週間も経たないうち(160時間)にCurrent_Pending_Sectorが発生しました。WD Redは自分とは相性が悪いのかもしれません・・・

# smartctl -a /dev/sde
smartctl 6.6 2017-11-05 r4594 [x86_64-linux-4.18.0-147.8.1.el8_1.x86_64] (local build)
Copyright (C) 2002-17, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Family:     Western Digital Red
Device Model:     WDC WD20EFRX-68EUZN0
Serial Number:    WD-WCC4M6CL2PLE
LU WWN Device Id: 5 0014ee 2638bc189
Firmware Version: 82.00A82
User Capacity:    2,000,398,934,016 bytes [2.00 TB]
Sector Sizes:     512 bytes logical, 4096 bytes physical
Rotation Rate:    5400 rpm
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   ACS-2 (minor revision not indicated)
SATA Version is:  SATA 3.0, 6.0 Gb/s (current: 1.5 Gb/s)
Local Time is:    Wed May 13 07:15:54 2020 JST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

General SMART Values:
Offline data collection status:  (0x00) Offline data collection activity
                                        was never started.
                                        Auto Offline Data Collection: Disabled.
Self-test execution status:      ( 121) The previous self-test completed having
                                        the read element of the test failed.
Total time to complete Offline 
data collection:                (25980) seconds.
Offline data collection
capabilities:                    (0x7b) SMART execute Offline immediate.
                                        Auto Offline data collection on/off support.
                                        Suspend Offline collection upon new
                                        command.
                                        Offline surface scan supported.
                                        Self-test supported.
                                        Conveyance Self-test supported.
                                        Selective Self-test supported.
SMART capabilities:            (0x0003) Saves SMART data before entering
                                        power-saving mode.
                                        Supports SMART auto save timer.
Error logging capability:        (0x01) Error logging supported.
                                        General Purpose Logging supported.
Short self-test routine 
recommended polling time:        (   2) minutes.
Extended self-test routine
recommended polling time:        ( 263) minutes.
Conveyance self-test routine
recommended polling time:        (   5) minutes.
SCT capabilities:              (0x703d) SCT Status supported.
                                        SCT Error Recovery Control supported.
                                        SCT Feature Control supported.
                                        SCT Data Table supported.

SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x002f   200   200   051    Pre-fail  Always       -       3640
  3 Spin_Up_Time            0x0027   207   173   021    Pre-fail  Always       -       2641
  4 Start_Stop_Count        0x0032   100   100   000    Old_age   Always       -       33
  5 Reallocated_Sector_Ct   0x0033   182   182   140    Pre-fail  Always       -       545
  7 Seek_Error_Rate         0x002e   100   253   000    Old_age   Always       -       0
  9 Power_On_Hours          0x0032   091   091   000    Old_age   Always       -       7196
 10 Spin_Retry_Count        0x0032   100   253   000    Old_age   Always       -       0
 11 Calibration_Retry_Count 0x0032   100   253   000    Old_age   Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       31
192 Power-Off_Retract_Count 0x0032   200   200   000    Old_age   Always       -       19
193 Load_Cycle_Count        0x0032   200   200   000    Old_age   Always       -       265
194 Temperature_Celsius     0x0022   120   108   000    Old_age   Always       -       27
196 Reallocated_Event_Count 0x0032   149   149   000    Old_age   Always       -       51
197 Current_Pending_Sector  0x0032   200   200   000    Old_age   Always       -       3
198 Offline_Uncorrectable   0x0030   100   253   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x0032   200   200   000    Old_age   Always       -       0
200 Multi_Zone_Error_Rate   0x0008   200   200   000    Old_age   Offline      -       108

SMART Error Log Version: 1
No Errors Logged

SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Extended offline    Completed: read failure       90%      7196         23027200
# 2  Extended offline    Completed: read failure       90%      7196         14746760
# 3  Short offline       Completed without error       00%      7195         -
# 4  Extended offline    Completed: read failure       90%      7186         14746760
# 5  Extended offline    Completed: read failure       90%      7186         14766264
# 6  Short offline       Completed without error       00%      7182         -
# 7  Short offline       Completed: read failure       90%      7182         16281440
# 8  Short offline       Completed: read failure       90%      7182         14750152
# 9  Extended offline    Completed: read failure       90%      7136         14740632
#10  Extended offline    Completed: read failure       90%      7136         16207904
#11  Extended offline    Completed: read failure       90%      7136         16207904
#12  Extended offline    Completed: read failure       90%      7136         14750152
#13  Short offline       Completed without error       00%      7136         -
#14  Short offline       Completed: read failure       90%      7135         14740537
#15  Short offline       Completed: read failure       90%      7135         14740536
#16  Conveyance offline  Completed: read failure       90%      7135         14740537
#17  Extended offline    Completed: read failure       90%      7135         14741008
#18  Short offline       Completed: read failure       90%      7120         14741008
#19  Short offline       Completed: read failure       90%      7120         14741008
#20  Extended offline    Completed: read failure       90%      7118         14741008
#21  Extended offline    Completed: read failure       90%      7118         14741008

SMART Selective self-test log data structure revision number 1
 SPAN  MIN_LBA  MAX_LBA  CURRENT_TEST_STATUS
    1        0        0  Not_testing
    2        0        0  Not_testing
    3        0        0  Not_testing
    4        0        0  Not_testing
    5        0        0  Not_testing
Selective self-test flags (0x0):
  After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.

ベンダー固有の属性情報を見てみるとCurrent_Pending_Sector(代替処理保留中のセクタ数)が3件存在しており、すでにReallocated_Sector_Ct(代替処理済のセクタ数)は545件存在しています。

3. 不良セクタの代替処理とは

HDDは右の写真のようにプラッタと呼ばれる銀色の円盤に磁気情報を記録することにより情報を保存しています。この銀色の円盤には磁性体と呼ばれるものが塗られており、これが磁気を帯びることで情報を保存するのですが、経年劣化や傷などにより磁性体が磁気を帯びにくくなったり剥がれたりすると、その場所への情報の読み書きができなくなります。この場所のことを不良セクタと呼びます。

不良セクタへは読み込みも書き込みも行えなくなるわけですが、HDDには予めある程度予備の領域が用意されており、ファームウェアが不良セクタへの書き込みを検知すると以後不良セクタではなく予備の領域へアクセスするようにします。これが不良セクタの代替処理です。

そしてセクタサイズで区切った場合に代替処理を行っていない不良セクタが何箇所あるかを表しているのがCurrent_Pending_Sectorの値であり、この不良セクタへの書き込みが行われ代替処理が行われたセクタの数がReallocated_Sector_Ctの値となります。

 

4. 不良セクタの代替処理を実際に試して見る

3に記載したとおり、不良セクタに対して書き込み処理を行うことで不良セクタが代替されます。不良セクタの位置を知らないと書き込みが行えないので、まず最初に不良セクタの位置を確認します。

4-1. 不良セクタの位置を知る

不良セクタの位置を知るにはS.M.A.R.Tのセルフテストの機能を使用します。不良セクタがある場合は2で示したsmart情報の83行目LBA_of_first_error列にセクタ番号が表示されます。

手順

  1. S.M.A.R.Tのshortテストを行う。
  2. テスト結果LBA_of_first_errorを確認する。
  3. 2で結果が得られなかった場合はS.M.A.R.Tのlongテストを行う。
  4. テスト結果LBA_of_first_errorを確認する。

longテストの場合、長い時間待つように(例では263分)言われますが、不良セクタを見つけるとその時点でテスト終了となるため場合にもよりますが、比較的短時間で結果が得られます。

以下、上記手順の例です。

# smartctl -t short /dev/sde   
smartctl 6.6 2017-11-05 r4594 [x86_64-linux-4.18.0-147.8.1.el8_1.x86_64] (local build)
Copyright (C) 2002-17, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF OFFLINE IMMEDIATE AND SELF-TEST SECTION ===
Sending command: "Execute SMART Short self-test routine immediately in off-line mode".
Drive command "Execute SMART Short self-test routine immediately in off-line mode" successful.
Testing has begun.
Please wait 2 minutes for test to complete.
Test will complete after Wed May 13 07:20:31 2020

Use smartctl -X to abort test.

# smartctl -l selftest /dev/sde
smartctl 6.6 2017-11-05 r4594 [x86_64-linux-4.18.0-147.8.1.el8_1.x86_64] (local build)
Copyright (C) 2002-17, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF READ SMART DATA SECTION ===
SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Short offline       Completed without error       00%      7196         -
# 2  Extended offline    Completed: read failure       90%      7196         23027200
# 3  Extended offline    Completed: read failure       90%      7196         14746760
・・・

# smartctl -t long /dev/sde
smartctl 6.6 2017-11-05 r4594 [x86_64-linux-4.18.0-147.8.1.el8_1.x86_64] (local build)
Copyright (C) 2002-17, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF OFFLINE IMMEDIATE AND SELF-TEST SECTION ===
Sending command: "Execute SMART Extended self-test routine immediately in off-line mode".
Drive command "Execute SMART Extended self-test routine immediately in off-line mode" successful.
Testing has begun.
Please wait 263 minutes for test to complete.
Test will complete after Wed May 13 11:44:12 2020

Use smartctl -X to abort test.

# smartctl -l selftest /dev/sde
smartctl 6.6 2017-11-05 r4594 [x86_64-linux-4.18.0-147.8.1.el8_1.x86_64] (local build)
Copyright (C) 2002-17, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF READ SMART DATA SECTION ===
SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Extended offline    Completed: read failure       90%      7196         23033488
# 2  Short offline       Completed without error       00%      7196         -
# 3  Extended offline    Completed: read failure       90%      7196         23027200
・・・

以上から不良セクタのひとつは23033488  だと分かります。

4-2. 不良セクタへ書き込みを行う

ここではddコマンドを使用する方法と、hdparmコマンドを使用する方法を紹介します。

4-2-1. 最初に読み込みを行ってみる

ddコマンドを使用して不良セクタから値を読み取って見るとこのようにエラーとなります。bsには2のsmartctlの結果12行目に書かれているセクタサイズを指定します。

# dd if=/dev/sde of=/dev/null bs=512 count=1 skip=23033488
dd: '/dev/sde' の読み込みエラー: 入力/出力エラーです
0+0 レコード入力
0+0 レコード出力
0 bytes copied, 7.02786 s, 0.0 kB/s

4-2-2. hdparmコマンドで書き込みしてみる

# hdparm --write-sector 23033488 --yes-i-know-what-i-am-doing /dev/sde

/dev/sde:
re-writing sector 23033488: succeeded

# dd if=/dev/sde of=/dev/null bs=512 count=1 skip=23033488
1+0 レコード入力
1+0 レコード出力
512 bytes copied, 3.08049 s, 0.2 kB/s

書き込み後はこのように読み取りができるようになります。

4-2-3. ddコマンドで書き込みしてみる

# dd if=/dev/zero of=/dev/sde bs=512 count=1 seek=23027200
dd: '/dev/sde' の書き込みエラー: 入力/出力エラーです
1+0 レコード入力
0+0 レコード出力
0 bytes copied, 3.51744 s, 0.0 kB/s

# dd if=/dev/zero of=/dev/sde bs=512 count=1 seek=23027200
1+0 レコード入力
1+0 レコード出力
512 bytes copied, 0.000406069 s, 1.3 MB/s

# dd if=/dev/sde of=/dev/null bs=512 count=1 skip=23027200
1+0 レコード入力
1+0 レコード出力
512 bytes copied, 2.34536 s, 0.2 kB/s

ddコマンドで書き込む際は(私の環境では?)2回実施が必要でした。

4-3. ベンダー固有の属性情報を確認する

# smartctl -A /dev/sde
smartctl 6.6 2017-11-05 r4594 [x86_64-linux-4.18.0-147.8.1.el8_1.x86_64] (local build)
Copyright (C) 2002-17, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF READ SMART DATA SECTION ===
SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x002f   200   200   051    Pre-fail  Always       -       3672
  3 Spin_Up_Time            0x0027   207   173   021    Pre-fail  Always       -       2641
  4 Start_Stop_Count        0x0032   100   100   000    Old_age   Always       -       33
  5 Reallocated_Sector_Ct   0x0033   182   182   140    Pre-fail  Always       -       547
  7 Seek_Error_Rate         0x002e   100   253   000    Old_age   Always       -       0
  9 Power_On_Hours          0x0032   091   091   000    Old_age   Always       -       7197
 10 Spin_Retry_Count        0x0032   100   253   000    Old_age   Always       -       0
 11 Calibration_Retry_Count 0x0032   100   253   000    Old_age   Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       31
192 Power-Off_Retract_Count 0x0032   200   200   000    Old_age   Always       -       19
193 Load_Cycle_Count        0x0032   200   200   000    Old_age   Always       -       266
194 Temperature_Celsius     0x0022   119   108   000    Old_age   Always       -       28
196 Reallocated_Event_Count 0x0032   148   148   000    Old_age   Always       -       52
197 Current_Pending_Sector  0x0032   200   200   000    Old_age   Always       -       1
198 Offline_Uncorrectable   0x0030   100   253   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x0032   200   200   000    Old_age   Always       -       0
200 Multi_Zone_Error_Rate   0x0008   200   200   000    Old_age   Offline      -       107

今回2つの不良セクタについて対応したので、Current_Pending_Sectorが3→1件に、Reallocated_Sector_Ctが545→547件と変化しました。

4-4. すべてのエラーを解消するには

4-1と4-2の手順を繰り返し実施します。

5. まとめ

不良セクタの代替処理について確認することができました、機会があればデータが入っているHDDに対してもやってみたいですね。

[CentOS8]Fcitxを導入してmozcを使用する

CentOS8にFcitxを導入し、fcitx-mozcを使用できるようにします。

1. epelリポジトリを導入する

# dnf install epel-release
※必要に応じて標準でepelリポジトリを利用しないなどの設定を行う

2. mozcを削除する(ibusのmozcを導入している場合)

# dnf remove mozc ibus-mozc

3. fcitxをインストール

# dnf --enablerepo=epel install fcitx

3-1. 設定ツールのインストール

3-1-1. GNOMEなど、GTK系のデクストップ環境

# dnf --enablerepo=epel install fcitx-configtool

3-1-2. KDEなど、Qt系のデスクトップ環境

# dnf --enablerepo=epel install kcm-fcitx

3-2. fcitx-mozcをインストール

fcitx-mozcはCentOS用のリポジトリに存在しないため(知らないだけかもしれないが)、openSUSE用のrpmパッケージをダウンロードして使用します。

RPM Search などから次のrpmパッケージをダウンロードします。

・fcitx-mozc-2.18.2612.102-lp151.5.1.x86_64.rpm
・mozc-2.18.2612.102-lp151.5.1.x86_64.rpm
・mozc-gui-tools-2.18.2612.102-lp151.5.1.x86_64.rpm

ダウンロードしたファイルがあるディレクトリで次のコマンドを実行
# dnf --enablerepo=epel localinstall fcitx-mozc-2.18.2612.102-lp151.5.1.x86_64.rpm mozc-2.18.2612.102-lp151.5.1.x86_64.rpm mozc-gui-tools-2.18.2612.102-lp151.5.1.x86_64.rpm

4. ibusからfcitxへの切り替え

GNOMEを使用している場合はまず次のコマンドを実行する。
$ gsettings set org.gnome.settings-deamon.plugins.keyboad active false
そして、このコマンドを実行することで切り替わります。
$ imsetting-swich fcitx
KDEを使用しており、profileや.bashrcなどに以下のように設定している場合は削除するかibusをfcitxに書き換える。

export GTK_IM_MODULE=ibus
export XMODIFIERS=@im=ibus
export QT_IM_MODULE=ibus

5. 参考

http://note.kurodigi.com/centos7-fcitx/

 

CentOS 7のときと比べるとだいぶ楽に切り替えられるようになりました。

以上

[CentOS8]DockerからNvidia GPUを使用する

1. 環境

CentOS8
Nvidia Driver 430.14
Docker 19.03.8

2. Dockerインストール

こちらのページを参考にインストールを行った。

https://qiita.com/cyberblack28/items/0b0ec02bce67a16e2f17

以前は nvidia-docker コマンドとかがあったみたいだが、最近は docker コマンドからGPUが使えるようになったみたい

https://qiita.com/ksasaki/items/b20a785e1a0f610efa08

特に過去のしがらみ等はないので、「Docker 19.03 + nvidia-container-toolkit」のインストールを行った。

3. nvidia-container-toolkitのインストール

以下のQuickStartにはCentOS8の記載はないが、CentOS7と同じ方法でインストール可能

https://github.com/NVIDIA/nvidia-docker/tree/master#centos-7-docker-ce-rhel-7475-docker-ce-amazon-linux-12

4. 動作確認

$ docker run --gpus 1 --rm nvidia/cuda nvidia-smi
Sun May  3 03:53:16 2020       
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 430.14       Driver Version: 430.14       CUDA Version: 10.2     |
|-------------------------------+----------------------+----------------------+
| GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
|===============================+======================+======================|
|   0  GeForce GTX 105...  Off  | 00000000:07:00.0 Off |                  N/A |
| 29%   38C    P8    N/A /  75W |      0MiB /  4040MiB |      0%      Default |
+-------------------------------+----------------------+----------------------+
                                                                               
+-----------------------------------------------------------------------------+
| Processes:                                                       GPU Memory |
|  GPU       PID   Type   Process name                             Usage      |
|=============================================================================|
|  No running processes found                                                 |
+-----------------------------------------------------------------------------+

これでDockerからGPUを利用できそう

以上

[CentOS8]KVMゲストマシンへGPU passthroughを行う

こちらのページを参考にGPUパススルーの設定を行ったが、エラーが発生したため備忘録として残しておく。

https://www.server-world.info/query?os=CentOS_8&p=kvm&f=12

1. 環境

ホスト:CentOS8

  • libvirt:4.5.0

ゲスト:CentOS8 ※すでに構築済みのものを使用

2. 発生した問題(1)

以下の画像のエラーが発生し、仮想マシンの起動に失敗した。

2-1. 解決方法

いろいろ調べていたところ vfio_iommu_type1  というモジュールが読み込まれていないことが分かり、これを読み込ませることで起動できるようになる。

・一時的には
# modprobe vfio_iommu_type1
・永続的には(ホストの再起動が必要)
# echo 'vfio_iommu_type1' > /etc/modules-load.d/vfio_iommu_type1.conf

3. 次に発生した問題(2)

問題(1)を解決後、Nvidia driverのインストールを行い、nvidia-smiを実行したところ以下のエラーが発生した。
$ nvidia-smi
Unable to determine the device handle for GPU 0000:07:00.0: Unknown Error

dmesgを実行するとこのようなログが複数残っていた。

$ dmesg
・・・
[   26.907855] NVRM: GPU 0000:07:00.0: RmInitAdapter failed! (0x23:0x56:498)
[   26.908054] NVRM: GPU 0000:07:00.0: rm_init_adapter failed, device minor number 0
・・・

3-1. 解決方法

Nvidia driverはハイパーバイザの動作を確認し動作を停止させるらしい。これを回避するためには、VM設定XMLのfeaturesタグ内に以下のhypervとkvmタグを追加する。

# virsh edit [vmname]
・・・
  <features>
  ・・・
    <hyperv>
      <vendor_id state='on' value='whatever'/>
    </hyperv>
    <kvm>
      <hidden state='on'/>
    </kvm>
  ・・・
  </features>
・・・

3-1-1. 参考サイト

Windows の仮想マシンに NVIDIA の GPU をパススルーした場合に “Error 43 : Driver failed to load”

Ubuntu19.10 KVMでGPUのパススルーができない問題の解決策
※私の環境ではこの設定は不要だった