Pytanie:
Używanie Raspberry Pi do flashowania własnej karty SD
Jeremiah Rose
2019-06-25 08:02:09 UTC
view on stackexchange narkive permalink

Tworzę Buildroot OS dla Raspberry Pi i mój przepływ pracy wymaga bardzo częstego ponownego flashowania karty SD w celu przetestowania nowych iteracji. Proces wyjmowania karty SD z Pi, flashowania jej na komputerze z systemem Windows, a następnie ponownego włożenia zajmuje dużo czasu Chciałbym napisać skrypt korzystający z aktualnie działającego systemu operacyjnego na Rpi (dostęp przez SSH) do

  1. Pobierz nowy obraz SD
  2. Zapisz go na SD, nadpisując wszystkie istniejące pliki systemu operacyjnego
  3. Uruchom ponownie w nowym systemie operacyjnym

Utknąłem w kroku 2. Czy system operacyjny może sam się nadpisać?

Możesz rozważyć użycie rozruchu sieciowego do programowania.
To jest komentarz, ponieważ nie wiem, czy to zadziała, ale czy możesz mieć dwie partycje na karcie SD, zapisać na drugiej partycji, a następnie następnym razem uruchomić komputer z nowej partycji? Podczas iteracji zmian po prostu uruchamiasz komputer z jednej lub drugiej partycji?
@JPhi1618 Tak, to możliwe, z wyjątkiem tego, że nie chciałbyś zapisywać (normatywnego) obrazu Pi OS na drugiej partycji - chciałbyś zapisać zawartość głównego systemu plików, który możesz wyodrębnić z obrazu. Wymaga to trochę ręcznego (lub skryptowego) majsterkowania. Następnie chcesz zaktualizować partycję rozruchową i ustawić `root =` w `cmdline.txt`.
Najłatwiej jest użyć czytnika / nagrywarki kart SD USB.
Siedem odpowiedzi:
flakeshake
2019-06-25 09:56:22 UTC
view on stackexchange narkive permalink

Aby nadpisać się, system operacyjny musi działać w pełni w pamięci RAM i nie czytać ani nie zapisywać z karty SD po uruchomieniu. piCore / TinyCore jest prawdopodobnie jednym z niewielu systemów operacyjnych Linux, które to potrafią.

