☰

壊れた lvm により read_urandom エラーが発生する

tag-icon • tag-icon lvm
壊れた lvm により read_urandom エラーが発生する

chroot で何か作業をしていたのですが、残念ながらホストが壊れてしまいました。これでボリューム グループを管理できなくなりました。

pvs
  read_urandom: /dev/urandom: open failed: No such file or directory

lvm に関する異なるコマンドで同じエラーが発生します。再構成を試行しています:

# dpkg-reconfigure linux-image-4.19.0-16-amd64

/etc/kernel/postinst.d/dkms:
dkms: running auto installation service for kernel 4.19.0-16-amd64:/usr/sbin/dkms: line 3345: /dev/fd/62: No such file or directory
.
/etc/kernel/postinst.d/initramfs-tools:
update-initramfs: Generating /boot/initrd.img-4.19.0-16-amd64
cryptsetup: ERROR: Couldn't resolve device 
    /dev/mapper/rootvg-root--server--alpha--host
cryptsetup: WARNING: Couldn't determine root device
cryptsetup: ERROR: Couldn't resolve device /dev/dm-1 (deleted)
cryptsetup: ERROR: Couldn't resolve device 
    UUID=e9ef352b-a648-4499-ade2-54235f40a3df
W: Couldn't identify type of root file system for fsck hook
I: The initramfs will attempt to resume from /dev/dm-1 (deleted)
I: Set the RESUME variable to override this.
/etc/kernel/postinst.d/zz-update-grub:
/usr/sbin/grub-probe: error: failed to get canonical path of `/dev/mapper/rootvg-root--server--alpha--host'.
run-parts: /etc/kernel/postinst.d/zz-update-grub exited with return code 1

initramfs を更新しようとしています:

# update-initramfs -u
update-initramfs: Generating /boot/initrd.img-4.19.0-16-amd64
cryptsetup: ERROR: Couldn't resolve device 
    /dev/mapper/rootvg-root--server--alpha--host
cryptsetup: WARNING: Couldn't determine root device
cryptsetup: ERROR: Couldn't resolve device /dev/dm-1 (deleted)
cryptsetup: ERROR: Couldn't resolve device 
    UUID=e9ef352b-a648-4499-ade2-54235f40a3df
W: Couldn't identify type of root file system for fsck hook
I: The initramfs will attempt to resume from /dev/dm-1 (deleted)
I: Set the RESUME variable to override this.

パーティションアーキテクチャ:

# lsblk
NAME                                       MAJ:MIN RM  SIZE RO TYPE  MOUNTPOINT
nvme1n1                                    259:0    0  1.8T  0 disk  
├─nvme1n1p1                                259:2    0    2M  0 part  
│ └─md1                                      9:1    0    2M  0 raid1 
├─nvme1n1p2                                259:3    0  510M  0 part  
│ └─md2                                      9:2    0  509M  0 raid1 /boot
└─nvme1n1p3                                259:4    0  1.8T  0 part  
  └─md3                                      9:3    0  1.8T  0 raid1 
    └─croot                                253:0    0  1.8T  0 crypt 
      ├─rootvg-swap--server--alpha--host 253:1    0    8G  0 lvm   
      ├─rootvg-root--server--alpha--host 253:2    0  1.5T  0 lvm   /
      ├─rootvg-root--vm1                   253:3    0  100G  0 lvm   
      ├─rootvg-root--vm2                   253:4    0   20G  0 lvm   
      ├─rootvg-root--vm3                   253:5    0   40G  0 lvm   
      └─rootvg-root--vm4                   253:6    0  100G  0 lvm   
nvme0n1                                    259:1    0  1.8T  0 disk  
├─nvme0n1p1                                259:5    0    2M  0 part  
│ └─md1                                      9:1    0    2M  0 raid1 
├─nvme0n1p2                                259:6    0  510M  0 part  
│ └─md2                                      9:2    0  509M  0 raid1 /boot
└─nvme0n1p3                                259:7    0  1.8T  0 part  
  └─md3                                      9:3    0  1.8T  0 raid1 
    └─croot                                253:0    0  1.8T  0 crypt 
      ├─rootvg-swap--server--alpha--host 253:1    0    8G  0 lvm   
      ├─rootvg-root--server--alpha--host 253:2    0  1.5T  0 lvm   /
      ├─rootvg-root--vm1                   253:3    0  100G  0 lvm   
      ├─rootvg-root--vm2                   253:4    0   20G  0 lvm   
      ├─rootvg-root--vm3                   253:5    0   40G  0 lvm   
      └─rootvg-root--vm4                   253:6    0  100G  0 lvm

問題は、rootvg-root--vm4 で chroot を実行したときに発生しました。おそらく、update-initramfs またはホストで実行中のプロセスに影響する /mnt 内のファイルの削除が原因です。現在、そのボリュームを削除することすらできず、サーバーを再起動するとサーバーが失われるのではないかと心配しています...

皆様のご支援をお待ちしております。よろしくお願いします。

編集済み:

その他のアクション: VM を再起動しようとしています:

$ sudo virsh start vm2-bastion
sudo virsh start vm2

error: Failed to start domain vm2
error: internal error: Failed to probe QEMU binary with QMP: Could not access KVM kernel module: No such file or directory
qemu-system-x86_64: failed to initialize KVM: No such file or directory
qemu-system-x86_64: Back to tcg accelerator

SSH 経由の従来のアクセスが失われました:

$ ssh user@ip
PTY allocation request failed on channel 0

...しかし、私は次のようにログインすることができました:

$ ssh user@ip "/bin/bash -i" 

bash: cannot set terminal process group (-1): Inappropriate ioctl for device
bash: no job control in this shell
user@server-alpha-host:~$

答え1

今ではそのボリュームを削除することすらできず、サーバーが再起動するとサーバーが失われるのではないかと心配です...

重要なデータはすべてバックアップしてください。このホストが重要な場合は、再構築して回復できる必要があります。

削除が発生した場所と時間にブロック デバイスがマウントされていたかどうか、またそれらのデータに関心があるかどうかを判断します。おそらくそうではないかもしれませんが、SIGINT を送信したからといって、削除がデバイス ノードで停止したわけではありません。

/dev/urandom、/dev/kvm、ブロック デバイス、/proc、およびその他のデバイスが不足すると、多くのことが壊れます。これらを元に戻すには再起動してください。devtmpfs と udev は、通常、起動のたびにデバイス ノードを再作成します。この再起動は、すべての不正なプログラムが再起動されるようにするためのもので、最終的には必ず実行されます。

関連情報