Rädda PI från krasch?

Permalänk

Rädda PI från krasch?

Använder PI för Pihole och som kontroller för Ubiqutis AP. Om jag behöver konfa så fjärrar jag in med VNC.

När jag körde igång VNC i förra veckan så anslöt den men skärmen var svart. Jag drog ur strömkabeln ur PI och nu startar den inte alls.

Antar att något blivit korrupt? Går det att rädda eller är det ominstallation som gäller?

Permalänk
Mattecoach

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

Permalänk
Medlem

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.

Permalänk
Medlem

Första gen pi var usla, den förstörde ett SD-kort som sedan inte gick att formatera ens på en annan dator. Senare blev det bättre. Och med btrfs som filsystem har inget gått snett. Ens efter strömavbrott.

Skickades från m.sweclockers.com

Permalänk
Medlem
Skrivet av Irre:

Första gen pi var usla, den förstörde ett SD-kort som sedan inte gick att formatera ens på en annan dator. Senare blev det bättre. Och med btrfs som filsystem har inget gått snett. Ens efter strömavbrott.

Och hur menar du att själva hårdvaran skulle resultera i att SD-kortet havererar?

Permalänk
Medlem
Skrivet av thu:

Och hur menar du att själva hårdvaran skulle resultera i att SD-kortet havererar?

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

Permalänk
Medlem

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

Permalänk
Medlem

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?

Permalänk
Medlem

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.

Permalänk
Medlem

@Opatagio: Pi != raspbian

Permalänk
Medlem
Skrivet av thu:

@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.

Permalänk
Medlem
Skrivet av Opatagio:

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

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...

Permalänk
Medlem
Skrivet av thu:

Och hur menar du att själva hårdvaran skulle resultera i att SD-kortet havererar?

Felaktig mikrokod kombinerat med det defekta filsystemet f2fs!

Skickades från m.sweclockers.com

Permalänk
Medlem
Skrivet av filbunke:

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.

Permalänk
Medlem

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

Permalänk
Medlem
Skrivet av Opatagio:

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.

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:

Citat:

fsck.mode=

One of "auto", "force", "skip". Controls the mode of operation. The default is "auto", and ensures that file system checks are done when the file system checker deems them necessary. "force" unconditionally results in full file system checks. "skip" skips any file system checks.

fsck.repair=

One of "preen", "yes", "no". Controls the mode of operation. The default is "preen", and will automatically repair problems that can be safely fixed. "yes " will answer yes to all questions by fsck and "no" will answer no to all questions.

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

Permalänk
Medlem
Skrivet av thu:

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

Filsystemet släpptes långt innan det var stabilt. Microkod = hemligstämplad dold kod som ligger i grafikkretsen, som behövs för att kunna läsa SD och överhuvud boota. Detta är inget öppet system, tyvärr.

Skickades från m.sweclockers.com

Permalänk
Medlem
Skrivet av Irre:

Filsystemet släpptes långt innan det var stabilt. Microkod = hemligstämplad dold kod som ligger i grafikkretsen, som behövs för att kunna läsa SD och överhuvud boota. Detta är inget öppet system, tyvärr.

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.

Permalänk
Medlem
Skrivet av thu:

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.

Har man Linux så finns det krav på öppen källkod. Det följer de inte. Mycket hemlig dold kod ligger i grafikkretsen. Ibland har Trump rätt även om han oftast är helt fel ute. Teknik och kod stjäls ganska vilt och tyvärr ställs inte några hårda krav på fabrikanterna.

Permalänk
Medlem

@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.

Permalänk
Medlem

@thu: Ursäkta att jag försökte hjälpa till. Jag har erfarenhet av flera olika RpI och de problem som jag råkade ut för när SD-korten lade av.
Edit: Eftersom stor del av viktig kod är dold, så har de som utvecklar Linux (Och även Android) stora problem med all ARM-arkitektur (läs: telefoner och RpI mm).

Permalänk
Medlem

@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.

Permalänk

Jag kör en USB sticka, ej SDkort.

Faktum är att exakt samma fenomen har hänt en gång innan för några månader sedan, dvs jag var tvungen att rycka kabeln då VNC inte fungerade. Jag bet i det sura då och ominstallerade allt.

Skulle man kunna kolla med chkdsk i windows eller måste det vara linuxmiljö? Är det isåfall från dosprompten eller finns program att kolla att filstruktur etc är ok?

Permalänk
Medlem
Skrivet av bluetrain:

Jag kör en USB sticka, ej SDkort.

Faktum är att exakt samma fenomen har hänt en gång innan för några månader sedan, dvs jag var tvungen att rycka kabeln då VNC inte fungerade. Jag bet i det sura då och ominstallerade allt.

Skulle man kunna kolla med chkdsk i windows eller måste det vara linuxmiljö? Är det isåfall från dosprompten eller finns program att kolla att filstruktur etc är ok?

Det du kan kolla från Windows är partition ett. I en av mina rpi ser det ut så här. Efter uppdateringar har inga SD-kort förstörts och som sagt filsystemet btrfs är bra. På extern disk blir "Device" /dev/sdaX någonting. Med imagebackup behöver inget installeras om. Se nedan.

fdisk -l

Device Boot Start End Sectors Size Id Type
/dev/mmcblk0p1 * 2048 141311 139264 68M b W95 FAT32
/dev/mmcblk0p2 141312 30613503 30472192 14.5G 83 Linux
/dev/mmcblk0p3 30613504 31116287 502784 245.5M 82 Linux swap / Solaris

Skaffa en usbsticka med linux så kan du testa filsystemen och även köra backup/restore. I mitt fall backup:

dd if=/dev/mmcblk0p2 | gzip > backup.gz

Och restore lika enkelt:

zcat backup.gz | dd of=/dev/mmcblk0p2

Permalänk

Tack, jag ska prova detta.

Är ju lite dumt att behöva dra kabel varje gång man inte kommer åt och kan göra en safe reboot.
Finns det någon start/avstänginngsknapp man kan sätta dit?

Permalänk
Medlem

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)

Permalänk
Medlem
Skrivet av bluetrain:

Tack, jag ska prova detta.

Är ju lite dumt att behöva dra kabel varje gång man inte kommer åt och kan göra en safe reboot.
Finns det någon start/avstänginngsknapp man kan sätta dit?

Ja, faktiskt. Jag behöver det inte, men det är enkel att löda dit. Då medför en kort knapptryckning att shutdown utförs. En lång knapptryckning medför sedan boot. Jag har det så på min server som är en utgången Cubieboard20. Väldigt smidigt att slippa logga in. Man behöver även installera ett program. Jag kan kolla när jag kommer hem.

Skickades från m.sweclockers.com

Permalänk
Medlem
Skrivet av xxargs:

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)

De senaste SD-korten jag köpte var både billigare och snabbare och de har oändlig garanti! Utom i Tyskland där de bara har femtio års garanti!

Skickades från m.sweclockers.com

Permalänk
Medlem

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...