Fråga:
Använda Raspberry Pi för att blinka sitt eget SD-kort
Jeremiah Rose
2019-06-25 08:02:09 UTC
view on stackexchange narkive permalink

Jag utvecklar ett Buildroot-operativsystem för Raspberry Pi, och mitt arbetsflöde kräver mycket ofta återblinkning av SD-kortet för att testa nya iterationer. Processen att ta bort SD-kortet från Pi, blinka det på en Windows-dator och sedan sätta in det igen tar mycket tid Jag vill skriva ett skript som använder det för närvarande körande operativsystemet på Rpi (nås via SSH) till

  1. Ladda ner den nya SD-avbildningen
  2. Blixt till SD, skriv över alla befintliga OS-filer
  3. Starta om till det nya OS

Steg 2 är där jag sitter fast. Är det möjligt för ett operativsystem att skriva över sig själv?

Du kan överväga att använda nätstart för utveckling.
Det här är en kommentar eftersom jag inte vet om det skulle fungera, men kan du ha två partitioner på SD-kortet, skriva till den andra partitionen och sedan starta från den nya partitionen nästa gång? När du itererar genom ändringar startar du bara från en partition eller den andra?
@JPhi1618 Ja, det är möjligt, förutom att du inte vill skriva en (normativ) Pi OS-bild till den andra partitionen - du vill skriva innehållet i rotfilsystemet, som du kan extrahera från bilden. Det kräver lite manuell (eller skriptbar) tinkering. Då vill du uppdatera startpartitionen och ställa in `root =` i `cmdline.txt`.
Det enklaste sättet är att använda en USB SD-kortläsare / -författare.
Sju svar:
flakeshake
2019-06-25 09:56:22 UTC
view on stackexchange narkive permalink

För att skriva över sig själv måste ditt operativsystem köras helt i RAM och varken läsa eller skriva från SD-kort efter start. piCore / TinyCore är förmodligen ett av få Linux OS som kan göra det.

Är det nödvändigt att OS * aldrig * läser / skriver till SD, eller bara det som inte kräver SD under dd-operationen?
@JeremiahRose Om något annat skriver till en del av SD-kortet 'dd' är klar med, kommer det att skruva upp bilden.
@JeremiahRose Strängt taget, så länge du kan _ helt säkert garantera_ att _ absolut ingen modifiering av SD-kortet_ kommer att hända medan `dd` körs, är det bra om det ändrar SD-kortet utanför det. Praktiskt taget går du bara med ett operativsystem som aldrig ändrar SD-kortet; det blir enklare att resonera om.
"medan dd är igång" - inte bara när den är igång, efter att den är klar. OS kommer troligen att cacha olika metadata för filsystem, till exempel _var filer finns på SD-kortet_. Om det, efter att dd är klart, beslutar att skriva till en av dessa filer (som inte längre finns där operativsystemet tror att de är), kommer det att skriva över andra godtyckliga data istället.
Ett operativsystem som körs bara i RAM är en enkel och allmän lösning, men på något sätt är jag lite besviken om det inte finns ett program som bara låser sig själv och bildfilen i minnet, förhindrar att andra processer körs ( ställa in sig för att köra med schemaläggning i realtid eller något) och skriv sedan bilden och starta om systemet.
@ilkkachu, problemet med det är många processer som att skriva en uppdatering av något slag till sig själva när de stängs av. Att förhindra detta kan orsaka RTE, orsaka oväntade andra fel. Även operativsystem gillar att göra detta. Att förhindra operativsystemet från en uppdatering av avstängning av ett program som körs på operativsystemet kommer sannolikt inte att fungera, eftersom programmet kommer att stängas av innan operativsystemet, som då skulle ha tillgång till kortet, vilket besegrar programmet oavsiktligt.
Baserat på dina kommentarer försöker jag tänka på ett sätt att förbättra mitt svar så att det 1. stoppar systemet omedelbart efter dd (utan avstängning) och 2. låser SD från att skrivas till av någon annan process (bara ändra behörigheter på / dev / mmcblk0 ska du göra det?)
@JeremiahRose Kanske lägger till ett overlayfs-lager som stöds av en ramfs över SD-kortet innan du kör `dd` och sedan gör en" nöd "-start (lite som att skriva [Alt-SysRq-U och sedan Alt-SysRq-B] (https: / /sv.wikipedia.org/wiki/Magic_SysRq_key))? Spekulerar bara, inte säker på att detta kan göras direkt.
@computercarguy, Jag skulle säga att det är ett sällsynt program som insisterar på att skriva uppdateringar när man stänger av (förutom förmodligen allt med sqlite eller sådant, men t.ex. de vanliga kommandoradsverktygen faller inte in i det). Hur som helst, vad jag pratar om skulle vara ett program som är byggt för just det syftet och skulle bara be om en hård och omedelbar omstart, inte en avstängning av användarutrymmet.
@ilkkachu, om det har ett loggningssystem som Windows, vill det skriva en logg som säger varför avstängningen hände. Om det inte hanteras korrekt av den aktuella disklayouten kan du av misstag skriva över en del av systemfilerna eller helt enkelt vara en godartad post mitt i vad som borde vara mellanslag. Det kan också finnas en automatisk uppdatering för det körande operativsystemet som startar efter att du har tagit om bilden, vilket orsakar samma typ av problem. Poängen är att du som användare inte har så mycket kontroll som du tror att du gör.
@computercarguy, ja, jag hade det dolda antagandet eller ett Linux-system (jag tror att det är det som ofta används på hallon och andra liknande enheter också). Självklart kör inte alla Linux, och sådant sådant _ är_ beroende av operativsystemet, men så körs OS från RAM.
@computercarguy, men när det gäller automatiska uppdateringar och liknande, notera att jag sa _ "förhindra att andra processer körs" _.
@ilkkachu "förhindrar att andra processer körs", det är vanligtvis inte så enkelt som det låter. Vad händer när en process som krävs för att köra wipe & reimage också kräver en annan process som kräver en annan process (i ad infinitum) som så småningom vill skriva något till enheten? Det är alltför vanligt och ofta svårt att komma runt eller skriva om effektivt när processkraven ändras på operativsystemet. Det är något att tänka på, inte en garanti för att det inte fungerar.
Roger Jones
2019-06-25 13:45:15 UTC
view on stackexchange narkive permalink

