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

lschip schreef : Ook dat kan, vandaar mijn opmerking, jongens zoek/maak eens ff samen een goede oplossing want die is er.

Het grote verschil tussen een plotter en een computer(rpi) is, een plotter heeft geen OS (Operating System). Netzo als bv een arduino dat ook niet heeft.
Bij een plotter staat het programma veilig in een EEPROM, en het programma zorgt zelf voor alle bijzaken als beeldscherm bewaren van tracks, lezen van kaarten etc.
Bij een computer start eerst het OS op, en dat leest het programma. En het programm besteed alle bijzaken weer uit aan het OS.
Door je OS en programma op een ReadOnly partitie te zetten benader je het idee van een plotter. Je gegevens als tracks ed zet je dan op normale partitie, en die kan je voor de zekerheid ook nog uitvoeren als een Raid-5.
Maar het blijft een 'benadering'. Wel een benadering die een faktor 10 goedkoper is.

PS
Als OpenCPN protesteert dat het niet netjes is afgesloten, dan kan je O opstarten met een script en in dat script eerst het bestand ~/.opencpn/_OpenCPN_SILock verwijderen.
PS2 De rpi is bedoeld om te leren omgaan met computers. Als je bovenstaande te ingewikkeld vindt dan moet je dus bijleren. (Of een andere oplossing zoeken )

Volgens mij draaien die Raymarine plotters op Android oid… heb er eens een paar dagen mee lopen stoeien.. en bij het booten zag ik dat voorbij komen..

rooiedirk schreef :
Mijn RM plotter werkt onder een Linux OS. Data en programma staan op flashgeheugen. Flashgeheugen is in mijn idee vergelijkbaar met geheugen in een SD kaartje.

Er draaien tientallen miljoenen devices op flash hoor. foutloos, 100 jaar als t moet.
Er is niks mis met flash geheugen.
Naast mij staat een iot modem ontwerp waar ik vandaag al een keer of 15 nieuwe software in heb geblazen. ( R&D)

Maar het is wat je er mee doet.
In een embedded toepassing, dus niet een OS als windows kan je het heel erg robuust maken. Een harde repower is dan geen probleem.

Stel je voor dat een RM plotter daar niet tegen kan, dan blijven ze wisselen onder garantie.....

Koezt schreef :
Waarom niet dezelfde oplossing als rooiedirk? (read-only systeem, maar dan met ubuntu).
En ook de supercap werkt met odroid.

3Noreen schreef : Ha RM ziet het licht ook Maar hun linux is vast flink aangepast, zodat het niet schrijft naar dat flash geheugen. En in je boekje zal ook vast staan dat je bij een firmware update absoluut never nooit niet de spanning mag afschakelen.
Ben wel benieuwd hoe zij hun gebruikers data opslaan, in een apart flash geheugen of misschien in een battery backup static-RAM.

PS Hun linux uitvoering zou op het internet te vinden moeten zijn volgens de licentie voorwaarden van linux. (Je mag het vrij gebruiken en ook aanpassen mits je dit weer publiceert)

Sram met een batterijtje is wel heel erg 1980 . Tegenwoordig heb je daar mooie intelligente eeprommetjes voor, of Fram.

Maar inderdaad, een soort embedded linux.

Zeilprutser schreef :
Logisch, jij bedient grotendeels een publiek dat een turn-key oplossing wil. Anders gingen ze wel zelf met een Pi aan de slag. En wat dat batterijtje betreft heb je natuurlijk een punt, hoewel ik tegen die tijd de hardware alweer vervangen zal hebben. En zolang het batterijtje het nog een beetje doet zal het systeem altijd netjes afgesloten worden bij stroomuitval of het bedienen van de schakelaar.

brice3010 schreef :
Volgens mij heb ik dit al enkele jaren geleden aangestipt en benoemd op het forum, maar werd verguist: de RPI is en was de heilige graal en is niet van repliek gediend....
We hadden zelfs een testopstelling gemaakt om alle mogelijke oplossingen te testen (lees treiteren).

Calidris schreef :
Dat ligt niet aan de Pi als platform an sich, maar aan het feit dat je een computer gebruikt. Er zijn ook mensen die aan boord kiezen voor een Intel NUC of een Pipo met Windows. Daar kan je net zo min zomaar de stekker uit trekken als uit een Pi. En een Pi is zeker niet heilig, maar wel goedkoop en veelzijdig, dus er is altijd iets leuks van te maken. Ook voor onze liefhebberij.

Roozeblij schreef : Dat was inderdaad de tijd dat ze hebben geprobeerd mij wat elektronika kennis bijtebrengen.

Ik zal het nog maar even herhalen; Een Argon aluminium kastje heeft het allemaal. Een aan en uitknop met beveiliging, Alle aansluitingen aan de achterzijde . Een ingebouwde ventilator waarvan je inschakel temperatuur ook nog softwarematig kunt instellen. De processors zijn verbonden met het aluminium huis dat dient tevens als koeling. Dus de ventilator werkt amper.

Je kunt er ook nog een ander onderstuk bij krijgen waarin een Sata SSD kaart in past.

Plus twee grote HDMI poorten inplaats van de kleine.

Kosten zoiets als € 30,-

Dingen werken hier goed. Er zit een kaartje in die de RPI verbindt met de poorten aan de achterzijde. Rechts de aan en uit knop.

Bram

Ik zal het ook maar eens herhalen. Zo'n Argon doosje wil via het besturingssysteem OpenCPN afsluiten. Dat gaat helaas niet helemaal goed als je niet onderstaande aanwijzingen opvolgt. Het probleem ontstaat niet door de framboos maar is een vervelende eigenschap van OpenCPN.
3Noreen schreef :

