Opstartproblemen met virtuele Linux-machines oplossen vanwege een volledige besturingssysteemschijf

Van toepassing op: ✔️ Virtuele Linux-machines

Onder bepaalde omstandigheden en configuraties kan een volledige besturingssysteemschijf (OS) leiden tot opstartproblemen met de 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 wordt niet opgestart.

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.
Diagnostische gegevens over opstarten die zijn 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 op elk moment een reddings-VM nodig is.
Machtigingen voor het maken, loskoppelen en koppelen van schijven voor het geval het wisselen van schijven vereist is.

Notitie

Niet alle vereisten zijn van toepassing op de volgende scenario's.

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

Veel beveiligingsbeveiligingsprocedures kunnen leiden tot problemen bij het onderhouden 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 de beveiligingscontroleservice gestart... bericht wordt weergegeven. Dit bericht geeft niet aan dat de service is gestart. In plaats daarvan wordt de VIRTUELE machine onmiddellijk overgezet om af te sluiten en wordt een bericht 'Uitschakelen' weergegeven. Als het systeem wordt uitgevoerd en onverwacht wordt afgesloten, kan in de seriële console een ordelijk afsluitproces worden weergegeven dat eindigt op een bericht 'Uitschakelen'. 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. Controleer vervolgens het schijfgebruik met behulp van het df opdrachtregelprogramma en controleer of de schijf met de map /var/log/audit bijna 100% is.
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

Notitie

Als deze oplossing niet werkt of niet geschikt is voor uw omgeving, gaat u naar de sectie Oplossing .

Als de gecontroleerde configuratie ervoor zorgt dat het systeem wordt afgesloten bij fouten in het auditlogboek, kan de HALT VIRTUELE machine tijdelijk worden opgestart naar het volledige besturingssysteem voor herstel.

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

Maak een momentopname van de besturingssysteemschijf om een herstelstatus te bieden.
Krijg toegang tot het configuratiebestand met behulp van az vm repair commands, een handmatige herstel-VM of de modus voor één gebruiker.
Noteer de huidige configuratie, omdat er mogelijk geen ruimte beschikbaar is om een back-up te maken van het bestand op de virtuele machine.
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 zijnIGNORE, of andere waarden die worden vermeld op de Linux-pagina SUSPEND voor het man, die de juiste parameters geeft voor de versies van software die in de VIRTUELE machine 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 met de map /var/log/audit moet een goed eerste doel 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 grootte van de bewerking mislukken omdat voor het proces enige vrije ruimte is vereist om het bestandssysteem uit te breiden. 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 zijn geretourneerd, zoekt u naar andere regels met de tekst "[Errno 28] Geen spatie links op apparaat" of soortgelijke "geen spatie" berichten.

Om dit probleem op te lossen, wist u overbodige gegevens om een kleine hoeveelheid schijfruimte vrij te maken en vouwt u vervolgens het bestandssysteem uit.

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 vouwt u de schijven uit.

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: Overbodige gegevens wissen

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.
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 naar behoefte aan meerdere megabytes of gigabytes aan om de meest effectieve bestanden te vinden die u wilt verwijderen.
Verwijder alle bestanden die kunnen worden geïdentificeerd als onnodig, zoals oude logboeken, vergeten back-ups en vergelijkbare bestanden.
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 Opstartfouten van virtuele Azure Linux-machines oplossen voor verdere probleemoplossing.

Feedback

Is deze pagina nuttig?

Last updated on 2025-09-15