Behebung des Fehlers „Speicher kann nicht zugewiesen werden“ während eines SLES-System-Upgrades

Das SLES-Upgrade scheint fortzufahren, doch dann meldet ein Terminal, das Installationsprogramm oder ein Migrationsprotokoll „Speicher konnte nicht zugewiesen werden“. Diese Meldung beweist allein nicht, dass der Server mehr physischen Arbeitsspeicher benötigt. Der Fehler kann durch Speichermangel, eine Beschränkung einer virtuellen Maschine oder eines Dienstes, fehlenden oder nicht nutzbaren Auslagerungsspeicher oder die Upgrade-Umgebung selbst verursacht werden. Zunächst muss ermittelt werden, welcher Prozess und welche Upgrade-Phase die Meldung ausgelöst haben; die sichere Lösung hängt von dieser Information ab.

Die Versionsnummer ist wichtig. Im SUSE-Leitfaden für das Hauptversions-Upgrade auf SLES 16.0 (Stand: Oktober 2026) wird ein Migrationssystem beschrieben, das ein dediziertes Live-Upgrade-Image startet. SLES 15-Service-Pack-Migrationen hingegen nutzen den etablierten YaST- oder Zypper-Workflow. Wenden Sie einen Fix, der für eine Online-Service-Pack-Migration vorgesehen ist, nicht ohne Prüfung der Vorgehensweise Ihrer Version auf ein Hauptversions-Upgrade an. SUSE dokumentiert den aktuellen SLES 16-Pfad im SLES 16-Upgrade-Leitfaden .

1. Identifizieren Sie die fehlerhafte Phase, bevor Sie irgendetwas ändern.

Notieren Sie die vollständige Fehlermeldung, den Zeitstempel, den Befehl oder die Bildschirmanzeige, auf der der Fehler auftrat, und ob das System in ein Installations- oder Migrationsabbild neu gestartet wurde. „Speicher kann nicht zugewiesen werden“ ist ein allgemeiner Betriebssystemfehler; daher sind die umgebenden Zeilen oft hilfreicher als die Meldung allein.

• Vor Beginn der Paketverarbeitung kann ein Registrierungs-, Repository-, Migrationsvorbereitungs- oder Installationsprozess fehlschlagen. Überprüfen Sie den System- und Prozessspeicher und anschließend das entsprechende Dienst- oder Migrationsprotokoll.
• Während Pakete installiert oder entfernt werden: Zypper und RPM haben möglicherweise bereits Änderungen am System vorgenommen. Beenden Sie den Prozess nicht, starten Sie den Computer nicht neu und verwenden Sie keinen zweiten Paketmanager, nur weil der Fortschritt langsam erscheint. Überprüfen Sie die Konsole und die Protokolle und warten Sie, bis der unterstützte Migrationsprozess abgeschlossen ist oder ein eindeutiger Fehlerzustand erreicht ist.
• Nach einem Neustart mit einem Upgrade-Image kann der Prozess mit einer anderen Ressourcenumgebung als das ursprüngliche Betriebssystem ausgeführt werden. Ein vor dem Neustart sichtbarer Auslagerungsbereich ist kein Beweis dafür, dass das Upgrade-Image diesen nutzen kann.

Die Migrationssequenz von SUSE SLES 16 bereitet die Migrationsumgebung vor, bindet Dateisysteme ein, konfiguriert das Netzwerk, bereitet Zypper vor, aktualisiert Pakete, den Bootloader und startet das System neu. Laut Anleitung führt ein Fehler vor Beginn des Upgrades dazu, dass das System in den ursprünglichen Zustand zurückversetzt wird. Dies bedeutet jedoch nicht, dass jeder Fehler während des Paketaustauschs harmlos ist. Sichern Sie Protokolle und vermeiden Sie manuelle Wiederherstellungsschritte, bis Sie wissen, in welcher Phase der Fehler aufgetreten ist.

2. Überprüfen Sie RAM, Swap-Speicher und die letzten Kernel-Meldungen.

Falls das ursprüngliche SLES-System noch läuft oder Sie eine Wiederherstellungs-Shell erreicht haben, beginnen Sie mit schreibgeschützten Prüfungen:

free -h
swapon --show
vmstat 1 5
ps -eo pid,comm,rss,%mem --sort=-rss | head -n 15

free -hDie Übersicht fasst Speicher und Auslagerungsspeicher zusammen. Achten Sie auf den verfügbaren Speicher und den genutzten Auslagerungsspeicher, nicht nur auf die Spalte „frei“: Linux verwendet ansonsten ungenutzten RAM für Caches. Die vmstatÜbersicht zeigt an, ob das System ständig auslagert. Die Prozessliste kann Datenbanken, Java-Dienste, Backups oder andere Prozesse aufdecken, die während des Upgrades Speicher belegen.

Suchen Sie nach Kernel-OOM-Einträgen um den Fehlerzeitpunkt herum:

sudo journalctl -k --since "30 minutes ago" |
  grep -i -E 'out of memory|oom|killed process'

