ubuntuusers.de

Für diese Funktion musst du eingeloggt sein.

Server im "emergency mode" nach Updates

Status: Gelöst | Ubuntu-Version: Ubuntu 22.04 (Jammy Jellyfish)
Antworten |

nonickatall

Anmeldungsdatum:
17. Juni 2019

Beiträge: 28

Hallo Gemeinde,

der Text ist ziemlich lang geworden, deshalb zunächst eine kurze Zusammenfassung:

Mein neu installierter Ubuntu Server 22.04 auf einem Dell r720 startet (reproduzierbar) nach einem sudo apt-get update/upgrade nur noch im "emergency mode".

Kann da jemand helfen?

Und hier die lange Version:

Ich hatte seit einigen Jahren ein Ubuntu Server 18.04 laufen, der mir bisher gute Dienste geleistet hat. Nun musste mal neue Hardware her und ich habe mir einen ordentlich ausgestatteten, gebrauchten Dell R720 Server mit 128 GB RAM und 3,7 Terabyte RAID 10 zugelegt.

Habe Ubuntu 22.04 installiert, alles eingerichtet, und meine Daten zurück kopiert.

Auf dem Server laufen bind9, ISC-DHCP-Server, ein MySQL Server, Samba und Moskito.

Habe eigentlich alles über SSH zunächst auf zwei 300 GB Platten eingerichtet weil die großen Platten noch beschafft werden mussten und parallel auf dem Monitor journalctl -l laufen lassen.

Der Server hatte bis auf eine DNS Fehlermeldung, die von einem fehlerhaften Namen (mit _) eines Huawei Handys kommt, keine Fehler, weder beim Start, noch im Betrieb.

Und nachdem ich fertig war und der Server bereits zwei Tage ohne Probleme lief, habe ich endlich 4 * 2tb Platten geliefert bekommen, die ich in einem Raid 10 eingebunden habe. Da dann aber das portieren der Boot Partition über ein Live System nicht funktionierte, habe ich die Konfigurationsdateien auf einen USB-Stick kopierte, die zwei 300er Platten auf denen das funktionierende Ubuntu lief, aus dem Server entfernt und die Installation einfach wiederholt. Ich habe meine Config-Dateien natürlich übernommen.

Der Server lief danach genauso wie vorher, was bei Linux ja auch zu erwarten ist und als ich nun soweit war, das Gerät in den Real-Betrieb zu nehmen, habe ich heute Nacht die Nutzdaten auf den Server kopiert.

Zwischendrin, in der langen Wartezeit, habe ich noch ein "sudo apt-get update" und ein "sudo apt-get upgrade" gemacht.

Dieses lief sauber und endete in einem grafischen Fenster, in dem Ubuntu mich aufforderte: "Die Services zu benennen, die momentan nicht neu gestartet werden können." Da ich mitten im kopieren war, habe ich Bind, DHCP und Samba nicht neu gestartet.

Der Server hatte im Syslog weiterhin keine fehlerhaften Einträge.

Als das Kopieren fertig war, dachte ich: So jetzt zum Abschluss noch Neustart und fertig ist der Server.

Aber leider endete der Systemstart mit einem Emergency Mode, aus dem ich nicht mehr rauskomme. Das Syslog kann ich leider nur fotografieren, weil ich nicht mehr ans Netz komme.

So wie ich das sehe, scheint er die Netzwerkkarte nicht mehr starten zu können. zumindest hatte ich beim Start ein solche Meldung gesehen.

Daraufhin habe ich die 300er Platten wieder in den Server gebaut. Da läuft ja das selbe Linux, in derselben Konfiguration, nur hatte ich da nach der Einrichtung noch keine Updates gefahren und siehe da: Die Maschine läuft.

Das Update muss mir also die Maschine zerschossen haben. 😢

Hat jemand eine Idee was ich tun kann, bevor ich wieder 18.04 installiere?

Vielen Dank im Voraus Ralf

Anlage: Bilder der Syslogs

Bilder

ChickenLipsRfun2eat Team-Icon

Anmeldungsdatum:
6. Dezember 2009

Beiträge: 12067

Deine Samba-Fehlermeldung ist ja recht eindeutig. Du musst das Protokoll entsprechend anpassen → Samba. Falls du dabei Hilfe brauchst → serverdienste.

Wegen der ACPI-Fehler hilft nur ein UEFI-Upgrade oder aktuellere Firmware. Eventuell kannst du mittels Bootoptionen noch was erreichen, aber bitte kein acpi=off oder solche „Hämmer“. Theoretisch sollte das System aber starten können und alle Dienste bis auf Samba auch laufen. Oder fehlen da noch Informationen?

Log dich mal ein und gehe Schritt für Schritt vor:

ip a  # Netzwerkverbindungen prüfen
journalctl -b -p err  # nur Fehler Anzeigen
journalctl -b -p warning # zusäztlich Warnungen

dingsbums

