Azure Linux häufig gestellte Fragen (FAQ) – Kernel

Dieser Artikel enthält Antworten auf einige der häufigsten Fragen zum Azure Linux-Kernel, einschließlich der Auswahl einer Kernelversion, der Verwaltung von Kernelmodulen und dem Exportieren von Kernelabbildern zum Debuggen.

Wie wird die Kernelversion für eine bestimmte Azure Linux-Version ausgewählt?

Die ausgewählte Kernelversion ist der aktuelle long-term Support (LTS)-Kernel zum Zeitpunkt der Azure Linux-Hauptversion. Beispielsweise wird Azure Linux 4.0 mit der LTS-Kernelversion 6.18 ausgeliefert. Weitere Informationen finden Sie unter Azure Linux release cadence and lifecycle.

Was ist die Kernelversionskonvention?

Azure Linux-Kernelversionen folgen dem Format Major.Minor.Patch.Integration-Release.alN, wobei:

• Major.Minor ist die upstream LTS-Kernelversion (z. B. 6.18).
• Patch ist die upstream LTS-Patchnummer von kernel.org.
• Integration ist die interne Integrationsnummer für Updates zusätzlich zur vorgelagerten LTS-Version.
• Release ist die Release-Nummer des RPM-Pakets, die verwendet wird, wenn die RPM-Paketdefinition aktualisiert wird.
• alN gibt die Azure Linux-Version an (z. B. al4 für Azure Linux 4.0).

Sie können die ausgeführte Kernelversion mit dem uname -r Befehl überprüfen.

Was sind die empfohlenen Größen- und Platzierungsrichtlinien für /var/crash bei Verwendung von kdump?

Ein kdump vmcore ist eine Momentaufnahme des physischen Speichers des Systems zum Zeitpunkt eines Absturzes, und seine Größe kann nahe am gesamten installierten RAM liegen.

In Azure Linux werden vmcore-Dateien standardmäßig auf dem Betriebssystemdatenträger unter /var/crash gespeichert. Das Speichern von vmcore-Dateien dort kann den verfügbaren Speicherplatz schnell aufbrauchen, was möglicherweise zu einer Erschöpfung des Speicherplatzes führt und die allgemeine Systemstabilität beeinträchtigt. Um dies zu vermeiden, empfehlen wir die folgenden bewährten Methoden für /var/crash:

• Stellen Sie einen dedizierten Datendatenträger für Absturzabbilder bereit, anstatt sich auf den Betriebssystemdatenträger zu verlassen.
• Größe des dedizierten Datenträgers mindestens gleich dem gesamten physischen Arbeitsspeicher des Systems.
• Binden Sie den dedizierten Datenträger unter /var/crash ein.
• Vermeiden Sie temporäre Datenträger (z. B. /mnt oder /mnt/resource), da sie in Azure nicht persistent sind.

Dieser Artikel enthält Antworten auf einige der häufigsten Fragen zum Azure Linux-Kernel, einschließlich der Auswahl einer Kernelversion, der Verwaltung von Kernelmodulen und dem Exportieren von Kernelabbildern zum Debuggen.

Die ausgewählte Kernelversion ist der aktuelle long-term Support (LTS)-Kernel zum Zeitpunkt der Azure Linux-Hauptversion. Beispielsweise wird Azure Linux 4.0 mit der LTS-Kernelversion 6.18 ausgeliefert. Weitere Informationen finden Sie unter Azure Linux release cadence and lifecycle.

Azure Linux-Kernelversionen folgen dem Format Major.Minor.Patch.Integration-Release.alN, wobei:

• Major.Minor ist die upstream LTS-Kernelversion (z. B. 6.18).
• Patch ist die upstream LTS-Patchnummer von kernel.org.
• Integration ist die interne Integrationsnummer für Updates zusätzlich zur vorgelagerten LTS-Version.
• Release ist die Release-Nummer des RPM-Pakets, die verwendet wird, wenn die RPM-Paketdefinition aktualisiert wird.
• alN gibt die Azure Linux-Version an (z. B. al4 für Azure Linux 4.0).

Sie können die ausgeführte Kernelversion mit dem uname -r Befehl überprüfen.

Ein kdump vmcore ist eine Momentaufnahme des physischen Speichers des Systems zum Zeitpunkt eines Absturzes, und seine Größe kann nahe am gesamten installierten RAM liegen.

In Azure Linux werden vmcore-Dateien standardmäßig auf dem Betriebssystemdatenträger unter /var/crash gespeichert. Das Speichern von vmcore-Dateien dort kann den verfügbaren Speicherplatz schnell aufbrauchen, was möglicherweise zu einer Erschöpfung des Speicherplatzes führt und die allgemeine Systemstabilität beeinträchtigt. Um dies zu vermeiden, empfehlen wir die folgenden bewährten Methoden für /var/crash:

• Stellen Sie einen dedizierten Datendatenträger für Absturzabbilder bereit, anstatt sich auf den Betriebssystemdatenträger zu verlassen.
• Größe des dedizierten Datenträgers mindestens gleich dem gesamten physischen Arbeitsspeicher des Systems.
• Binden Sie den dedizierten Datenträger unter /var/crash ein.
• Vermeiden Sie temporäre Datenträger (z. B. /mnt oder /mnt/resource), da sie in Azure nicht persistent sind.