Onderwerp: Raspberry Pi en OpenCPN: opletten bij "shutdown"

Brambo heeft gewoon altijd een reservekaartje paraat Da’s het mooie van een RPi!

brice3010 schreef :
Handige oplossing!

Ik zie meer iets in een Raspberry Pi UPS HAT.

Dan hoef je er helemaal niet meer bij na te denken en sluit hij zelf af als de capaciteit van de accu afneemt....

Wat is de klok frequentie van een framboos ? Hoe lang denk je dat je het draadje aan een GPIO kan maken voordat het ding amok maakt ? Dit soort grappen kun je met een Arduino die op een slome 16 MHz draait wel doen maar op het 100 voudige
Verder heeft het stoppen van OpenCPN vanaf de backdoor iets meer aandacht nodig. Is ook vrij goed gedocumenteerd op de site van OpenCPN.

Deze Raspberry Pi HAT zit er ook aan te komen. Specifiek om stabiele voeding te geven en de 'last breath' shutdown te kunnen doen.

Dit draait bij mij nog steeds probleemloos. En zonder extra hardware.
https://zeilersforum.nl/index.php/forum-hoofdmenu-37/raspberry-pi-arduino-etcetera/585858-raspberry-met-openplotter-op-readonly-fs#1218277
3 jaar intussen

Nachtvlinder schreef :
Nee, geen SD kaartje meer, maar eenvoudig een snelle USB stick of een SSD via USB3.

De Pi boot met een nieuwe Eeprom versie probleemloos van een USB3 apparaat. Zo'n usb stick of een SSD is in principe minder kwetsbaar dan een SD kaartje.

Verschil in kosten ? Een USB stick 3.2 met een leessnelheid tot 300 mb/s kost in de 64 GB uitvoering € 19,-. Heb hier 3 verschillende OS versies op 3 usb sticks.

Installeren van Raspian 64 OS kan met deze Eeprom direct vanaf een server.

Niets erin steken en bij opstarten shift toets ingedrukt houden.

Kan het mooier ?

Bram

brambo schreef :
Wel flexibel in elk geval.

Ik begrijp het hele probleem niet. Iedere computer sluit je toch netjes af.

Daar trek je toch ook niet de stekker uit het stopcontact als de computer nog draait.

Verder is het ext3 file systeem zelfherstellend. Een ook OpenCPN heeft een "dubbele agenda". Als deze niet goed start, dan start je voor een tweede keer. Grote kans is dat het dan weer normaal werkt.

Ik heb er een PiJuice HAT op zitten. Dan heb je UPS én een aan/uit schakelaar. Bovengenoemde oplossing ken ik ook, maar werkt niet in combinatie met de PiJuice omdat die de I2C pin al in gebruik heeft. Enige nadeel van de PiJuice vind ik dat de in- en uitschakelfunctie alleen werkt als je de Micro-USB input gebruikt. Zelf heb ik de voeding liever via de GPIO pins lopen.

Ik snap niet dat een oplossing zoals die van Rooiedirk hier nog steeds geen gemeengoed is op forum.
Iedereen wil toch gewoon de hoofdschakelaar van je navigatie om kunnen gooien zonder afsluiten en ander gedoe?
En dan met oplossingen komen zoals een extra UPS en zo, dat heeft een plotter toch ook niet, wie heeft een UPS achter zijn plotter?

Ik benader dergelijke zaken altijd van de geheel andere kant: je weet zeker DAT op een gegeven moment het zal gebeuren dat de stekker eruitgaat. En dat er dan iets kapot kan gaan. Je kunt maar beter vooraf weten wat er dan stuk gaat en er op voorbereid zijn. Zo heb ik altijd een actuele backup van de configuratiefile van opencpn, plus een scriptje om die file terug te zetten. En een reserve SD-kaart. Plus ook nog een paar screendumps van de belangrijke configuraties. Je zult toch maar al je geld en vertrouwen ingezet hebben op 1 enkele SSD unit om erachter te komen dat je geen enkele backup daarvan hebt? Het 'netjes' uitzetten van een navigatiecomputer op een zeilboot is voor mij een idee-fixe. Zeilen is toch geen 9 to 5 job of zo?

Mijn ervaring met Raspberry's en een read olny file system zijn ook uitstekend. Je zou bijna zeggen dat Raspberry's daarvoor gemaakt zijn. Het heeft ook iets geruststellends dat bij het opstarten er altijd precies het zelfde gebeurt. groundhog day.
Maar een log maken van je gevaren route is wel een stuk omslachtiger.