Czy konieczne jest, aby system operacyjny * nigdy * nie czytał / zapisywał na SD, czy po prostu nie wymaga SD podczas operacji dd?
@JeremiahRose Jeśli cokolwiek innego zapisze na części karty SD `dd`, to zepsuje obraz.
@JeremiahRose Ściśle mówiąc, o ile możesz _całkowicie na pewno_ zagwarantować_, że _ absolutnie żadna modyfikacja karty SD nie nastąpi podczas działania `dd`, to jest w porządku, jeśli zmodyfikuje kartę SD poza tym. Praktycznie rzecz biorąc, po prostu wybierz system operacyjny, który nigdy nie modyfikuje karty SD; łatwiej będzie o tym myśleć.
„gdy dd jest uruchomiony” - nie tylko podczas działania, ale po jego zakończeniu. System operacyjny prawdopodobnie będzie buforował różne metadane systemu plików, takie jak _ gdzie pliki znajdują się na karcie SD_. Jeśli po zakończeniu działania dd zdecyduje się zapisać do jednego z tych plików (które nie są już tam, gdzie sądzi system operacyjny), zamiast tego nadpisze inne arbitralne dane.
System operacyjny działający wyłącznie w pamięci RAM jest prostym i uniwersalnym rozwiązaniem, ale w pewnym sensie jestem trochę rozczarowany, jeśli nie istnieje program, który po prostu zablokowałby się i plik obrazu w pamięci, uniemożliwiając uruchomienie innych procesów ( ustawienie się do pracy z harmonogramem w czasie rzeczywistym lub coś w tym stylu), a następnie napisz obraz i zrestartuj system.
@ilkkachu, problem polega na tym, że wiele procesów lubi pisać aktualizację do siebie, gdy się zamykają. Zapobieganie, które może powodować RTE, powodując nieoczekiwane inne błędy. Nawet systemy operacyjne lubią to robić. Zapobieganie aktualizacji systemu operacyjnego przy wyłączaniu przez program działający w systemie operacyjnym raczej nie zadziała, ponieważ program zostanie zamknięty przed systemem operacyjnym, który miałby wówczas dostęp do karty, omyłkowo pokonując program.
Opierając się na twoich komentarzach, próbuję wymyślić sposób na poprawienie mojej odpowiedzi tak, aby 1. zatrzymywała system natychmiast po dd (bez zamykania) i 2. blokowała SD przed zapisem przez jakikolwiek inny proces (tylko zmiana uprawnień na / dev / mmcblk0 powinno to zrobić?)
@JeremiahRose Może dodanie warstwy overlayfs wspieranej przez ramfs na karcie SD przed uruchomieniem `dd`, a następnie„ awaryjne ”ponowne uruchomienie (trochę jak wpisanie [Alt-SysRq-U, a następnie Alt-SysRq-B] (https: / /en.wikipedia.org/wiki/Magic_SysRq_key))? Tylko spekuluję, nie jestem pewien, czy można to zrobić w locie.
@computercarguy, Powiedziałbym, że to rzadki program, który nalega na pisanie aktualizacji podczas zamykania (z wyjątkiem prawdopodobnie wszystkiego, co używa sqlite lub czegoś podobnego, ale np. Zwykłe narzędzia wiersza poleceń nie wchodzą w to). W każdym razie to, o czym mówię, byłby programem zbudowanym właśnie w tym celu i poprosiłby o twardy i natychmiastowy restart, a nie zamknięcie przestrzeni użytkownika.
@ilkkachu,, jeśli ma system logowania podobny do systemu Windows, będzie chciał napisać dziennik, w którym będzie można przeczytać, dlaczego nastąpiło zamknięcie. Jeśli nie jest to poprawnie obsługiwane przez obecny układ dysku, możesz przypadkowo nadpisać część plików systemowych lub po prostu być łagodnym wpisem w środku tego, co powinno być białymi znakami. Może również istnieć automatyczna aktualizacja działającego systemu operacyjnego, która uruchamia się po ponownym wyświetleniu, powodując ten sam typ problemu. Chodzi o to, że jako użytkownik nie masz takiej kontroli, jak myślisz.
@computercarguy, tak, miałem ukryte założenie lub system Linux (wierzę, że jest to raczej coś, co jest dość powszechnie używane na Raspberry i innych podobnych urządzeniach). Oczywiście nie wszyscy używają Linuksa i takie rzeczy _zależą_ od systemu operacyjnego, ale tak samo jest z systemem operacyjnym z pamięci RAM.
@computercarguy,, ale jeśli chodzi o aktualizacje automatyczne i tym podobne, zwróć uwagę, że powiedziałem _ „zapobiegaj uruchamianiu innych procesów” _.
@ilkkachu „zapobiega uruchamianiu innych procesów”, zwykle nie jest to takie proste, jak się wydaje. Co się dzieje, gdy proces wymagany do uruchomienia czyszczenia i ponownego obrazu wymaga również innego procesu, który wymaga innego procesu (w nieskończoność), który ostatecznie chce coś zapisać na dysku? Jest to zbyt powszechne i często trudne do obejścia lub skutecznego przepisania, gdy zmienią się wymagania procesu w systemie operacyjnym. Warto o tym pomyśleć, a nie gwarancja, że ​​to nie zadziała.
Roger Jones
2019-06-25 13:45:15 UTC
view on stackexchange narkive permalink

Jak wskazano w innym miejscu, dd -ing na działającym systemie operacyjnym nigdy nie jest dobrym pomysłem. Alternatywą (i zwykłym sposobem tworzenia systemów wbudowanych) jest udostępnianie obrazu systemu operacyjnego z dysku sieciowego, a płyta docelowa wykonuje rozruch sieciowy. Przyspiesza to początkowy rozwój i musisz tylko wypisywać karty SD, gdy zbliżasz się do ukończenia i musisz przetestować na rzeczywistym sprzęcie.