Som påpekats någon annanstans är dd -ing över ett operativsystem som körs aldrig en bra idé. Ett alternativ (och det vanliga sättet att utveckla inbäddade system) är att få din OS-bild serverad från en nätverksenhet och målkortet utför en nätverksstart. Detta påskyndar den första utvecklingen och du behöver bara skriva ut SD-korten när du kommer närmare slutförandet och behöver testa på faktisk hårdvara.

Det finns en skrivning om hur du ställer in PI3B och PI3B + för att starta en server på Foundation-sidorna: https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/net_tutorial.md

I mitt fall har dd-ing över det löpande operativsystemet orsakat absolut inga problem alls
Akta dig att det här är lite som att säga att du kör full ofta och inte har några problem alls, eller tar trappan i mörkret hela tiden och har inga problem alls osv. Det är lite annorlunda än att dessa saker, dock i att när det går fel kommer du inte ha någon möjlighet att reagera på det. OTOH, du kommer inte att skadas eller dödas, så "det fungerar tills det inte gör" kanske bra med ditt arbetsflöde.
Det här liknar den teknik som människor använder för att köra verktyg som nwipe för att säkert radera en hel hårddisk: https://github.com/martijnvanbrummelen/nwipe/
Jeremiah Rose
2019-06-25 13:26:20 UTC
view on stackexchange narkive permalink

Använd med försiktighet

Detta fungerar för mig eftersom jag använder ett skrivskyddat rotfilsystem med ett anpassat Buildroot-operativsystem. Det här skriptet har inte testats på Raspbian än, men kommer förmodligen att fungera. 

  #! / Bin / bashset -eecho "Kopiera bild till RPi ..." sshpass -p LÖSENORD scp / PATH /TO/SDCARD.img USER @ RPI: /tmp/sdcard.imgecho "Blinkande bild till / dev / mmvblk0 på RPi ..." sshpass -p LÖSENORD ssh USER @ RPI 'nice -20 sudo sh -c "sync && dd if = / tmp / sdcard.img of = / dev / mmcblk0 conv = fdatasync && reboot -f "'

Detta ska köras på värddatorn ( inte stark > RPi) och gör följande:

  1. Kopierar SD-bilden till RPi via scp
  2. Loggar in i RPi via ssh
  3. Synkroniserar alla väntande OS-skrivoperationer till SD-kort
  4. Ställer in prioritet till -20 för att förhindra att andra processer körs
  5. Blinkar bilden till SD-kortet följt av en fdatasync
  6. Utför en hård återställning

Begränsningar:

  • Om data skrivs till SD-kortet av en annan process medan skriptet körs kan SD bli korrugerad pted. På några dagar av aktiv användning har jag inte stött på detta ännu - men jag använder inte Raspbian.
  • Se till att du bara använder det här skriptet för utveckling / testning, inte för att uppgradera ditt operativsystem eller något annat datakänsliga applikationer.
  • Kan använda vissa förbättringar för att ytterligare hindra andra processer från att komma åt SD-kortet - välkomna förslag.