Anmeldungsdatum:
13. November 2010

Beiträge: 3776

Vielleicht lassen sich die schönen bunten Meldungen für ipmi_si vermeiden, wenn du mit der Bootoption modprobe.blacklist=ipmi_si startest. Siehe Bootoptionen (Abschnitt „Start-eines-installierten-Systems-einmalig“)

Das letzte Kernel-Update für Jammy ist vom 24.05., siehe https://ubuntu.com/security/notices?order=newest&release=jammy&details=kernel. Älteren Kernel starten wäre also auch einen Versuch wert.

nonickatall

(Themenstarter)

Anmeldungsdatum:
17. Juni 2019

Beiträge: 28

Hallo,

vielen Dank für die Antworten hat mich schon weiter gebracht. 👍

Das BIOS stand tatsächlich noch auf 1.6.0 und es gibt schon eine 2.9.0. Habe also das BIOS mal upgedatet und gestartet, allerdings mit demselben Ergebnis.

Oder meintest du zusätzlich, dass ich das Booten grundsätzlich auf UEFI umstelle?

Das mit dem Samba ist kein Samba Fehler, sondern ich habe noch eine externe Festplatte in der fsab stehen, wo die Syntax unter 18.04 noch funktioniert hat, aber unter 22.04 nicht. Ich denke aber das ist erstmal irrelevant.Die ließ sich auch vor dem Update, dass mir den Server zerschossen hat, nicht einbinden und der Server startete ohne Probleme..

Habe aber leider keine Zeit gehabt mich heute groß um die Maschine zu kümmern, zumal die Maschine mit der Installation auf den 300er Platten ja läuft.

Werde mich dem Thema wahrscheinlich am Freitag widmen und dann auch die gewünschten Informationen liefern, bzw. das andere mit den boot Optionen und dem anderen Kernel versuchen.

Aber euch beiden schonmal bis hierhin..

Vielen Dank.

LG Ralf

kB Team-Icon

Supporter, Wikiteam
Avatar von kB

Anmeldungsdatum:
4. Oktober 2007

Beiträge: 9608

Wohnort: Münster

nonickatall schrieb:

[…] RAID 10 […] zwei 300 GB Platten

RAID 10 auf 2 Platten? Wie soll das gehen? Ich kenne das nur mit mindestens 4 Platten.

[…] 4 * 2tb Platten

[…] Konfigurationsdateien auf einen USB-Stick kopiert […] Ich habe meine Config-Dateien natürlich übernommen.

Welche Konfigurationsdateien genau? Ein System mit 2 physischen Platten und eines mit 4 physischen Platten unterscheiden sich doch strukturell sehr deutlich und in der Größe der Platten sowieso. Wie kann da eine Konstanz der Konfigurationsdateien erwartet werden, Sinn machen und gar funktionieren? Und was ist mit UUIDs in den Konfigurationsdateien?

Und wo liegt der Boot-Manager und wie greift dieser auf seine Konfiguration, Linux-Kernel und initrd.img zu? Wie wird überhaupt gebootet?

nonickatall

(Themenstarter)

Anmeldungsdatum:
17. Juni 2019

Beiträge: 28

Na, in dem Server waren beim Kauf 2 * 300GB Platten, die natürlich kein Raid 10 sein können, das ist richtig, sondern ein Raid 0 sind. Die vier 2TB Platten sind das Raid 10.

Ich hatte die 4 TB Platten aber anfangs noch nicht und hatte den Server schon mal testweise auf die 2 * 300GB Platten installiert. Diese kann ich natürlich leicht hin und her wechseln und muss diese dann im Raid Controller nur aktivieren.

Linux wie jedem anderem Betriebssystem ist das völlig wurscht, denn aus Sicht des Betriebssystems befindest es sich auf einer 3,7 TB großen Platte. Das hinter diesem virtuellen Laufwerk ein Raid 10 mit vier 2 TB Platten hinter ist, davon weiß Linux wahrscheinlich nicht mal was.

Und installiert habe ich es ganz normal und dann die Konfigurationsdateien, wie die resolve.conf, die namend.conf.* von Bind9, die Zonendateien, die smb.conf von Samba und andere einfach übernommen. In denen steht nix von irgendwelchen Partitionen oder UUIDS..

Oder verstehe ich deine Frage falsch?

Wie gesagt funktionierte ja auch bis zum upgrade...

nonickatall

(Themenstarter)

Anmeldungsdatum:
17. Juni 2019

Beiträge: 28

So, ich habe den Server gekillt und Ubuntu 20.04 installiert.

Nun läuft er ohne Fehler..

Vermute mal da ist irgendeine Hardware Inkompatibilität..

Jetzt habe ich nur noch mein SAMBA Problem mit den zu kleinen Shares..

https://forum.ubuntuusers.de/topic/samba-shares-mehr-speicherplatz-zuweisen/

Vielen Dank nochmal für die Hilfe..

LG Ralf

Antworten |