Jest wzmianka o ustawianiu PI3B i PI3B + do rozruchu z serwer na stronach Foundation: https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/net_tutorial.md

W moim przypadku dd -ing na działającym systemie operacyjnym nie spowodował żadnych problemów
Uważaj, to trochę tak, jakbyś mówił, że często jeździsz po pijanemu i nie masz żadnych problemów, albo chodzisz po schodach cały czas w ciemności i nie masz żadnych problemów, itp. Jest to trochę inne niż te rzeczy że kiedy coś pójdzie nie tak, nie będziesz miał okazji na to zareagować. OTOH, nie odniesiesz obrażeń ani nie zostaniesz zabity, więc „działa, dopóki nie” może być w porządku z Twoim przepływem pracy.
Jest to podobne do techniki używanej przez ludzi do uruchamiania narzędzi takich jak nwipe do bezpiecznego wymazywania całego dysku twardego: https://github.com/martijnvanbrummelen/nwipe/
Jeremiah Rose
2019-06-25 13:26:20 UTC
view on stackexchange narkive permalink

Używaj ostrożnie

To działa w moim przypadku, ponieważ używam głównego systemu plików tylko do odczytu z niestandardowym systemem Buildroot. Ten skrypt nie był jeszcze testowany na Raspbian, ale prawdopodobnie będzie działał. 

  #! / Bin / bashset -eecho "Kopiowanie obrazu do RPi ..." sshpass -p HASŁO scp / PATH /TO/SDCARD.img USER @ RPI: /tmp/sdcard.imgecho "Wgrywanie obrazu do / dev / mmvblk0 na RPi ..." sshpass -p HASŁO ssh USER @ RPI 'nice -20 sudo sh -c "sync && dd if = / tmp / sdcard.img of = / dev / mmcblk0 conv = fdatasync && reboot -f "'

Powinien być uruchomiony na komputerze hosta ( nie RPi) i wykonuje następujące czynności:

  1. Kopiuje obraz SD do RPi przez scp
  2. Loguje się do RPi przez ssh
  3. Synchronizuje wszystko oczekujące operacje zapisu systemu operacyjnego na kartę SD
  4. Ustawia priorytet na -20, aby zapobiec uruchomieniu innych procesów
  5. Przesyła obraz na kartę SD, a następnie fdatasync
  6. Wykonuje twardy reset

Ograniczenia:

  • Jeśli dane są zapisywane na karcie SD przez inny proces podczas działania skryptu , SD może stać się corru pted. W ciągu kilku dni aktywnego użytkowania nie spotkałem się jeszcze z tym - ale nie używam Raspbian.
  • Upewnij się, że używasz tego skryptu tylko do programowania / testowania, a nie do aktualizacji systemu operacyjnego lub innego aplikacje wrażliwe na dane.
  • Można zastosować pewne ulepszenia, aby jeszcze bardziej uniemożliwić innym procesom dostęp do karty SD - mile widziane sugestie.

Do użycia:

  1. Skopiuj powyższy skrypt do pliku flash.sh na swoim komputerze głównym
  2. Wprowadź ustawienia dotyczące hasła, nazwy użytkownika i obrazu SD etc
  3. Ustaw go jako wykonywalny za pomocą chmod a + x flash.sh
  4. Zainstaluj sshpass i ssh na hoście: sudo apt install sshpass openssh
  5. Upewnij się, że logowanie ssh działa na RPi
  6. Uruchom ./flash.sh
Są przypadki, w których obraz jest cięższy niż wspomnienie chrapliwego, co możemy zrobić w takich przypadkach?
Tak, te przypadki wydają się niemożliwe do obejścia
Monty Harder
2019-06-26 02:43:49 UTC
view on stackexchange narkive permalink

Użyj karty SD wystarczająco dużej, aby pomieścić wiele partycji

Karta SD powinna zawierać partycję rozruchową (0) i trzy partycje systemu operacyjnego (1-3).

Program ładujący na partycji rozruchowej sprawdziłby etykiety partycji, aby określić, co załadować. Załóżmy, że są to etykiety:

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

