Opstartproblemen met Azure virtuele Linux-machine oplossen vanwege een volledige besturingssysteemschijf

Van toepassing op: ✔️ Virtuele Linux-machines

Overzicht

Onder bepaalde omstandigheden en configuraties kan een volledige besturingssysteemschijf (OS) leiden tot opstartproblemen met Azure virtuele Linux-machine (VM). Dit artikel bevat enkele oorzaken en oplossingen voor de opstartproblemen.

Symptomen

Als tijdens normale systeembewerkingen de besturingssysteemschijf of kritieke systeempartities vol raken, kunnen de volgende problemen optreden:

• Een virtuele machine wordt onverwacht afgesloten.
• Een virtuele machine start niet succesvol op.

Voorwaarden

Om de opstartproblemen op te lossen en systeemreparaties te voltooien, moet aan de volgende vereisten worden voldaan:

• Machtigingen voor het maken van een momentopname van een schijf of het gebruik van enkele hulpprogramma's voor back-up en herstel.

  In dit artikel worden gegevens of schijven gewijzigd, zodat de mogelijkheid om de VIRTUELE machine terug te keren naar een eerdere status een essentieel onderdeel is van veilig systeembeheer.

• Opstartdiagnostiek die is ingeschakeld en geconfigureerd.

  Als u deze configuratie hebt ingesteld, kunt u de opslag van het consolelogboek en de interactie met de seriële consoleinterface van de VIRTUELE machine in de toekomst bekijken.

• Machtigingen voor het maken van een virtuele machine voor het geval er wanneer dan ook een reddings-VM nodig is.

• Machtigingen voor het maken, loskoppelen en koppelen van schijven voor het geval het wisselen van schijven vereist is.

Scenario 1: VM wordt onverwacht afgesloten en kan niet worden opgestart

Veel beveiligingsversterkende praktijken kunnen leiden tot problemen met het onderhoud van systemen. Als er een fout optreedt bij het schrijven naar het auditlogboek, vereist één algemene configuratie dat het systeem onmiddellijk wordt afgesloten. Voer de volgende acties uit om te controleren of dit scenario de reden is voor het afsluiten van een systeem:

• Controleer de systeemuitschakelingsberichten in het seriële consolelogboek .

  Als het systeem wordt opgestart, wordt een bericht "Starting Security Auditing Service…" weergegeven. Dit bericht geeft niet aan dat de service is gestart. In plaats daarvan wordt de virtuele machine onmiddellijk overgeschakeld naar uitschakeling en wordt een bericht 'Afsluiten' weergegeven. Als het systeem draait en onverwacht wordt uitgeschakeld, kan op de seriële console een ordelijk afsluitproces worden weergegeven dat eindigt met een bericht 'Afsluiten'. Bekijk de volgende schermopnamen als voorbeeld:

  

  

• Koppel de besturingssysteemschijf met behulp van az vm-herstelopdrachten , een handmatige herstel-VM of de modus voor één gebruiker. Gebruik vervolgens het df opdrachtregelprogramma om het schijfgebruik te onderzoeken en kijk of de schijf met de directory /var/log/audit bijna 100% benutting bereikt.

• Open het bestandssysteem van het besturingssysteem met behulp van az vm-herstelopdrachten , een handmatige herstel-VM of de modus voor één gebruiker en controleer of het bestand /etc/audit/auditd.conf de volgende configuraties bevat:

  [root@linux /]# grep action /etc/audit/auditd.conf
  admin_space_left_action = HALT
  disk_full_action = HALT
  disk_error_action = HALT
  

Oplossing: HALT-configuratie tijdelijk uitschakelen

Als de auditd-configuratie ertoe leidt dat het systeem wordt afgesloten bij fouten in de auditlogs, kan de VM tijdelijk worden opgestart naar het volledige besturingssysteem voor herstel.

Als u dit veelvoorkomende gecontroleerde probleem en verschillende andere veelvoorkomende problemen wilt oplossen, voert u de extensie az vm repair automatisch uit in de Azure CLI met behulp van de actie auditd in het hulpprogramma Azure Linux Automatic Repair (ALAR). Voer de volgende stappen uit om dezelfde procedure handmatig uit te voeren:

1. Maak een momentopname van de besturingssysteemschijf om een herstelstatus te bieden.

2. Krijg toegang tot het configuratiebestand met behulp van az vm repair commands, een handmatige herstel-VM of de modus voor één gebruiker.

3. Noteer de huidige configuratie, omdat er mogelijk geen ruimte beschikbaar is om een back-up te maken van het bestand op de virtuele machine.

4. Wijzig de vorige configuraties in het bestand /etc/auditd.conf van HALT naar een andere geldige waarde, behalve SINGLE. In dit scenario kunnen de waarden zijn IGNORE, SUSPEND of andere waarden die worden vermeld op de Linux man pagina voor het auditd.conf bestand, dat de juiste parameters geeft voor de softwareversies die in de VM worden gebruikt.

   [root@linux /]# grep action /etc/audit/auditd.conf
   admin_space_left_action = SUSPEND
   disk_full_action = SUSPEND
   disk_error_action = SUSPEND
   

• Als u een herstel-VM gebruikt, volgt u de instructies in Ontkoppelen en loskoppelen van de oorspronkelijke virtuele harde schijf om de besturingssysteemschijf terug te zetten naar de problematische VM en probeert u de VIRTUELE machine normaal op te starten. Als u de modus voor één gebruiker gebruikt, sluit u af en start u de VM opnieuw op.

