ファイルシステムを縮小したかったのですが、残念ながら1つのステップを逃しました。
以前にファイルシステムのサイズを変更せずに、論理ボリュームを減らしました。
その結果、システムが起動しなくなり、ファイルシステムが破損しているというメッセージが表示されました。
[root@node2 ~]# mount -a
mount: wrong fs type, bad option, bad superblock on /dev/mapper/vgprod-prod,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so.
[root@node2 ~]# e2fsck -f /dev/mapper/vgprod-prod
e2fsck 1.42.9 (28-Dec-2013)
Error reading block 65536 (Invalid argument). Ignore error<y>? yes
Force rewrite<y>? yes
Superblock has an invalid journal (inode 8).
Clear<y>? yes
*** ext3 journal has been deleted - filesystem is now ext2 only ***
Superblock has_journal flag is clear, but a journal inode is present.
Clear<y>? yes
The filesystem size (according to the superblock) is 115712 blocks
The physical size of the device is 64512 blocks
Either the superblock or the partition table is likely to be corrupt!
Abort<y>? yes
Error writing block 65536 (Invalid argument). Ignore error<y>? yes
/dev/mapper/vgprod-prod: ***** FILE SYSTEM WAS MODIFIED *****
問題を解決する方法を教えてください。
多くの損傷を引き起こす可能性のある変更を行う前に、現在の状態で物理ボリュームのセクターごとのコピーを作成し(_dd if=/dev/sdXY of=/path/to/safe/place.img
_のように)、変更せずにどこかに保存します。 pvdisplay
を使用して、コピーするパーティションを確認します。最悪の事態が発生した場合(ファイルシステムが損傷して内容を理解できない場合)でも、 testdisk を使用できます(ファイルシステムが1つの連続したブロックのLVMパーティションに存在する場合):
testdisk /path/to/image.img
_testdisk
はLVMの書き込み方法を知りませんが、検出したパーティションから情報を読み取ります。失敗したLVMパーティションがrootfsをホストしていないと仮定して、_/etc/lvm
_ディレクトリもバックアップします。パーティションがrootfsをホストしていた場合、おそらく以前のバックアップにこのディレクトリが含まれていますか?必要になります。他のすべてが失敗した場合でも、16進エディターと_/etc/lvm/
_の文字列検索を使用して、_description =
_からファイルの内容を見つけることができる可能性がありますが、それは非常に長いプロセスです。 。
まだinitramfsシェルにいて、イメージ用の十分な空きHDDスペースがない場合は、運が良ければ(usb-storageおよびinitramfsに存在する他のモジュール)、USB-HDDをマウントできる可能性があります。
dmesg | tail
_[ 8391.759613] sd 6:0:0:0: [sdX] 15826944 512-byte logical blocks: (8.10 GB/7.55 GiB)
(サイズを比較してsdX
がUSB-HDDであることを確認してください)および_[ 8391.770279] sdX: sdX1
_(sdX1 ... sdXnがのリストであることを確認してください)のように見える行を探しますパーティション)実行:
_mkdir -p /mnt/usb-hdd # ensure existing mountpoint
mount /dev/sdXN /mnt/usb-hdd # substitute X for the drive letter and N for the partition number from (3)
_
復元された_/etc/lvm
_バックアップを_/mnt/usb-hdd
_に書き込むか、コピーします。
umount /mnt/usb-hdd
_それが終わったら、rootfsまたはバックアップからフェッチした現在の_/etc/lvm/backup
_と_/etc/lvm/archive
_を見てください。 lvresize
を実行する前に作成されたバックアップメタデータがあり、それがすべての損害を引き起こした可能性があります。これらのディレクトリ内のファイルで、_description =
_で始まる行を探します。説明を一覧表示するには、_grep description .../etc/lvm/*/*
_を試してください。まだinitramfsシェルを使用している場合は、less
、more
を使用するか、それができない場合はcat
と Shift+PgUp/Shift+PgDn テキストファイルを表示します。 _Created *before* executing 'lvresize -l <something> /dev/vgprod/prod'
_のファイルはありますか? _vgcfgrestore -f /etc/lvm/archive/<suitable archive file> vgprod
_を実行してメタデータを以前の値に復元し、後で_/dev/vgprod/prod
_をマウントしてみます。
このような状況では、ファイルを正常にコピーして安全であることを確認するか、復元できると確信しているパーティションのイメージを作成する前に、いかなる種類のfsck
も実行しないようにする必要があります。切り捨てられたファイルシステムのfsck
は、事態を悪化させる可能性があります。