Ich hoffe, dass irgendjemand Erfahrung mit EC2 hat. Ich bin in einer Zwickmühle.
Ich habe glibc versehentlich von meiner Amazon Linux 2-Instanz entfernt. Nun, nicht ganz aus Versehen, ich habe versucht, das vorhandene durch das offizielle Amzn2-Repo-Paket zu ersetzen (ich hatte zuvor versucht, es manuell über rpm zu aktualisieren).
Obwohl ich es schon einmal gemacht hatte, bin ich dieser Anleitung gefolgt:https://www.rootusers.com/how-to-repair-an-aws-ec2-instance-without-console/
Ich habe eine neue Amazon Linux 2-Instanz erstellt, ein neues Volume aus dem Snapshot gemountet, den ich erstellt habe, dev/nvme1n1p1 gemountet und chrootet. Glibc und Yum repariert. Yum-Distro-Sync ausgeführt (jetzt keine Probleme mehr). Ich habe alles sorgfältig unmountet. Die Instanz heruntergefahren. Einen neuen Snapshot erstellt. Aus diesem Snapshot ein neues Volume erstellt. Dieses Volume als dev/xvda an meine erste (defekte) Instanz gemountet. Und es funktioniert nicht. 1/2 Systemprüfungen bestanden (also nach einer wirklich langen Zeit) und es ist nicht erreichbar. Habe das Kernel-Protokoll durchgesehen, konnte aber nichts Ungewöhnliches finden. Ich habe versucht, Elastic IPs erneut anzuhängen.
Ich habe sogar versucht, das reparierte Volume direkt nach der Reparatur als Root in meine temporäre Instanz einzubinden. Hat trotzdem nicht funktioniert. Habe sogar versucht, AMI aus dem Snapshot zu erstellen. Ich wäre für jede Hilfe wirklich dankbar, ich weiß nicht, was ich tun soll.
Antwort1
Okay, falls jemand Probleme beim Chrooten in eine Amazon Linux 2-Instanz hat, obwohl der Host auch eine Amazon Linux 2-Instanz ist (also dieselbe Architektur), kopieren Sie einfach die fehlenden Bibliotheken in /mnt/lib64. Wichtig ist, dass Sie sie nicht mounten, wenn dieses Verzeichnis für die Reparatur benötigt wird.
Z.B# cp -n /lib64/* /mountpoint/lib64/