Rädda PI från krasch?

Min gissning är att SD-kortet är rökt.
Hänt för mig ett par gånger med PI.

Troligen SD-kortet som @PuMaH påpekade.

Har du SD-läsare så prova att stoppa i kortet där och se om du kan kopiera det som behövs.
Om du sedan ska använda ett annat SD-kort (om det var felet) så kan jag rekommendera, att efter installation och justeringar, göra en backup på hela SD-kortet med win32diskimager. När samma problem inträffar igen så kan du snabbt flasha ett nytt kort.

Vill du minimera slitaget på SD-kortet kan du prova göra filsystemet till Read-Only.

Pi är ökända för att skriva asmycket till SD-kort.

@GLaDER: Och hur är det nåt som uppstår pga. hårdvaran? Och dessutom försvinner mellan generationerna?

Kortet behöver inte vara rökt, drar man bara ur strömmen så kan den vägra boota igen då en "dirty-bit" (vad det nu heter på svenska) är satt på boot-partitionen. I linux rensas det lätt genom att köra fsck.vfat, men ingen aning om hur det görs i windows. Så länge som den är satt så kommer pi:n inte boota.

Edit: Börjar minnas. montera kortet i datorn och kör chkdsk. Kanske chkdsk /f?

Det kan vara idé att lägga in "fsck.repair=yes" i cmdline.txt i /boot/.

@thu de tidigare releaserna av Raspbian skrev onödigt mycket tmp och log till SD-kortet vilket dödade dom ganska snabbt. Detta är betydligt bättre nuförtiden, och vill man inte ha några tmp eller log skrivna alls till SD-kort/eMMC så kör Read-Only på filsystemet och montera /tmp/ och log i RAM.

@Opatagio: Pi != raspbian

Självklart är det så, därav jag uttryckligen skrev Raspbian så att mitt inlägg inte skulle förvirra andra i onödan.

Verkar ju vara oklart vad som händer om det är fel, om dessa fixas automatiskt så är det inte är ett problem om det bara skulle vara att boot-partitionen är flaggad som inte korrekt avmonterad, men skulle nog vara ett större problem om det är en partition med data.

Och fixas inte dessa automatiskt, så innebär det ju att man får en prompt för att ordna dessa och om pi:n är headless så kommer det ju fungera lika bra som om man inte har det tillaggt, dvs inte alls...

Fått intrycket att både forcefsck och fsck.repair i cmdline.txt gäller för / och inte begränsat till /boot/. Och med "yes" så kommer föreslagna åtgärder köras automatiskt.

Jag skulle kunna se om jag kan provocera fram detta, har ett antal liggandes i utvärderingssyfte.

@Irre: Felaktig microkod vart? Och vad för defekt i f2fs syftar du på?

Först, eftersom jag glömde, tack för tipset Skall lägga till det i min mobila pi som används för datainsamling

Hittade det här:

Så, det verkar som fsck.repair=preen är vad som skulle fungera bäst för mig.

Varför skulle grafikkretsen vara inblandad i hanteringen av SD-kortet? Och vad är isåfall felet? Och hur påverkar detta SD-kortet?
På vilket sätt påverkar den påstådda filsystemsinstabiliteten SD-kortet?

Hemligstämpling är förresten nåt regeringar pysslar med, inte kretstillverkare. De kanske vill hålla koden för sig själva, men den är inte hemligstämplad.

@Irre: Det där hade ju noll och intet att göra med mina frågor eller ditt ursprungliga påstående. Jag är väl medveten om att all firmware inte är opensource.

@Irre: Ursäkta att jag går hårt åt påståendet. Jag försöker bara gå till botten med vad jag uppfattar som kvalificerat svammel. Ett tag funderade jag på om det var nåt subtilt trollande (Irre = tyska för galen, missuppfattning, ~vilseledande). Det finns ju risk att felaktig uppfattning om orsakerna sprider sig och folk börjar byta ut fungerande prylar för att de tror på att det skulle vara nåt i själva hårdvaran som förstör SD-kort.

De har också problem med UEFI som finns i ~varenda moderkort. Microkoden till valfri AMD/Intel-CPU är inte heller opensource.

Det som plågat RPI 1 och 2 är att SD-minnena brickas lätt om strömmatningen inte har varit stabil, pga. långa sladdar och spänningsfall pga. av detta, dåligt med strömmarginaler i använda 5V adapter eller inte har god reglering vid varierande last. RPI3 och RPi4 har man förbättrat det med egen regulator för själva SD-minnena.