Wenn der Fehler früher auftrat, ändern Sie das Zeitfenster. Eine Kernel-Meldung, die einen beendeten Prozess nennt, deutet auf einen Speichermangel hin; das Fehlen einer übereinstimmenden Zeile schließt jedoch nicht alle Speicherzuweisungsfehler aus. Wenn das Upgrade in einer separaten Produktivumgebung durchgeführt wird, prüfen Sie deren Protokolle, sofern verfügbar, anstatt sich ausschließlich auf das Protokoll des alten Systems zu verlassen.

Prüfen Sie außerdem, ob eine virtuelle Maschine, ein Container oder eine systemd-Unit eine Speicherbegrenzung hat. Ein Gastsystem kann zwar über verfügbaren Speicher auf dem Host verfügen, aber dennoch an seine konfigurierte Grenze stoßen. Unter SLES 16 dokumentiert SUSE cgroups v2 als Standardhierarchie für die Ressourcensteuerung und erklärt, dass systemd Ressourcenbegrenzungen anwenden kann. Überprüfen Sie die entsprechende VM-Konfiguration oder MemoryMaxdie Einstellungen des Dienstes, anstatt globale Kernel-Grenzwerte willkürlich zu erhöhen. Weitere Informationen finden Sie im Leitfaden zu Kernel-Kontrollgruppen von SUSE für SLES 16 .

3. Reduzieren Sie die konkurrierende Speichernutzung und versuchen Sie es nur an einem sicheren Punkt erneut.

Wenn Messungen zeigen, dass eine Arbeitslast den Großteil des verfügbaren Speichers belegt, planen Sie ein Wartungsfenster ein und beenden Sie nicht benötigte Dienste ordnungsgemäß, bevor Sie es erneut versuchen. Beispiele hierfür sind speicherintensive Anwendungen, Analyseprozesse, Testdatenbanken und Sicherungsprozesse. Beenden Sie Speicher-, Cluster- oder Anwendungsdienste auf einem Produktivsystem nicht ohne Weiteres. Verwenden Sie stattdessen die dokumentierte Herunterfahrprozedur der Anwendung und stellen Sie sicher, dass das Beenden weder Benutzer noch Wiederherstellungsprozesse beeinträchtigt.

Vergleichen Sie bei einer virtuellen Maschine den konfigurierten Arbeitsspeicher des Gastsystems mit der Kapazität des Hostsystems und dem aktuellen Speicherbedarf anderer Gastsysteme. Ist der Arbeitsspeicher des Gastsystems zu klein, erhöhen Sie ihn mithilfe der vom Hypervisor unterstützten Methode. Ob eine Speichererweiterung im laufenden Betrieb möglich ist, hängt vom Hypervisor, der Gastsystemkonfiguration und der Arbeitslast ab; planen Sie gegebenenfalls einen Neustart ein. Überprüfen Sie in der Public Cloud die Instanzgröße und etwaige anbieterspezifische Speicherbeschränkungen.

Wenn die Meldung weiterhin angezeigt wird, obwohl ausreichend Arbeitsspeicher verfügbar ist und keine Speichermangelmeldung vorliegt, überprüfen Sie die Prozesslimits. Bei einem noch laufenden Prozess überprüfen Sie /proc/PID/limitsdie Prozess-ID. Bei einem von systemd verwalteten Upgrade-Helfer überprüfen Sie die Ressourceneinstellungen der Einheit. Ein Limit kann einen Prozess einschränken, selbst wenn der Host über freien Speicher verfügt. Ändern Sie ein Limit nur, wenn Sie die entsprechende Einstellung identifizieren und deren Auswirkungen verstehen können.

Nachdem die identifizierte Einschränkung behoben wurde, setzen Sie die Aktualisierung ausschließlich mit der für Ihre SLES-Version und Ihren Aktualisierungspfad unterstützten Methode fort oder versuchen Sie es erneut. Verwenden Sie für die Migration eines Service Packs auf SLES 15 den dokumentierten Migrationsworkflow von YaST oder Zypper. Folgen Sie für die Migration einer Hauptversion auf SLES 16 der Migrationsprozedur der SLES 16-Distribution. Die SUSE-Anleitung zu SLES 15 SP7 erläutert den Service-Pack-Workflow und die Voraussetzungen für ein unterstütztes Rollback in der Online-Aktualisierungsdokumentation .

4. Überlegen Sie sich den Austausch gut; verwenden Sie ihn nicht als Blindfluglösung.

Zusätzlicher Auslagerungsspeicher kann einem System mehr virtuellen Speicher zur Verfügung stellen, wenn die Arbeitslast den Arbeitsspeicher auslagern kann. Er ist jedoch deutlich langsamer als RAM. Wenn das System bereits stark auslagert, kann das Hinzufügen von mehr Auslagerungsspeicher das Upgrade extrem verlangsamen, ohne eine zu kleine VM oder eine Beschränkung isolierter Prozesse zu beheben. Prüfen Sie zunächst, ob Auslagerungsspeicher vorhanden ist und ob er verwendet wird swapon --show.free -h

