Drucken

Bitte loggen sie sich ein oder registrieren sie sich.
1 Stunde 1 Tag 1 Woche 1 Monat Immer
Einloggen mit Benutzername, Passwort und Sitzungslänge

[Clement]

Edit: Lösung siehe Antwort.

Hallo,
ich habe sowohl Free als auch Paid VS2-Server und betreibe jeweils das Archlinux-Image als OS. Nach einem kürzlichen Update der Systeme (pacman -Su) booten die Server nicht mehr, nicht einmal Logs oder Journal-Entries werden geschrieben (über Rescue-System einsehbar).

Das tritt auch bei komplett neu installierten Servern auf. Während des Updates wird die ssh-Verbindung mittendrin getrennt. Interessanterweise direkt nachdem das Paket "systemd" aktualisiert wurde. Ich schätze mal, dass ein aktuelles systemd mittlerweile "zu neu" für den verwendeten Kernel des Hosts der Virtualisierungslösung ist (LXC-Kernel?).

Hat EUserv eine Idee, wie man es doch hinbekommen könnte ein Archlinux-Server zu updaten? Wäre es eventuell auch einmal an der Zeit, ein neueres Image für Archlinux bereitzustellen? Ein Image von 2022 ist ja auch nicht mehr sonderlich aktuell.

Hier die Schritte auf einem frisch neu installierten "Archlinux 2022.09 - 64Bit - minimal v4"-Server, die zu dem Problem führen:

Code: [Auswählen]

# pacman -Sy
[...]
# pacman -S archlinux-keyring
[...]
# pacman -Su
[...]
(111/162) Aktualisiert wird kbd                                                                 [########################################################] 100%
(112/162) Aktualisiert wird libelf                                                              [########################################################] 100%
(113/162) Aktualisiert wird systemd                                                             [########################################################] 100%
Warnung: Verzeichnis-Berechtigungen unterscheiden sich für /usr/share/polkit-1/rules.d/
Dateisystem: 750  Paket: 755
Creating group 'clock' with GID 973.
Creating group 'groups' with GID 972.
Connection to 2a02:180:6:1::1dd closed by remote host.
Connection to 2a02:180:6:1::1dd closed.
$

Danke und viele Grüße!

[Clement]

Habe es hinbekommen. Es lag tatsächlich an systemd. Die letzte funktionierende Version ist 257.9, 258 scheint zu neu für den Host-Kernel zu sein.

Falls noch jemand über das Problem stolpert, folgendermaßen konnte ich ein frisch neu installierten vServer updaten.
Als erstes ein volles Update auf dem Live-System starten:

Code: [Auswählen]

# pacman -Sy
# pacman -S archlinux-keyring
# pacman -Su

Hierbei "crasht" der Server dann, man kann das Update aber über das Rescue-System fortsetzen. Dazu zuerst im Kundencenter den vServer auf Rescue-System umschalten und in dieses einloggen. Hier dann in das Live-System chrooten:

Code: [Auswählen]

# mount --bind /dev /mnt/custom/dev; mount --bind /proc /mnt/custom/proc; mount --bind /sys /mnt/custom/sys; mount --bind /run /mnt/custom/run
# chroot /mnt/custom

Im chroot-Live-System funktioniert dann nicht einmal mehr pacman, daher muss man zunächst mit pacman-static arbeiten (https://wiki.archlinux.org/title/Pacman#Using_pacman-static). Damit dann das Update fortsetzen, zuvor muss man eventuell eine Lock-Datei löschen:

Code: [Auswählen]

# rm /var/lib/pacman/db.lck
# pacman-static -Su

Danach sollte das normale pacman auch wieder funktionieren. Nun hat man aber systemd auf die neueste Version aktualisiert, daher muss man jetzt noch ein Downgrade auf Version 257.9 durchführen. Folgende Pakete herunterladen:

https://archive.archlinux.org/packages/s/systemd/systemd-257.9-1-x86_64.pkg.tar.zst
https://archive.archlinux.org/packages/s/systemd-libs/systemd-libs-257.9-1-x86_64.pkg.tar.zst
https://archive.archlinux.org/packages/s/systemd-sysvcompat/systemd-sysvcompat-257.9-1-x86_64.pkg.tar.zst

Diese Pakete dann manuell installieren:

Code: [Auswählen]

# pacman -U systemd-257.9-1-x86_64.pkg.tar.zst systemd-libs-257.9-1-x86_64.pkg.tar.zst systemd-sysvcompat-257.9-1-x86_64.pkg.tar.zst

Dann noch eben diese Pakete in /etc/pacman.conf ignorieren, damit beim nächsten Update nicht wieder das gleiche passiert:

Code: [Auswählen]

IgnorePkg = systemd systemd-libs systemd-sysvcompat

Nun sollte das Live-System wieder booten, also im Kundencenter den vServer wieder auf Live-System umstellen und rebooten. Das war jetzt aus dem Gedächtnis, also eventuell fehlt irgendwo ein kleiner Schritt, aber das war der grobe Weg, der für mich funktioniert hat.


Viele Grüße!