In mijn opzet niet. Ik heb alleen de root als Read-only, dus programmas en linux zelf gaat altijd goed. De home dir wordt 3x weggeschreven, en bij lezen gechekt op verschil tussen deze 3, en zo ja de 2 gelijke gebruikt en de derde hersteld.
Enigste nadeel is dat lezen en schrijven dus 3x gebeurd, en dat kost ietsjes tijd.

Ik heb nog nooit ervaren dat de root een probleem heeft. Het gaat mis bij die files die veel geschreven worden, en dat die corrupt raken hetzij als gevolg van het feit dat de SD kaart op die plek grijs geschreven is, hetzij door een powerdown tijdens het schrijven. Welk van de twee weet ik dan weer niet. Vanuit dat oogpunt zou ik meer waarde hechten aan de raid-configuratie voor die files. Staan die wel elke 3x op dezelfde SD-kaart? Heb je ooit al gezien dat de raid een reparatie heeft uitgevoerd?

Voorzover ik weet is het probleem bij SD kaartjes vooral dat je niet simpel één file kan schrijven, maar eerst een blok moet lezen, dan het blok wissen en dan het aangepaste blok opnieuw schrijven. Gaat dit niet goed dan ben je dus zeer waarschijnlijk meerdere bestanden kwijt dan wel beschadigd.
Het voordeel van een ro root is dat hier dus nooit iets aan veranderd wordt, ook niet als een naast gelegen file wordt aangepast.
Alles staat inderdaad op 1 SD kaart. Of de raid heeft ingegrepen? geen idee, nooit meer naar omgekeken. Maar wel bijna dagelijks gebruikt.

Is dan toch een mini upsje die de rpi netjes afsluit niet veel eenvoudiger en vooral laagdrempeliger voor de meeste gebruikers?
Dat, samen met twee reserve sd kaartjes met een kopietje erop.

Dan ben je echt zorgeloos en kun je de rpi gewoon uitzetten met de hoofdschakelaar van de boot.

lschip schreef :
Reserve sd kaartjes is een fallback. Maar je bent wel je log's kwijt. En eventuele routes die je gemaakt hebt en update's van je kaarten. Die laatste twee kun je natuurlijk wel voorkomen door telkens als je routes bijmaakt of veranderd dan wel kaarten bijwerkt dat ook te verwerken op je reserve sd kaartjes. Dat vereist een discipline die bij mij afwezig is. Maar log's is jammer dan. Bovendien kwam ik daar pas veel later achter dat de log bestanden voor een groot deel corrupt waren. Overigens niet door uitzetten of power failure. Maar zeer waarschijnlijk door een te hoge temperatuur van het sd kaartje. SD kaartje zit wat dat betreft bij een Rpi4 op een ongelukkige plek.

Dat is dus precies wat ik doe
Een UPS(je) is m.i. een technisch probleem oplossen met nog meer techniek.

rooiedirk schreef :
Thx. Leerzaam.

Jawel, dat zal best zo zijn maar het een upsje is een stuk eenvoudiger toe te passen voor de meeste gebruikers...

Kan alleen maar kapot.

Het probleem is ook een beetje dat OpenPlotter zo lekker makkelijk is. Zelfs ik doe het . Het zou mooi zijn als iemand een stap-voor-stap procedure zou beschrijven om een kant-en-klare openplotter image te modificeren zodat niet alleen het root filesystem read-only zou zijn, maar ook het home filesystem raid is .

Beetje vreemde reacties op het gebruik van iets UPS-achtigs hier. Zo'n ding is ook niet meer dan een HAT met een kleine lithiumaccu. Mijn Pi zit in een SmartiPi case. Als de SD-card een keer corrupt zou raken zou dat héél vervelend zijn, want het vervangen van het kaartje is een crime. Gedoe met een pincet om het kaartje onder de Pi uit te peuteren, want direct er overheen loopt de DSI-kabel van het touchscreen. Dat is op de keukentafel al niet leuk, laat staan op een wiebelende boot. Ik ben vooralsnog tevreden met de PiJuice, ook omdat ik het spul nu inderdaad met een druk op de knop aan en uit kan zetten.

waarom niet iets als een Argon 1 case? kan je de pi aan/uit zetten, kan een SSD kaart aan en heb je ook nog eens actieve koeling.

Een vraag die hierbij aansluit: als ik OpenPlotter op mijn RPi netjes afsluit met OpenCPN nog open, dan klaagt OpenCPN bij de volgende keer opstarten dat hij de laatste keer niet goed afgesloten is, en vraagt hij of hij in veilige modus moet starten.
Is er een manier om te zorgen dat OpenCPN eerst netjes wordt afgesloten voor OpenPlotter zichzelf afsluit (behalve handmatig uiteraard)?