reprapy.pl

Tak dla informacji, nic się nie "przywiesiło". Na Linuksie zawsze po zmianie czegoś z grupami użytkowników trzeba zrestartować system albo chociaż przelogować użytkownika i zrestartować wszystkie usługi które działają na nim. Prościej oczywiście zrestartować cały system.

Kopytko pisze:Teraz jak zainstalowałem to najnowsze, to nie mogłem otworzyć środowiska graficznego przez komende startx. Wywalało ,ze nieznana komenda

I bardzo dobrze

, chociaż sprawdź czy czasem nie ma xinit.

rafaljot pisze:trzeba było trochę poczekać na otwarcie przeglądarki

Otwierałeś przeglądarkę na Pi? Eh czyli miałeś tam zainstalowanego całego desktopa

, nie dziwię się że lagowało. Dalej nie ogarniam po co w octopi jest całe środowisko graficzne

WillingMagic pisze: @dragonn
Skoro ponad 10 lat to np. jak wywalali hal i można było skończyć bez działającej klawiatury, ewentualnie przejście na systemd. Poza tym jak się czasem zrobiło pacman -Syu bez czytania strony archa to też coś mocno pudło.

No no czytać trzeba, to było ironicznie napisane

. Jak integrowali wszystko do jednego bin było podobnie po prostu zawsze wszystko udało mi się przeczytać przed Suy

. Co ciekawe kiedyś mi padł Debian, co prawda testing ale i tak paczka dbus która rozpakowała się do /tmp to była duża wpadka xD, wtedy przeszedłem na Archa.

już koniec offtopu

WillingMagic pisze: Tzn. co napsuć? To nie Arch, że aktualizacja wywraca system do góry nogami.

Ale że co się ma napsuć w Archu

? użytkownika Archa od 10 lat

(sorry musiałem)

A wracając do aktualizacji, również uważam że należy ją w miarę możliwości robić, szczególnie jak coś bazuje na Debianie który pod tym względem rzadko sprawia problemy.

Właśnie gdzieś czytałem że pomimo tego że operujesz na blokach kontroler karty SD dba np. o to żeby jedna komórka nie była zbyt często zapisywana (np. cyklicznie będziesz wykonywał zapis w jeden blok a tak naprawdę kontroler sam sobie to przerzuca po karcie SD żeby rozłożyć obciążenie komórek).

dziobu pisze:Karta SD jest tak samo dobra na system jak CF czy każdy inny flash. Niektóre pamięci są w ogóle na tych samych scalakach; różnią się tylko interfejsem.
A z samymi kartami problemy są dwa:
- Złącze. Niewiele rzeczy jest tak ciulowych jak ono. Jak używasz często - rozpada się. Jak rzadko - śniedzieje i przestaje stykać.
- Obsługa samego protokołu. Karty SD nie są tak prymitywne jak np CF (teoretycznie rzecz jasna, bo CF też nie muszą być proste) i tutaj trzeba zachować pewien standard obsługi. Dotyczy to zarówno czasów, kompletności nastaw np. przy przejściu SPI->SDIO jak i badania statusów które zwraca. Spora część bibliotek z którymi się spotkałem szczerze to olewa. Jeśli karta nie przyjmie rozkazu lub zwróci niestandardowy status to tu całość leży, choć biblioteka działa jak gdyby nigdy nic. Podobnie z trybami oszczędzania energii (niektóre karty same się wygaszają, stąd problemy).

Da się zorganizować pracę tak żeby wyjęcie karty w dowolnym momencie nie powodowało utraty danych i praktykuję to w swoim urządzeniach, ale rpi jest dość szybkie i raczej nie będzie marnowało czasu na takie bzdury.

Używamy kart SD wszędzie gdzie się da, to podpowiem na koniec:
- Jedyne problemy jakie miałem to z niektórymi kartami Kingstona (dodam że do dziś żadna nie przeżyła). Modele "no-name" w ogóle pomijam bo to loteria.
- Sandisk i Goodram - te działają zawsze. Kupuję kartonami, stąd niewielka różnorodność ;p
- Modele Industrial (Sandisk, A-Data) nie mają żadnych cudów; po prostu działają w szerszym zakresie temperatur (zwykła SD może zgłupieć przy -40). Bajery jak diagnostyka (odpowiednik SMART z dysku) czy OTP pomijam, bo to tu bezużyteczne.

Właśnie że karta SD to nie to samo co CF czy inny flash. CF jest kompatybilny z IDE co daje dużo niższy poziom dostępu do nośnika, oczywiście i CF i karta SD posiada w sobie i tak jakiś mikrokontoler ale karta SD dużo bardziej 'ukrywa' pamięć flash przed systemem niż taka CF. Przynajmniej z tego co mi wiadomo (zresztą sam piszesz że karty SD nie są tak prymitywne jak CF)

Co do `organizować pracę tak żeby wyjęcie karty w dowolnym momencie ` to właśnie ciekawe, jak mówiłem robiłem już tak żeby system na Pi pracował jako tylko do odczytu i też się sypało.

Ja mam kilka kart leżeć 'markowych' który w ogóle zablokował się zapis... można formatować ile się chce i jak, po odpięciu i wpięci stare dane wracają

A no to takie coś zepsuje kartę na pewno, możesz tam dograć octopi jak Ci się chce możesz też na nią po prostu wgrać octopi zamiast noobs. BTW jak by ktoś był ciekawy udało mi się znaleźć coś takiego https://www.morele.net/karta-microsd-ki ... p-1073492/

buffer overflow Oo heh to brzmi jak by binarka fsck też uległa uszkodzeniu :/.

Z 2 może nie być, niestety czasem zdarzają się błędy który nie da się naprawić z poziomu aktualnie uruchomionego systemu tylko trzeba naprawić je offline. Przerabiałem ten temat dość intensywnie i po prostu karty SD to kijowy nośnik na system - miałem nawet system który pracował z kartą w trybie read-only i też po czasie miała błędy. Wydaje mi się że to zależy od karty SD, bo niektóre Pi które gdzieś stawiałem chodzą do dziś bez problem a były wyłączane brutalnie co trochę, a niektóre uważałem jak się dało jeden restart i koniec. Zauważyłem że karty SandDisk Extreme sprawdzają się lepiej a ogólnie wydaje mi się że najlepiej kupić sobie kartę przeznaczoną do przemysłu np. Sandisk Industrial ale nie mam pojęcia gdzie je dostać i ile kosztują, wiem że TME chyba jakieś ma.

Znaleziono 14 wyników

Re: OCTOPI - Problem

Re: OCTOPI - Problem

Re: OCTOPI - Problem

Re: OCTOPI - Problem

Re: OCTOPI - Problem

Re: OCTOPI - Problem

Re: OCTOPI - Problem

Re: OCTOPI - Problem

Re: OCTOPI - Problem

Re: OCTOPI - Problem