Befolgen Sie die SUSE-Anleitung für Ihre SLES-Version und Ihr Dateisystem, wenn Sie Swap-Speicher hinzufügen müssen. Seien Sie besonders vorsichtig bei Btrfs: SUSE dokumentiert die Einschränkungen für Swap-Dateien auf Btrfs und gibt an, dass kein Snapshot erstellt werden kann, solange eine Swap-Datei im Quell-Subvolume aktiv ist. Da SLES üblicherweise Snapper-Snapshots für die Systemwiederherstellung verwendet, sollten Sie während eines Upgrade-Fensters keine generische Swap-Datei auf dem gesnapshotten Root-Subvolume erstellen und aktivieren. Fügen Sie stattdessen RAM hinzu oder verwenden Sie eine korrekt konfigurierte Swap-Partition oder einen unterstützten Speicherort, nachdem Sie das Speicherlayout und den Wiederherstellungsplan geprüft haben. Die dateisystemspezifischen Details finden Sie im SUSE- Speicherhandbuch für SLES 15 SP7 .

Ändern Sie nicht die Einstellungen vm.overcommit_memory, deaktivieren Sie den OOM-Killer nicht und führen Sie keine beliebigen Bereinigungsbefehle als erste Maßnahme aus. Solche Änderungen können die Symptome verschleiern, Workloads destabilisieren oder die Wiederherstellung erschweren. Sammeln Sie zunächst Beweise und befolgen Sie die spezifischen Anweisungen von SUSE oder Ihrem Anwendungshersteller, falls die Protokolle auf eine spezielle Speicherkonfiguration hinweisen.

5. Wiederherstellung, falls das Upgrade nach Beginn der Paketänderungen abgebrochen wurde.

Bevor Sie ein Upgrade erneut ausführen, prüfen Sie, ob der Paketmanager noch aktiv ist und ob das Migrationstool einen endgültigen Fehler gemeldet hat. Falls das Upgrade nach Beginn der Paketänderungen abgebrochen wurde, speichern Sie die vollständige Protokollausgabe und konsultieren Sie die versionsspezifische Wiederherstellungsdokumentation. Führen Sie die Befehle `yast migration` und `rpm` nicht zypper dupgleichzeitig zypper migrationaus.

Unter SLES 15 SP7 dokumentiert SUSE das Rollback von Service Packs, wenn das Root-Dateisystem Btrfs ist und Snapper-Snapshots aktiviert sind. Das Rollback-Verfahren erfordert das Identifizieren und Testen des Snapshots vor der Migration und die anschließende permanente Wiederherstellung. Es ist keine universelle Lösung für jeden Upgrade-Fehler. Die Migration auf eine Hauptversion von SLES 16 folgt einem anderen Workflow. Verwenden Sie daher die aktuellen Upgrade- und Wiederherstellungsanweisungen von SLES 16 und gehen Sie nicht davon aus, dass das Verfahren von SLES 15 anwendbar ist. Wenn das System geschäftskritisch ist, kein getestetes Backup vorhanden ist oder die Migration während des Paketaustauschs fehlschlägt, eröffnen Sie ein Support-Ticket bei SUSE, bevor Sie manuelle Paketreparaturen versuchen.

6. Überprüfen Sie das System, bevor Sie den normalen Betrieb wiederaufnehmen.

Sobald die Aktualisierung abgeschlossen ist und der Server normal hochfährt, überprüfen Sie die Betriebssystemversion und -registrierung. Prüfen Sie anschließend die Paketkonsistenz und die Arbeitslast, die das Problem ursprünglich aufgedeckt hat:

cat /etc/os-release
sudo SUSEConnect --status
sudo zypper verify
free -h
swapon --show

Verwenden Sie den von Ihrer SLES-Version unterstützten Befehl zur Paketverifizierung. Falls zypper verifydieser in Ihrer Version nicht verfügbar ist oder sich anders verhält, konsultieren Sie zypper helpdas Administrationshandbuch Ihrer Version. Prüfen Sie die Anwendungs- und Kernelprotokolle auf neue Fehler, stellen Sie sicher, dass die vorgesehenen Dienste fehlerfrei funktionieren, und überwachen Sie Speicher und Auslagerungsspeicher, während die Last wieder ansteigt. Vergewissern Sie sich vor dem Schließen des Wartungsfensters, dass das unterstützte Upgrade-Ziel installiert wurde und sich die Serverregistrierung und die Repositories im erwarteten Zustand befinden.

Eine erfolgreiche Fehlerbehebung bedeutet mehr als nur das Verschwinden einer Fehlermeldung: Die SLES-Migration wird über einen unterstützten Pfad abgeschlossen, das System startet mit der erwarteten Version, Pakete und Registrierungen werden erfolgreich geprüft, und normale Arbeitslasten laufen ohne wiederholte Speichermangelereignisse. Falls die Fehlermeldung „Speicher kann nicht zugewiesen werden“ trotz geringer Speicherauslastung, ausreichendem Auslagerungsspeicher und keiner Ressourcenbegrenzung weiterhin erscheint, sollten Sie die genauen Protokoll- und Prozessdetails aufbewahren – diese Hinweise helfen, einen Upgrade-Fehler von einem Kapazitätsproblem zu unterscheiden.