Att använda: stark >

  1. Kopiera ovanstående skript till en flash.sh -fil på din värddator
  2. Fyll i dina inställningar för lösenord, användarnamn, SD-bild etc
  3. Gör det körbart med chmod a + x flash.sh
  4. Installera sshpass och ssh på värden: sudo apt installera sshpass openssh
  5. Se till att ssh-inloggning fungerar på RPi
  6. Kör ./flash.sh kod>
Det finns fall där bilden är tyngre än minnet av raspy, vad skulle vi kunna göra i dessa fall?
Ja, dessa fall låter omöjliga att arbeta runt
Monty Harder
2019-06-26 02:43:49 UTC
view on stackexchange narkive permalink

Använd ett SD-kort som är tillräckligt stort för att rymma flera partitioner

SD-kortet ska innehålla en startpartition (0) och tre OS-partitioner (1-3).

Startladdaren på startpartitionen undersöker partitionsetiketterna för att avgöra vad som ska laddas. Antag att etiketterna är:

0: BOOT
1: OS-0004!
2: OS-0002
3: OS-0003

Lastaren vet att ladda operativsystemet från partition 1, eftersom det är den sista etiketten när de sorteras. Och den första OS-etiketten är partition 2, till vilken den skriver uppdateringen

2: OS-0005_

Detta är nu den sista etiketten, men understrykningsflaggan säger till lastaren att det är det första försöket att starta från det. Det ändrar etiketten för att ange att den gör en teststart precis innan den kopplas till den:

2: OS-0005? Om operativsystemet framgångsrikt startar upp och klarar sina egna sanityskontroller uppdaterar det etiketten en gång till, liksom etiketten för den tidigare OS-partitionen: 1: OS-0004 2: OS-0005!

Om den misslyckas, nästa gång den försöker starta upp, kommer den att se? flagga och återgå för att ladda från partition 1, varefter uppdateringen börjar om.

Detta verkar vara en intressant översikt, men har du några detaljer om hur man gör det?
Jag har inte gjort det själv, men jag vet att startladdare kan den här typen av saker. Google Chromebook-systemet liknar det genom att det har en startpartition, minst två OS-partitioner och en användarutrymme-partition, så att uppdateringar alltid tillämpas på OS-partitionen som systemet inte startade från.
Ronny Nilsson
2019-07-24 17:56:04 UTC
view on stackexchange narkive permalink

Alla dina krav finns redan i min Nard SDK-distribution. Det går från RAM och det finns färdiga skript för fjärrbilduppgraderingar.
http://www.nard.se/

Trevligt projekt! Jag har en fråga: De flesta av de [exemplen] (http://www.nard.se/examples.html) som listas verkar som saker som också görs med RPi / Raspbian, så jag är inte klar över fördelarna med ditt (Nard) system. Redigera yr svar för att utarbeta?
@Seamus Där Nard lyser är för stora volymprodukter. Säg till exempel att du bygger någon form av maskin med en inbäddad Pi. Maskinen säljs sedan i +100 exemplar. Frånvaron av sådana användarprodukter på webbplatsen är politisk. Tillverkare går aldrig med på att bli en referens. :(
Timothy Baldwin
2019-06-26 23:35:17 UTC
view on stackexchange narkive permalink

Här är ett grovt tillvägagångssätt:

  1. Byt ut / sbin / init med uppgraderingsverktyget.
  2. Be init att köra igen.
  3. Döda alla andra återstående processer (till exempel med kill -9 -1 )
  4. Använd pivot_root och chroot för att ersätta roten filsystem.
  5. Om det behövs exec nästa steg för att släppa referenser till den gamla roten.
  6. Demontera den gamla roten rekursivt.
  7. Skriv den nya bilden.
  8. Starta om.
Benjamin Collins
2019-10-29 06:36:18 UTC
view on stackexchange narkive permalink

Jag har funderat på något liknande för att testa utveckling / distribution från en ny installation av Raspbian. Mitt nuvarande tänkande är ett dubbelt sd-kort, usb-drive set up. Så vid varje start startar pi först in i SD-kortet, blinkar en ny installation till USB-enheten och sedan krokar in i USB-enheten för att starta operativsystemet.

Även om det här bara är text , jag har bara tänkt på det konceptuellt medan man manuellt blinkar SD-kort med andra enheter. Så jag antar att jag bör börja undersöka implementeringen ..



ⓘ
Denna fråga och svar översattes automatiskt från det engelska språket.Det ursprungliga innehållet finns tillgängligt på stackexchange, vilket vi tackar för cc by-sa 4.0-licensen som det distribueras under.
Loading...