Problemen met het opstarten van Ubuntu, Mint en Kali oplossen met de Initramfs-prompt in BusyBox

Heb je al ontdekt waarom Linux soms vastloopt tijdens het opstarten? Als je systeem vastloopt in een busybox -prompt bij initramfs, is de kans groot dat er een probleem is met de schijf of het bestandssysteem. Dat is behoorlijk irritant, vooral als je al hebt geprobeerd opnieuw op te starten of basiscontroles hebt uitgevoerd en nog steeds vastloopt. Deze handleiding laat je zien hoe je dit in de praktijk kunt oplossen, zoals het repareren van een beschadigde superblock of het corrigeren van je fstab, zodat je hopelijk weer aan de slag kunt met Linux zonder je haren uit je hoofd te trekken.

Hoe je veelvoorkomende opstartproblemen met Linux kunt oplossen wanneer het vastloopt in BusyBox.

Een beschadigd superblok repareren met fsck

Als Linux vastloopt in een busybox-prompt met een bericht over een beschadigde superblock, is dat waarschijnlijk precies wat het is: een corrupte kopie van de superblock op je schijf. Dit gebeurt meestal als het systeem niet correct is afgesloten, of als een stroomstoring belangrijke informatie heeft vernietigd. Omdat de superblock essentiële informatie over het bestandssysteem bevat, kan het herstellen ervan je hele installatie redden.

Om te beginnen moet je opstarten vanaf een Live CD, een hersteldisk of een USB-stick met Linux geïnstalleerd. Zodra je in deze omgeving bent, open je de terminal. Het doel is om je Linux-partitie te identificeren en vervolgens een commando uit te voeren om back-up-superblocks te vinden en te proberen deze te repareren.

• Geef een lijst van uw schijven en volumes om de juiste partitie te vinden: # sudo fdisk -l | grep Linux. In sommige configuraties kan de uitvoer bijvoorbeeld iets zijn als /dev/vda2. Houd dit in gedachten, want u hebt het nodig in de volgende stappen.
• Controleer beschikbare superblocks met: # sudo dumpe2fs /dev/vda2 | grep superblock. Dit geeft een lijst met locaties voor back-up superblocks weer. Voor de meeste ext4-bestandssystemen zie je bijvoorbeeld 98304 of 2064 als back-upopties.

Kies een back-up-superblock (niet de primaire).Meestal werkt 98304 goed. Voer vervolgens het volgende commando uit: # sudo fsck -b 98304 /dev/vda2 -y. Dit commando geeft fsck de opdracht om het bestandssysteem te repareren met behulp van die back-up-superblock.

Als je een foutmelding ziet zoals “/dev/vda2 is gemount”, ontkoppel het dan eerst: # sudo umount /dev/vda2. Soms wordt het als gemount weergegeven, zelfs als het niet gemount is, dus wees voorzichtig. Op sommige machines is na deze magische oplossing mogelijk een herstart nodig om het gerepareerde bestandssysteem soepel te laden.

Als de controle succesvol is afgerond, ziet u berichten zoals:

* FILE SYSTEM WAS MODIFIED *

Vervolgens wordt een lijst met opgeloste fouten weergegeven. Ontkoppel daarna de schijf volledig en herstart de computer. Hopelijk start het systeem nu normaal op.

Het afhandelen van de fsck-fout “Onverwachte inconsistentie”.

Soms, wanneer busybox verschijnt, wordt er een melding weergegeven /dev/sda1: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY. Dat is een vrij duidelijke aanwijzing: je bestandssysteem is niet schoon. Meestal hoef # fsck /dev/sda1 -yje alleen maar het volgende commando in de opdrachtprompt uit te voeren:.Als de opdrachtprompt daarna weer verschijnt, is dat een goed teken. Herstart de computer en als alles goed gaat, zou Linux direct moeten opstarten.

Ik weet niet zeker waarom het werkt, maar in sommige gevallen helpt het om dat in initramfs te doen om kleine corruptie te herstellen die een volledige opstart verhindert.

Het probleem met /dev/volume bestaat niet.

Dit probleem treedt op wanneer /etc/fstab verwijst naar een volume of UUID die niet overeenkomt met de werkelijkheid. Dit gebeurt meestal als je vanaf een USB-stick hebt geïnstalleerd en de UUID van het apparaat is gewijzigd of verkeerd geconfigureerd.

Start op in de herstelmodus of live Linux. Koppel de verdachte schijf ergens aan: # sudo mount /dev/sda2 /mnt. Bewerk vervolgens het bestand /etc/fstab op die locatie:

# sudo nano /mnt/etc/fstab

Zoek de regel die verwijst naar /dev/sda1(of een ander volume) en vervang deze door de juiste UUID, die je kunt vinden met `sudo blkid`. Je regel zou er als volgt uit moeten zien:

UUID=36cce3d5-cbdb-46f4-adbf-3f9aaa01d729 / ext4 errors=remount-rw 0 1

Opslaan, ontkoppelen, opnieuw opstarten…Hopelijk klaagt het systeem dan niet meer over ontbrekende apparaten.

In geval van hardwareproblemen: het corrigeren van een verkeerde SATA-poortnummering of UUID-match.

Op sommige ongebruikelijke moederborden of bij bepaalde hardwareconfiguraties krijgen SATA-poorten vreemde nummers of veranderen ze, waardoor Linux denkt dat je root-apparaat niet meer bestaat. Om dit op te lossen, moet je mogelijk je grub.cfg bewerken.

Start op in de noodmodus of gebruik een Live CD en open vervolgens het bestand /boot/grub/grub.cfgom het te bewerken. Zoek de regel met de kernelopdracht (waarschijnlijk staat daar root=/dev/sda1 ).Wijzig deze regel zodat in plaats van /dev/sda1 de UUID wordt gebruikt, zoals hieronder weergegeven:

linux /boot/vmlinuz-...root=UUID=36cce3d5-cbdb-46f4-adbf-3f9aaa01d729 ro quiet elevator=noop fsck.repair=yes

Deze overstap naar UUID zorgt ervoor dat Linux, zelfs als de SATA-poort verandert of de volgorde van de schijven wijzigt, bij het opstarten nog steeds de juiste schijf vindt. Het is geen perfecte oplossing, maar het is een veelgebruikte workaround die al veel mensen heeft behoed voor een complete opstartfout.

En ja, natuurlijk maakt Linux de dingen ingewikkelder dan nodig, maar het oplossen van deze problemen is niet onmogelijk – alleen vervelend.

Samenvatting

• Start op vanaf live media om het bestandssysteem te herstellen of UUID-problemen op te lossen.
• Gebruik dit dumpe2fsom back-up superblocks te vinden en voer vervolgens bewerkingen uit fsckop de superblocks.
• Controleer en corrigeer /etc/fstab met de juiste UUID’s om opstartfouten te voorkomen.
• Wijzig GRUB om van apparaatpaden naar UUID’s over te schakelen als hardwareproblemen zich voordoen.

Samenvatting

De meeste van deze problemen komen voort uit beschadiging van het bestandssysteem of verkeerd geconfigureerde apparaatverwijzingen. Het oplossen ervan vereist een combinatie van schijfcontroles, het bewerken van configuratiebestanden en soms gewoon hopen dat de hardware zich goed gedraagt. Als de ene oplossing niet werkt, kan een andere methode wellicht wel uitkomst bieden. Hopelijk bespaart dit iemand urenlang gepieker en frustratie. Let op: maak altijd een back-up van je gegevens voordat je met schijfprogramma’s aan de slag gaat, indien mogelijk – anders kan het misgaan.