• Zodra de virtuele machine volledig is opgestart, bladert u door het bestandssysteem en maakt u ruimte vrij met opdrachtregelprogramma's zoals df en du. Ongeveer 10% van het bestandssysteem dat de /var/log/audit directory bevat zou een goed initieel doel kunnen zijn.

Zodra het probleem is opgelost, keert u de inhoud in het bestand /etc/audit/auditd.conf terug naar de oorspronkelijke waarden en start u de VM opnieuw op.

Scenario 2: de grootte van de VM-schijf wordt gewijzigd in Azure, maar het besturingssysteem kan niet worden gewijzigd en de VM wordt niet volledig opgestart

Nadat een volledige schijf is geïdentificeerd en de VM is afgesloten om het formaat van de besturingssysteemschijf te wijzigen, kan de vm mogelijk niet worden opgestart. Dit scenario kan verwarrend zijn voor sommige distributies waarbij het besturingssysteem de grootte van het hoofdbestandssysteem (/) automatisch probeert te wijzigen bij het opnieuw opstarten. Als de schijf vol is, kan de bewerking voor het wijzigen van de grootte mislukken omdat deze bewerking wat vrije ruimte vereist om het bestandssysteem te vergroten. Als u geen vrije ruimte hebt, kan cloud-init mislukken en wordt de vm niet opgestart.

Als u dit probleem wilt identificeren, bekijkt u de opstartlogboeken in de seriële console en controleert u of regels die lijken op de volgende tekst aanwezig zijn:

[   15.384699] cloud-init[1142]: OSError: [Errno 28] No space left on device
[   15.384742] cloud-init[1142]: Original exception was:
[   15.384784] cloud-init[1142]: OSError: [Errno 28] No space left on device

Omdat de specifieke cloud-init-berichten mogelijk niet het meest zichtbare bericht is geretourneerd, bekijk andere regels met de tekst "[Errno 28] Geen ruimte over op het apparaat" of soortgelijke "geen ruimte" berichten.

Om dit probleem op te lossen, wis overbodige gegevens om een kleine hoeveelheid schijfruimte vrij te maken en vergroot vervolgens het bestandssysteem.

Scenario 3: VM-opstartbewerkingen, maar is niet toegankelijk vanwege servicefouten

Een VM die volledig lijkt te worden opgestart, kan de volgende problemen hebben:

• Serviceproblemen treden op tijdens het opstarten.
• De Azure-agent wordt mogelijk niet beschikbaar weergegeven.
• Verbindingen met de VIRTUELE machine kunnen mislukken.
• De VIRTUELE machine lijkt mogelijk offline te zijn volgens toepassingen.

Tijdens het opstarten geven meerdere berichten zoals "[Errno 28] Geen ruimte over op apparaat" of andere typen berichten aangeven dat het hoofdbestandssysteem vol is.

Als een VM wordt opgestart maar niet beschikbaar lijkt, controleert u het seriële logboek in de diagnostische opstartgegevens om de opstartberichten weer te geven of gebruikt u de seriële console om te communiceren met de virtuele machine. Als de ruimte onvoldoende is, wist u overbodige gegevens om ruimte vrij te maken of vergroot u de schijven.

Als het consolelogboek veel berichten bevat met de mededeling 'ERROR ExtHandler /proc/net/route bevat geen routes', kan een volledige besturingssysteemschijf ook de oorzaak zijn, omdat de netwerkservices niet volledig kunnen worden gestart.

Oplossing

De volgende oplossingen zijn van toepassing op een van de vorige scenario's.

Oplossing 1: Opschonen van overbodige gegevens

1. Krijg toegang tot de besturingssysteemschijf en -partities met behulp van az vm repair-opdrachten , een handmatige herstel-VM of een modus voor één gebruiker, omdat het systeem niet normaal opstart.

2. Identificeer grote bestanden en mappen met behulp van standaard Linux-hulpprogramma's en -opdrachten:

   • du -ks /* | sort -n - Zoek de meeste ruimte-verbruikende bestanden of mappen op een locatie. Herhaal dit in de grootste gerapporteerde map totdat bepaalde grote gegevens zijn ontdekt.

   • ls -altSr /var/log - Vermeld de inhoud van een map, gesorteerd op grootte, in oplopende volgorde.

   • find / -size +500M -exec ls -alFh {} \; - Grote afzonderlijke bestanden zoeken. Pas de 500M waarde zo nodig aan naar meerdere megabytes of gigabytes, om de meest geschikte bestanden te verwijderen.

3. Verwijder alle bestanden die kunnen worden geïdentificeerd als onnodig, zoals oude logboeken, vergeten back-ups en vergelijkbare bestanden.

4. Zodra een geschikte hoeveelheid ruimte is gewist, richt u zich op ongeveer 10% vrije schijf en start u het systeem opnieuw op.

Oplossing 2: Bestandssysteem van besturingssysteem uitbreiden

Als er geen gegevens uit het bestandssysteem van het besturingssysteem kunnen worden gewist, raden we u aan de schijf met de kritieke besturingssysteemvolumes uit te breiden. Zie Virtuele harde schijven uitvouwen op een Virtuele Linux-VM voor meer informatie.

Volgende stappen

Als de specifieke opstartfout geen Linux-opstartprobleem is vanwege een volledige besturingssysteemschijf, raadpleegt u Roubleshoot Azure opstartfouten voor virtuele Linux-machines voor verdere probleemoplossing.