Att också använda bättre kvalitets SD-minne som Sandisk ultra och Sandisk extrem eller samsung EVO+ - dom är de snabbare än idag vid 4K-skrivningar då SD-minnen och USB-stickor är extremt dåliga på detta i jämförelse med tex. SSD-minne även om det går via USB. Är det höga krav på driftsäkerhet så får man titta på 'industrial grade' SD-minne med ruggad kontroller och minnen av SLC eller MLC-typ, men de är inte billiga då tex. 16 GB SD-minne av den kvaliteten kostar runt 3000:-

SD-minne är byggd för rätt stora blockskrivningar på ganska många MB i stöten (läs lagra bilder från en kamera) och tillverkarna räknar kallt att en SD-minne får sin diskyta omskriven max 5-10 ggr i sin livstid. Med 4K-skrivningar (minsta storleken som en filsystem skriver med) hackande tusentals på samma ställe (inods-uppdateringar, journalskrivning i ext4) så är det inte säkert att den rätt primitiva wearlevlingen jobbar så bra eller inte alls i billigare SD-minne och man får ganska snabbt att sektorer börja läsas fel (SD-minne har inte alls samma felrättning och och om det misslyckad, blockering av korrupta sektorer som SSD har - man glömde den detaljen då när SD-standarden skrevs då man hade filosofin att SD-minne aldrig gjorde fel - och det kanske stämde med SLC-minnen för hundra år sedan, men inte med dagens TLC-minne - därför kan man läsa korrupta sektorer ur SD-minne utan något skulle indikera att det är felaktingt medans på SSD/NVMe så får man IO-error.)

Checksummande filsystem som BTRFS är inget dåligt val alls då reagerar vid felläsning (ger IO-error... precis som SSD) samt sprider ut sitt skrivande på helt annat sätt än ext4 mha. COW-filosofin. dvs. alla ändringar görs alltid på nya sektorer och man modifierar inte de redan skrivna - och det gäller också metadatat som inod-listor. - det gör att diskytan på SSD/USB-stickan kommer att nyttjas fullt ut innan den börja skriva på de äldsta lediga sektorerna igen.

BTRFS har också funktioner att kunna spara all sin data i 'DUP' dvs. i 2 kopior på olika ställen i SD-minnet vilket gör att om den ena läses fel (vilket kollas av checksumman) så kan den använda kopian för att ge programmen rätt data samt rätta den fellästa sektorn (går automagiskt). Ändra raid-läge gör man med 'balance' och görs under drift/användande och man kan konvertera tillbaka igen om man inte gillade att filerna tar dubbelt med plats som när man kör i single-disk eller RAID-0.

Detta går också att göra RAID1 mellan en SD-minne och en USB-sticka av samma storlek. Dock kan man inte garantera att starten fungerar i RAID1 vid felaktighet på någon av media då detta är styrd av uboot-rutinen på RPI vilka enheter den provar i startfasen och var den gör ifall den inte kan läsa endera av lagringen (man har samma problem med vanliga BIOS)

vilka SD-minnen då??

Tillverkare kan lämna oändlig garanti om det för dem kostar noll och ingenting att skicka ut en ny till en klagande kund även om det sker 10 ggr i rad - dvs. de kan vara gjord av lägsta 'tiern' av NAND-flash.

Det är totalt ointressant med garantier för använda SD-minnet om en utrustning med SD-minne sitter oåtkommligt och ett byte kosta stora pengar eller att man förlorat värdefull data när SD-minnet havererat (och den delen står inte garantin för)

- I det läget vill man ha minne som är bevisat och man vet både av sin egna erfarenhet/tester och andras erfarenhet att det är pålitligt! _och_ är likadan om 3 år att köpa!!! styckpriset är i det läget mindre intressant om man vet att det man stoppar in i utrustningen faktiskt håller...

Det är ett problem idag när tillverkarna av SD-minne och USB-stickor byter innehåll lika ofta som folk byter skjorta...

Jag har 6-7 olika Cruzer blade från Sandisk köpta vid olika tillfällen med samma kapsling - ingen av dem har samma uppsättning kontroller eller Nandflash i sig - drar olika mycket ström och är olika snabba både vid läsning och skrivning - innehållet är olika gång till gång...