Lvm rupt duce la o eroare read_urandom

Făceam ceva într-un chroot și, din păcate, am spart gazda. Acum nu pot gestiona grupurile de volum:

pvs
  read_urandom: /dev/urandom: open failed: Nu există un astfel de fișier sau director

Aceeași eroare cu diferite comenzi despre lvm.. Încercarea de a reconfigura:

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

/etc/kernel/postinst.d/dkms:
dkms: rulează serviciul de instalare automată pentru kernel 4.19.0-16-amd64:/usr/sbin/dkms: linia 3345: /dev/fd/62: nu există un astfel de fișier sau director
.
/etc/kernel/postinst.d/initramfs-tools:
update-initramfs: se generează /boot/initrd.img-4.19.0-16-amd64
cryptsetup: EROARE: Dispozitivul nu a putut fi rezolvat 
    /dev/mapper/rootvg-root--server--alpha--gazdă
cryptsetup: AVERTISMENT: Nu s-a putut determina dispozitivul root
cryptsetup: EROARE: Nu s-a putut rezolva dispozitivul /dev/dm-1 (șters)
cryptsetup: EROARE: Dispozitivul nu a putut fi rezolvat 
    UUID=e9ef352b-a648-4499-ade2-54235f40a3df
W: Nu s-a putut identifica tipul de sistem de fișiere rădăcină pentru hook fsck
I: initramfs va încerca să reia din /dev/dm-1 (șters)
I: Setați variabila RESUME să o înlocuiască.
/etc/kernel/postinst.d/zz-update-grub:
/usr/sbin/grub-probe: eroare: nu s-a putut obține calea canonică a `/dev/mapper/rootvg-root--server--alpha--host'.
run-parts: /etc/kernel/postinst.d/zz-update-grub ieșit cu codul de întoarcere 1

Încerc să actualizezi initramfs:

# update-initramfs -u
update-initramfs: se generează /boot/initrd.img-4.19.0-16-amd64
cryptsetup: EROARE: Dispozitivul nu a putut fi rezolvat 
    /dev/mapper/rootvg-root--server--alpha--gazdă
cryptsetup: AVERTISMENT: Nu s-a putut determina dispozitivul root
cryptsetup: EROARE: Nu s-a putut rezolva dispozitivul /dev/dm-1 (șters)
cryptsetup: EROARE: Dispozitivul nu a putut fi rezolvat 
    UUID=e9ef352b-a648-4499-ade2-54235f40a3df
W: Nu s-a putut identifica tipul de sistem de fișiere rădăcină pentru hook fsck
I: initramfs va încerca să reia din /dev/dm-1 (șters)
I: Setați variabila RESUME să o înlocuiască.

Arhitectura partiției:

# lsblk
NUME MAJ:MIN RM DIMENSIUNE RO TIP PUNCT DE MONTARE
nvme1n1 259:0 0 1.8T 0 disc  
âânvme1n1p1 259:2 0 2M 0 parte  
â ââmd1 9:1 0 2M 0 raid1 
âânvme1n1p2 259:3 0 510M 0 parte  
â ââmd2 9:2 0 509M 0 raid1 /boot
âânvme1n1p3 259:4 0 1.8T 0 parte  
  ââmd3 9:3 0 1.8T 0 raid1 
    ââcroot 253:0 0 1.8T 0 criptă 
      âârootvg-swap--server--alpha--gazdă 253:1 0 8G 0 lvm   
      âârootvg-root--server--alpha--gazdă 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 disc  
âânvme0n1p1 259:5 0 2M 0 parte  
â ââmd1 9:1 0 2M 0 raid1 
âânvme0n1p2 259:6 0 510M 0 parte  
â ââmd2 9:2 0 509M 0 raid1 /boot
âânvme0n1p3 259:7 0 1.8T 0 parte  
  ââmd3 9:3 0 1.8T 0 raid1 
    ââcroot 253:0 0 1.8T 0 criptă 
      âârootvg-swap--server--alpha--gazdă 253:1 0 8G 0 lvm   
      âârootvg-root--server--alpha--gazdă 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  

Problema a fost la a face chroot pe rootvg-root--vm4. Poate din cauza update-initramfs sau a eliminării fișierelor din /mnt care au afectat procesele care rulează pe gazdă. Acum nici măcar nu pot șterge acel volum și mi-e teamă să pierd serverul dacă un server se repornește...

astept sprijinul dumneavoastra, multumesc anticipat.

editat:

Mai multe acțiuni: Încercarea de a reporni o VM:

$ sudo virsh start vm2-bastion
sudo virsh start vm2

eroare: Nu s-a pornit domeniul vm2
eroare: eroare internă: nu s-a putut testa binarul QEMU cu QMP: nu s-a putut accesa modulul kernel KVM: nu există un astfel de fișier sau director
qemu-system-x86_64: nu a reușit inițializarea KVM: Nu există un astfel de fișier sau director
qemu-system-x86_64: Înapoi la acceleratorul tcg

Am pierdut accesul convențional prin SSH:

$ ssh utilizator@ip
Solicitarea de alocare PTY a eșuat pe canalul 0

...dar am reusit sa ma autent folosind:

$ ssh utilizator@ip „/bin/bash -i” 

bash: nu se poate seta grupul de procese terminale (-1): ioctl neadecvat pentru dispozitiv
bash: nu există control de job în acest shell
utilizator@server-alfa-gazdă:~$

Acum nici măcar nu pot șterge acel volum și mi-e teamă să pierd serverul daca un server reporneste...

Faceți backup pentru orice date importante. Dacă această gazdă este importantă pentru tine, trebuie să fie posibil să o reconstruiești și să o recuperezi.

Stabiliți dacă dispozitivele bloc au fost montate unde și când a avut loc ștergerea și dacă vă pasă de datele de pe ele. Posibil nu, dar doar pentru că l-ai trimis SIGINT nu înseamnă că ștergerea sa oprit la nodurile dispozitivului.

Lipsa /dev/urandom, /dev/kvm, blocarea dispozitivelor, /proc și a altor dispozitive va distruge multe lucruri. Reporniți pentru a le recupera. devtmpfs și udev recreează în mod normal nodurile dispozitivului la fiecare pornire. Această repornire este pentru a se asigura că fiecare program care se comportă greșit este repornit și trebuie să se întâmple în cele din urmă.