Onderwerp: RPI als boordcomputer

Multiboot

Hallo Joop.

Heb zoals beloofd eens getest hoe het zit met voorrangsregels tussen usb sticks met opstarten.

Ik heb m’n Pi voorzien van 2 usb sticks. 1x Samsung 32gb, en 1x Sandisk 32 gb. De sticks zijn voorzien van dezelfde image, echter heb ik op de Sandisk een mapje gezet genaamd “backup USB”. Dit om te zien tijdens het testen of de Sandisk is opgestart, of de Samsung.



Vervolgens ben ik de Pi heel vaak gaan opstarten en afsluiten (totaal 30 keer ofzo...)
Daarbij de sticks regelmatig van poort gewisseld.

Resultaat: de Sandisk is dominant. Elke keer start de Pi op vanaf de Sandisk UBS als beide sticks erin zitten. Daarbij maakt het niet uit in welke poort de Sandisk zit.
Voor de duidelijkheid: ik heb alleen de 2 blauwe usb 3.0 poorten gebruikt. (In de andere zit een muis en gps-muis.



Heb ook getest wat er gebeurt als ik de usb eruit trek wanneer de Pi gewoon draait (om crash te “simuleren”). Pi loopt dan vast (begrijpelijk). Voeding ff onderbreken, en Pi start gewoon op vanaf de andere “backup” USB. Dit stuk of 15 keer gedaan, gaat allemaal goed.

Verder heb ik de 2 usb sticks ook aangesloten via een hub op 1 poort.
De resulaten zijn precies gelijk. Sandisk blijft als eerste opstarten. De andere usb werk gewoon via de hub, ook als backup.





Moraal van het verhaal:
Proefondervindelijk vastgesteld dat er wel een opstart volgorde is, maar die hangt dus af van welke USB “sneller” is.
Dit blijft verder constant.
Zelf instellen om een niet “dominante” usb toch softwarematig als eerste op te laten starten gaat niet zover ik weet.

Op zich is daar goed mee te werken denk ik. 1x ff voor jezelf uitzoeken welke usb dominant is. Die usb is dan de Master. De rest backup.
Verder kan je dus een hele hoop usb sticks voorbereiden als je vreest voor problemen.
In mijn geval zijn dat er 5 (4x hub) en 1x direct op de Pi. Kan je in totaal 6x een fatale flash memory crash hebben voordat je de Pi moet aanraken.
Dus de verhalen van “snel een SD kaartje verwisselen op een kritisch moment” behoren tot het verleden, dat is echt niet meer nodig.

Hopelijk ben je hiermee een beetje geholpen! (Ik vond het een nuttige vraag )

Groet!
Sjoerd

Dikke pluim voor Sjoerd!!!

Mooi dat je dit getest hebt, Sjoerd!

Als ik je verhaal goed begrijp, dan heb je een ‘crash’ getest door de USB waarmee de Pi was opgestart eruit te trekken, en dan heb je gekeken of de Pi na rebooten dan vanaf de andere USB opstart.
Maar als je dus iets aan de instellingen hebt veranderd (bewust of niet) waarbij de Pi nog wel opstart maar niet zoals je zou willen, dan moet je dus alsnog die USB eruit trekken om van de andere (intacte) USB op te kunnen starten, toch? Dan zou Joop er toch nog fysiek bij moeten kunnen om het voor elkaar te krijgen om van de andere USB op te starten.

Wat wel een mogelijkheid is, is "dual-boot". Twee systemen op een kaartje of een SSD.

Net zo als het mogelijk is op andere systemen. Even zoeken naar "Barry Boot".

Ik begrijp nog steeds het probleem niet.

Dat een systeem geheel is ingebouwd, ook de SSD ? Dit is zonder meer af te raden. Je moet er altijd bij kunnen komen. Dat geldt trouwens voor alles op een boot.

Een ander systeem proberen. Ander kaartje erin of een andere SSD of usb stick eraan hangen.

Dit alles kun je beter thuis proberen op een andere RPI in plaats van op je navigatie systeem.

Bram

ReinierZeilt schreef :
Ja, dat is zo. Als de Pi “half” opstart vanaf de dominante usb, dan zal die je fysiek uit de poort moeten halen. (Denk ik..)

Maar... gebeurt dat ook echt? Het lastige is dat ik nog geen niet-zelfveroorzaakte crashes heb meegemaakt. Niet de met SD kaart, maar ook niet met de USB. Dus weet niet wat er dan gebeurt, en dan het ook niet goed testen of dat “half” opstarten gebeurt.
Enige wat ik kan is een goed werkende usb eruit trekken als de Pi aanstaat. En voeding zomaar eraf halen. Dit heb ik ook een keer of 10 gedaan, zonder crash (toen vond ik het wel welletjes, verder gaan is geen testen meer, maar moedwillig slopen )

Misschien hebben andere mensen daar ervaring mee? De verhalen die ik heb gehoord, is dat het flash geheugen (SD of USB) corrupt raakt bij een crash. Dan start ie helemaal niet meer op lijkt me.

Interessante materie...

Groet!
Sjoerd

sjoerd1981 schreef :
Het OS zal ongetwijfeld veel dingen terugschrijven naar de geheugenkaart en daar van alles tijdelijk opslaan, waaronder hele stukken werkgeheugen via paging en swapping.
Als er iets met de kaart mis is en dat stukje gegevens was toevallig net nodig dan is vastlopen zeker een goede mogelijkheid, het zal afhangen van de data in kwestie.
Opnieuw kunnen opstarten vanuit die geheugenkaart is dan niet meer gegarandeerd.....

Baasklusje schreef :
Nee dat klopt. Ik betwist ook niet dat vastlopen echt kan gebeuren.

De vraag is of een usb “half” corrupt kan zijn, zodat hij wel probeert op te starten, maar halverwege vastloopt. Want dan moet je de corrupte usb er toch fysiek uithalen voordat de Pi van de backup automatisch opstart.

Misschien, als alles perse ingebouwd moet zitten een schakelaar naar voren brengen. Dus zoiets als dit;
[url=http://https://www.allekabels.nl/usb-micro-kabel/4911/1387258/micro-usb-kabel.html?gclid=Cj0KCQjw5PGFBhC2ARIsAIFIMNcjyQ8jVJ03mAHAwEYa1_82DCNkiQ99hPPKJrpaovIO6mHK8ZBVF-8aAjcjEALw_wcB][/url]
En dan die schakelaar ergens in je schakelpaneel. Dan kun je een SSD fysiek uitschakelen.

sjoerd1981 schreef :
Dat kan vast wel. Hier een goede beschrijving van het opstartproces.

developer.ibm.com/technologies...%201%20boot%20loader

Het Bios zal wel werken (niet afhankelijk van een 'los' geheugen). Eerst de POST, dan iets opstartbaars zoeken.
Het vinden van een bootable device lukt dan dus ook wel want dat regelt het Bios.
Na het vinden van een MBR (op een bootable device) kan het op elk moment tijdens het laden van het OS fout gaan als er fouten in het opstartdevice zitten.

Als dat gebeurt denk ik dat een apparaat niet lekker vanzelf van een andere geheugenkaart gaat opstarten. Het eerste device was immers bootable.....

Dual Boot voor 2 keer Linux op 1 stick... dat zou misschien kunnen helpen....?

@Rooiedirk:

Een kleine maar irritante bug:

Op RPI:

Als je het NMEA debug window aan hebt, kun je dat pas weer sluiten, of de knoppen in dat scherm bedienen als je eerst het settingswindow daar achter gesloten hebt.

Hierop inhakend: in het filter in deze debugwindow kun je niet op talkerID filteren, alleen op scentence. Het zou mooi zijn op beide te kunnen, bv door wildcards toe te staan naar mijn mening

OpenCPN 5.

Ik zie dat daar een 64bit versie kant en klaar voor wordt aangeboden. Niet meer beta.

Maar.

www.raspberrypi.com/software/operating-systems/

Als ik hier de Rasp OS kies, is die dan 64 bit?

En:

Ben ik dan de O-chart key kwijt?

Of: Is het mogelijk de huidige 32bit OS automatisch te laten updaten naar 64, met behoud van alle instellingen?

Joop66 schreef :
OpenCPN wel 64 bit, Raspberry Pi OS nog niet (vlgs mij nog steeds in Beta, zonder release date).
Ik vond de logica achter de fingerprint van O-Charts lastig, dus heb gewoon 2 dongels. Idee?.

Joop66 schreef :
Dat is lijkt mij gezien de opzet niet mogelijk. De nieuwste versie is gebaseerd op Debian Bullseye. Je zult versteld staan hoe snel het daarna werkt. Uiteraard met de flatpak OpenCPN versie 5.6 en alle plugins.

Je bent hierdoor wel 2 USB poorten kwijt. Het stroom gebruik van dongle en de usb stick zijn gering.

Groet,

Bram

brambo schreef :
OK. Thanks.

Flatpack klinkt als iets "eenvoudigs", klopt dat?

Daar ben ik wat schrikachtig voor geworden, als ik heel eerlijk ben.

Hoe ingewikkeld is de instructie om Rasp OS 64 bit op een SSD te krijgen?

Beste Joop,

in het RaspiOS zit de applicatie SD kopieren oftewel Pi-clone.

Hiermee kun je kopieren van SD kaart naar SSD HD, USB stick of andersom ongeacht de capaciteit
van het apparaat (Uiteraard mits er voldoende ruimte is.) Als het goed is, is je systeem van de laatste Eeprom versie voorzien.

Waardoor starten van een USB stick, SSD of een SD kaartje gewoon mogelijk is. Je kunt in sudo raspi-config ook nog aangeven welke voorkeur je wilt.

Formatteren met Windows gaat soms niet goed. Want Windows ziet eenvoudig Ext4 partities niet.

Pi-clone neemt eenvoudig alles over. Ik gebruik dit ook om andere zaken te kopieren. Start Pi-clone op. Steek het ene apparaat (met Ubuntu) bijvoorbeeld in de USB poort en een tweede apparaat in een andere USB poort.

Ook dat werkt. Je hiermee dus allerlei andere zaken kopieren. Van het ene medium naar het andere.

Bram

brambo schreef :
Wacht- wat? Waar dan? Niet op de officiële website (www.raspberrypi.com/software/operating-systems/)
Volgens mijn laatste (enthousiaste, blije, verwachtingsvolle) zoektocht is Raspbian 64 (Bullseye) nog steeds BETA. Weer een dooie mus dus. Jammer.

Ze zijn er zelf erg vaag over.
Ik weet dat jij er erg blij mee bent maar ik wil (en ga) niet varen met een OS in Beta.

(meest recente, niet officiële info heb ik uit dit draadje:
forums.raspberrypi.com/viewtopic.php?t=327731 )

Maarten-IW31 schreef :
Dan nog is het de vraag welke versie van OpenCPN in bullseye is ingebouwd. Bij de amd64 versie van
bullseye is dat 5.2.4 Niet dat dit een ernstig bezwaar is. Lekker stabiel.

Info over de laatste versie van RaspiOS op basis van Debian Bullseye.

www.raspberrypi.com/news/raspb...-os-debian-bullseye/

Voor een Raspberry Pi 4 beslist de 64 bits versie nemen.

Als je dan de flatpak versie van OpenCPN 5.6 neemt, dan heb je tegelijk ook alle plugins beschikbaar.

Zie mijn eerdere post als je de nieuwe Oesenc plugin wilt installeren voor de zeer binnenkort uitkomende nieuwe opzet van de O-charts plugin.

Er is dan een plugin voor zowel raster kaarten als ENC. Staat nu nog in de beta plugins.

Dat geldt overigens ook voor AMD64 systemen en de nieuwe versie 5.6 versie van OpenCPN. Je kunt die ook als flatpak versie installeren. De bestaande OpenCPN versie blijft onaangeroerd en werkend.

Je hebt dan 2 OpenCPN versies beschikbaar.

Het eerste wat je moet doen is de flatpak omgeving op je systeem aanbrengen. Een omvangrijk bestand.

Sudo apt install flatpak. Werkt op vrijwel ieder Linux systeem.

Als er interesse voor bestaat zal het vervolg ook nog aangeven. Is overigens ook te vinden op de Website van OpenCPN.

Voor de Pi zou ik adviseren de installatie op een SD kaartje te doen en daarna de inhoud van het SD kaartje naar snelle 3.1. Usb stick te kopieren. Hier een met 300mb/s.

Kaartje eruit en opstarten van de usb stick.

Je hebt dan dezelfde werking als een SSD HD, maar veel goedkoper en met minder stroom gebruik.

Overigens flatpak schijnt ook beschikbaar te zijn voor Windows 11 WSL versie. Uiteraard als Linux.

Bram

brambo schreef :
Uit die link:
Op beide links geen download van de 64-bits RaspiOS Bullseye-versie te vinden

Tja dat is typisch Brambo, alles is heel makkelijk maar hij verteld niet hoe!
downloads.raspberrypi.org/raspios_arm64/images/

Zeilprutser schreef :
Ik doe dit alleen op verzoek. Anders krijgt ik weer direct kritiek en daar wordt ik een beetje moe van.

Ik begeef mij aan het voorfront van de nieuwste ontwikkelingen en dat snapt niet iedereen.

Als er voldoende belangstelling voor bestaat, zal ik een handleiding maken, hoe je stap voor stap een volledig werkend 64 bits systeem op de RPI4 kunt kunt maken met alle opties, zoals OpenCPN 5.6, Flatpak, SignalK en alle plugins.

Ik heb dat recent voor een ZF lid gedaan.

Moet hier de nodige moeite voor doen en wens dan geen gezeur op mijn dak te krijgen van mensen die het zelf niet eens gebruiken.

Een geheel compleet systeem maken op een SD kaartje is ook nog steeds mogelijk.

Het verplaatsen van de SD kaart inhoud, naar een usb stick of SDD HD, uitsluitend uitvoeren met de SD kopieer software (Pi-Clone). Andersom kan het ook. Je kunt hiermee ook nog andere hardware kopieren (bit voor bit).

Bram

downloads.raspberrypi.org/raspios_arm64/images/

Bi voorkeur de ARM versie nemen en niet de armhf.

brambo schreef :
HF staat voor "hardware floating point", dat betekent dat de CPU hardware ondersteuning biedt voor floating point berekeningen waar de niet-HF versie dit niet ondersteunt en dus softwarematig gesimuleerd moet worden. Maw HF versie zou sneller moeten zijn bij FP berekeningen.

In de link zie je trouwens geen ARM of ARMHF varianten staan, alleen ARM64.