Voor iemand die niet echt in de linux systeembeheer of -architectuur wereld zit is dit voor mij een redelijk complex probleem, ik kan simpelweg niet overzien wat er allemaal gebeurt. Ook wordt het analyseren van het daadwerkelijk probleem hierdoor bemoeilijkt. Wat ik wel kan doen is beschrijven wat er gebeurt.
Hardware
Raspberry Pi 3 Model B (revisie a02082)
Official Raspberry Pi 3 Power Supply
Randapparatuur (gekoppeld aan de RPi)
USB 3.0 - 22 pins SATA aansluiting voor 2.5" harde schijven
(met hieraan) Kingston SUV400S37 120G
USB toetsenbord
USB muis (wordt niet gebruikt, ik boot in shell, niet in de GUI)
monitor (staat meestal uit)
Software
Raspbian versie 9 (stretch), handmatige update van jessie (don't ask lol, ik had beter gewoon een nieuwe image kunnen installeren)
Symptomen
Na verloop van tijd loopt het systeem vast, deze is niet langer extern toegankelijk, de webserver reageert ook niet meer. Als ik achter de RPi zit dan worden vele varianten van de volgende melding uitgespuugd:
EXT4-fs error (device sda2): ext4_find_entry:1436: inode #131094: comm nmbd: reading directory lblock 0Commando's worden ook niet meer herkend. Het enige wat ik op dat moment kan doen is de voeding eruit trekken en rebooten. De eerstvolgende reboot faalt ook altijd (een component tijdens het opstarten rapporteert [FAILURE]), ik heb getracht een manier te vinden om te achterhalen wat dit onderdeel is, maar de machine reboot meteen (misschien een boot_delay inbouwen?). Ook het raadplegen van boot- en systeemlogs na de tweede reboot bevat geen informatie (meer?) over de vorige niet-succesvolle boot.
Analyse
Ik heb echt veel gezocht op het internet, maar heb de oplossing nog niet gevonden. Er worden ook legio potentiële oorzaken aangedragen, met allerlei complexe linuxcommando's c.q. toverformules of configuratieregels die je ergens in de krochten van het systeem moet aanpassen... Een greep van oorzaken:
- voedingsprobleem (tijdens piekbelasting)
ik doe geen aannames over wat het is, want dat weet ik simpelweg niet, maar deze lijkt mij onwaarschijnlijk omdat er geen sprake is van piekbelasting, en hij knalt er altijd redelijk consequent uit na 10-20 dagen (tenzij er een loodzware cron is die tweewekelijks draait?)
- slijtage SSD
deze lijkt mij ook onwaarschijnlijk, de SSD is/was nieuw, en de rest van de tijd is er geen enkel probleem
- complexe technische oorzaak?
had ergens gelezen dat er iets was met niet om kunnen gaan met IPv6 adressen, of een of andere bug in de aansturing van IPv4, maar ik kan hier echt geen waardeoordeel over geven, ik heb geloof ik wel draadloos netwerk uitgeschakeld op mijn RPi omdat ik deze toch niet gebruik
Suggesties?
Misschien is de huidige opzet (SSD met SATA koppelstuk) niet echt ideaal en moet ik denken over een SSD met externe voeding? Of wellicht de "officiële" standaard adapter van de RPi vervangen, omdat daar ook nog wel wat berichtgeving over is dat deze redelijk bagger is? Wel zijn er een hoop webtutorials (waarvan de kwaliteit nogal eens verschilt ;)) die zo een SSD aan hun RPi fietsen ogenschijnlijk zonder enig probleem.
Ook kan ik niet goed controleren of er iets met de SSD mis is (ik kan fsck namelijk niet uitvoeren op een gemounte (systeem)schijf?).
Ik heb wel een beetje het idee dat ik bij alles wat ik probeer een beetje buitenspel wordt gezet :p. Als iemand enig idee heeft of iets soortgelijks heeft meegemaakt, I'm all ears :).
On a sidenote: als ik het apparaat reboot (sudo reboot), start deze nooit opnieuw op als ik dit commando remote aanroep (via SSH), en... soms (?!) als ik dat rechtstreeks vanaf de prompt doe. Dit kan ik ook niet helemaal plaatsen. Misschien heeft dit er iets mee te maken, misschien helemaal niets. Ik heb begrepen dat de RPi geen power saving heeft, deze is altijd op 100% vermogen actief maar wellicht is dat ondertussen veranderd?