Program ładujący wie, że należy załadować system operacyjny z partycji 1, ponieważ jest to ostatnia etykieta, gdy są sortowane. Pierwsza etykieta systemu operacyjnego to partycja 2, do której zapisuje aktualizację

2: OS-0005_

To jest teraz ostatnia etykieta, ale flaga podkreślenia informuje program ładujący, że jest to pierwsza próba załadowania z niego. Zmienia etykietę, aby wskazać, że wykonuje rozruch testowy tuż przed połączeniem się z nim:

2: OS-0005? Jeśli system operacyjny pomyślnie uruchomi się i przejdzie własne testy poprawności, zaktualizuje etykietę jeszcze raz, a także etykietę poprzedniej partycji systemu operacyjnego: 1: OS-0004 2: OS-0005!

Jeśli to się nie powiedzie, przy następnej próbie uruchomienia zostanie wyświetlony symbol? flagę i przywróć ładowanie z partycji 1, po czym aktualizacja rozpocznie się od nowa.

Wydaje się, że to interesujący zarys, ale czy masz jakieś szczegóły, jak to zrobić?
Sam tego nie zrobiłem, ale wiem, że programy ładujące są zdolne do tego. System Google Chromebook jest podobny, ponieważ ma partycję rozruchową, co najmniej dwie partycje systemu operacyjnego i partycję przestrzeni użytkownika, dzięki czemu aktualizacje są zawsze stosowane na partycji systemu operacyjnego, z której system _nie_ się nie uruchamia.
Ronny Nilsson
2019-07-24 17:56:04 UTC
view on stackexchange narkive permalink

Wszystkie Twoje wymagania są już dostępne w mojej dystrybucji Nard SDK. Działa z pamięci RAM i są gotowe skrypty do zdalnej aktualizacji obrazu.
http://www.nard.se/

Niezły projekt! Mam pytanie: większość [przykładów] (http://www.nard.se/examples.html) wygląda na rzeczy, które są również wykonywane z RPi / Raspbian, więc nie mam jasności co do zalety Twojego systemu (Nard). Czy edytować odpowiedź, aby ją rozwinąć?
@Seamus Tam, gdzie świeci Nard, jest przeznaczony dla produktów o dużej objętości. Załóżmy na przykład, że budujesz jakąś maszynę z osadzonym Pi. Maszyna jest następnie sprzedawana w ponad 100 egzemplarzach. Brak takich produktów użytkownika na stronie ma charakter polityczny. Producenci nigdy nie zgadzają się zostać referencją. :(
Timothy Baldwin
2019-06-26 23:35:17 UTC
view on stackexchange narkive permalink

Oto przybliżone podejście:

  1. Zastąp / sbin / init narzędziem do aktualizacji.
  2. Powiedz initowi, aby sam się ponownie wykonał.
  3. Zabij wszystkie pozostałe procesy (na przykład z kill -9-1 )
  4. Użyj pivot_root i chroot , aby zastąpić root system plików.
  5. W razie potrzeby exec następny etap usuwania odwołuje się do starego katalogu głównego.
  6. Rekurencyjnie odmontuj stary katalog główny.
  7. Napisz nowy obraz.
  8. Uruchom ponownie.
Benjamin Collins
2019-10-29 06:36:18 UTC
view on stackexchange narkive permalink

Myślałem o czymś podobnym do testowania rozwoju / wdrażania ze świeżej instalacji Raspbian. Moje obecne myślenie to konfiguracja z podwójną kartą SD i napędem USB. Tak więc przy każdym rozruchu pi najpierw ładuje się do karty SD, przesyła nową instalację na dysk USB, a następnie chrootuje do napędu USB, aby uruchomić system operacyjny.

Chociaż jest to tylko tekst , myślałem o tym tylko koncepcyjnie podczas ręcznego flashowania kart SD z innymi urządzeniami. Więc chyba powinienem zacząć przyglądać się implementacji ..



ⓘ
To pytanie i odpowiedź zostało automatycznie przetłumaczone z języka angielskiego.Oryginalna treść jest dostępna na stackexchange, za co dziękujemy za licencję cc by-sa 4.0, w ramach której jest rozpowszechniana.
Loading...