Eclips schreef :
Ja, klopt grotendeels, zolang er maar bij de gebruikers het besef is wat ze wel en niet kunnen/mogen doen. En dat er aanvullende handelingen/hardware noodzakelijk is om het "mission critical" te maken.

Al het bovenstaande heb ik als volgt opgelost:

1: De RPI draait NIET op een SD, maar een SSD. Dat scheelt ongeveer ALLE problemen met het OS. Met een SSD worden de pakketjes data die heen en weer gestuurd worden, veel kleiner dan met een SD. Heb ik begrepen. De kans dat er dan iets mis gaat bij een harde power off is vrijwel nul.

2: Regelmatig maak ik een backup van de hele folder ".opencpn" elders op de SSD. Zeker na een wijziging aan instellingen. Als er een harde power off is geweest, hoef je die alleen terug te zetten, en alles werkt weer als voorheen.

Het voordeel voor mij:
- Ik snap wat ik aan het doen ben.
- Er is geen extra hardware nodig. Dat is een ding: ik wat gestoeid met de Juice-Pi, maar vond het een K-ding. Matige kwaliteit, doet niet altijd wattie moet doen, en support is nihil.

rooiedirk schreef :
Dit klinkt erg logisch, dit zou ik als linux-leek wel willen proberen voor elkaar te krijgen. Maar hoe dan? Partities maken op een SD lukt wel. De meest recente versie van Openplotter op een partitie zetten ook wel (denk ik). Dan alles vrolijk inregelen in Openplotter, daar is een uitgebreide handleiding voor, zie ik ook wel zitten. Daarna de partitie waarop Openplotter staat RO maken zal waarschijnlijk ook lukken. Klopt dit tot zo ver een beetje of sla ik de plank al totaal mis met bovenstaande?
Maar dan, een raid 5 opzetten voor de opslag van gebruikers data en zorgen dat die daar ook terecht komen en zelf herstellen als het mis is, geen idee waar ik moet beginnen met dat stuk... Kan je daar misschien een tipje van de sluier oplichten? Of is er wellicht ergens al een link voorhanden waar deze hele hufter proof aanpak beschreven is?

3 jaar geleden alweer dit draadje.
https://zeilersforum.nl/index.php/forum-hoofdmenu-37/raspberry-pi-arduino-etcetera/585858-raspberry-met-openplotter-op-readonly-fs#1218277
In de openingspost 2 linkjes waar ik m'n info vandaan gehaald heb.
succes.

PS In dat draadje staat ook nog een link naar mijn google drive met een compleet image van de SD. Is intussen ook 3 jaar oud natuurlijk.

Nou ben ik om. Dit wordt mijn nieuwe standaard. Vandaag even een SD-kaartje kopen en met gparted gaan stoeien totdat ik een plaatje heb als in jouw openingspost. Dan openplotter installeren zoals Koezt dat gedaan heeft.

Ben jij nog snobby geweest over de SD of kan dat er eentje zijn van de spreekwoordelijke A.C.Tion? En hoe trek jij een backup van de SD kaart?

vroeghe waren er nog wel een SD kaartjes waar de pi niet mee wou opstarten. De mijne komt geloof ik van een warenhuis met vier letters.
Een backup maken doe ik niet op de pi zelf, maar op de computer met sd-card lezer. Daar zijn vele programaatjes voor te vinden op het www.

alweereengijp schreef :
Dit is precies waarom ik aangeef dat een klein upsje, die iedereen die een Raspberry pi kan installeren, een simpele oplossing is. Daarmee is het voor degenen die de oplossing van RooieDirk te moeilijk vinden een prima oplossing.

Ik vind de oplossing van RooieDirk ook een nóg betere, en ik kan echt wel wat in Linux, maar ik zou er ook wel even voor moeten gaan zitten om Opencpn, Signalk, Avnav, mijn electronisch logboek etc. separaat op te slaan....

Grofweg is doe je het volgende:
SD kaartje waar je een image van openplotter op zet.
Dan niet de partitie vergroten op de pi, maar op je computer. Kies een groote dat je wat reserve hebt maar ook genoeg ruimte overhoud voor je '/home' Ik heb een 16Gb kaartje gebruikt, maar 32 geeft wat meer ruimte vooral omdat je /home 3x moet doen.
Dan lekker aan de slag om ea RO te krijgen.
Vervolgens de raid5 maken (op de pi) en je hele home directory daar naar toe kopieren
Dan kaartje eruit en op je computer het /etc/fstab bestand aanpassen zodat je raid5 gemount wordt op /homeDe 'oude' home kan je nu leeg maken, kaartje terug in de pi en gaan.

En als het lekker draait natuulijk weer een backup maken en eventueel hier delen.

Joop66 schreef :
In de basis zijn SD kaartjes niet ontworpen om de vele schrijfacties van een OS aan te kunnen. Nu heb ik geen ervaring met Linux en SD kaartjes of USB sticks, wellicht leert de ervaring hier dat het jaren goed gaat. Prima.

In mijn auto was de Speciale Robuuste Veel Schrijfacties USB stick in 2 maanden naar de klote door de vele schrijfacties van het OS. SSD ingehangen, nooit meer problemen.

rooiedirk schreef :
In hoeverre is het mogelijk om jouw oude image te nemen en vervolgens OpenCPN te updaten naar een versie waar de huidige o-charts op werken. Of is dat te simpel gedacht? 32 vs 64 bits en zo.
Voor een Rpi of aanverwant is read olny SD de oplossing.