Graterlia OS [MIPS32EL] - uwagi i błędy

[tux]

Sprawdź na wszelki wypadek HDD.

• odmontuj partycje dysku
  
• fsck -f /dev/sdXY
  

[zielonyBB]

TS zapisuje się u mnie na karcie SD ale puściłem fsck również na hdd:

 

GraterliaOS:~# fsck -f /dev/mmcblk0p1

fsck from util-linux 2.34

e2fsck 1.45.3 (14-Jul-2019)

Pass 1: Checking inodes, blocks, and sizes

Pass 2: Checking directory structure

Pass 3: Checking directory connectivity

Pass 4: Checking reference counts

Pass 5: Checking group summary information

EPG: 773/3838296 files (0.3% non-contiguous), 495297/7674368 blocks

GraterliaOS:~#

 

GraterliaOS:~# fsck -f /dev/sda1

fsck from util-linux 2.34

e2fsck 1.45.3 (14-Jul-2019)

Pass 1: Checking inodes, blocks, and sizes

Inode 15728734 extent tree (at level 1) could be shorter.  Optimize<y>? yes

Inode 15728767 extent tree (at level 1) could be shorter.  Optimize<y>? yes

Pass 1E: Optimizing extent trees

Pass 2: Checking directory structure

Pass 3: Checking directory connectivity

Pass 4: Checking reference counts

Pass 5: Checking group summary information

records: ***** FILE SYSTEM WAS MODIFIED *****

records: 329/19472384 files (13.7% non-contiguous), 46421978/77880406 blocks

GraterliaOS:~#

 

Chyba nic specjalnego nie było zepsute ale TS ożył i działa.

Dzięki.

[mleczyk89]

Witam

 

Po dzisiejszej aktualizacji paczek

nettle

iputils

GLibc

mtr

 

problem podobny jak u przedmówcy.

 

Mam uruchomiony automatyczny TS,  po uruchomieniu dekodera próba zmiany kanału kończy się kręcącym spinerem.

Próba restartu odbiornika lub GUI z menu kończy się spinerem.

 

Wyłączenie automatycznego TS przywraca tunerowi funkcjonalność.

 

Skan dysku za wiele nie wskazał.

 

 

 

Zauważyłem ten problem już kilka miesięcy temu, zazwyczaj jakakolwiek akcja (np zmiana kanału) po update (np list kanałów)  powodowała spiner, ale po restarcie system działał poprawnie.

Obecnie z auto TS nie jest możliwe użytkowanie dekodera, gdyż każda czynność powoduje spiner.

Problem unieruchamiający dekoder tak naprawdę zaczął się dziś po aktualizacji wyżej wymienionych paczek.

[tux]

Ja to mam od grudnia na Vu+ Duo2 i za cholerę nie umiem tego namierzyć o co chodzi.

Wszyscy co pytałem nawet jak wierzyli mi to nie potrafili tego zreprodukowa.

[m2teusz]

U mnie ni z gruchy ni z pietruch GS. Po przeinstalowaniu OS'a nadal to samo. Podejrzenia padły na HDD. A wystarczyło wyłączyć TS.

[tux]

Autostart TS działa od bardzo dawna dziwnie. W zasadzie odkąd pamiętam.

Dlatego zawsze zalecam nieużywanie AutoTS.

Natomiast tryb PAUSE/START zawsze działa OK.

 

Próbuję od dawna znaleźć, co jest przyczyną, ale za nic nie mogę tego namierzyć. W logach po prostu nic niepokojącego nie ma. Wszystko, co wydaje się podejrzane, tak naprawdę jest OK. Nie mam się do czego przyczepić.

Zawsze wygląda to tak samo...

• wstaje E2;
  
• i teraz następuje ileś sekund do startu AutoTS (np. 10sec);
  
• po tym okresie jeżeli jakimś cudem u mnie (Duo2) wstanie 6 procesów E2, to jest OK. Jak wstanie mniej niż 6 procesów — ZWIS.
  

Przetestowałem starsze E2 (mam pełne archiwum) i setki wersji OSCam (też mam archiwum). Efekt jest ten sam.

Nawet powrót do wsadu sprzed np. 1,5 roku nie zmienia faktu. Stąd mój wniosek, że leci z SAT jakiś babol i czasem zdarza się taki tandem kanałów, gdzie akurat zmiana z kanału A tandemu, na kanał B tandemu == ZWIS.

[mleczyk89]

Wymienione w poprzednim poście przeze mnie paczki nie są w żaden sposób powiazane?

 

Ponad rok lub więcej  autoTS działało u mnie dobrze.

 

Jutro z ciekawości przywrócę kopie z przed tygodnia celem sprawdzenia.

Postaram się aktualizować paczki pojedynczo , tak aby wyszło po aktualizacji której pojawia się problem.

[tux]

Niestety, w moim przypadku nie są.

Pakiety są od systemu a nie od E2.

[mleczyk89]

Zgodnie z wcześniejszą informacją przywróciłem kopie z 28.07.2019

AutoTS zaczął działać poprawnie.

 

Aktualizacja paczki nettle 3.5.1

powoduje problem przynajmniej u mnie.

 

 

Iputils nie jest zaktualizowany ze wzlgędu na zależność od nettle

Package: iputils

Version: s20180629-1

Depends: glibc (>= 2.30), libcap-libs (>= 2.27), nettle (>= 3.5.1)

 

Aktualizacja samego nettle 3.5.1 (brak zależności w drugą stronę) unieruchamia dekoder.

Package: nettle

Version: 3.5.1

Depends: glibc (>= 2.30), gmp (>= 6.1.1)

 

 

Poniżej obecnie zainstalowane paczki.

list-installed.txt

[tux]

Napisz to raz jeszcze, aby to zrozumieć. Ja nie potrafię :):)

 

iputils jest wymagany przez E2. Natomiast instalacja samego nettle aktualizuje biblioteki, bez których (w konkretnej wersji) nie zadziała iputils.

Dlatego, albo to iputils powoduje problem co jest raczej mało możliwe ponieważ to tylko służy do ustawiania kontrolera sieciowego w E2, albo nie wiem o co chodzi.

Bez nettle może unieruchomić całą E2.

[mleczyk89]

Mam nadzieje że teraz trochę jaśniej.

 

Nettle obecnie w wersji 3.4.1,    aktualizacja nettle do 3.5.1 powoduje problem.

 

iputils w wersji 20180629    nie zaktualizowane do s20180629-1 ze względu na konieczność aktualizacji nettle.

[tux]

• aktualizacja systemu
  
• mv /bin/ping /bin/ping_
  
• restart gui
  
• raport
  

Nic innego poza ping nie używa nettle.

[mleczyk89]

Doinstalowalem Midnight Commander bo nie miałem.

 

Jaką akcje powinna wykonać komenda

mc /bin/ping /bin/ping_ ?

Odpala mc ale nie widzę nic poza tym.

 

Po restarcie Gui wszystko działa jak powinno, a przynajmniej nie mam spinera po wykonaniu jakiejkolwiek czynności. AutoTS wydaje się również działać poprawnie.

[tux]

Przepraszam. Mój błąd. Nie mc a mv.

[mleczyk89]

Wychodzi na to ze poprzednie funkcjonowanie to przypadek / loteria. Po restarcie gui oczywiście spiner przy zmianie kanału.

Po zmianie nazwy paczki komendą mv /bin/ping /bin/ping_  i restarcie gui również spiner.

Po restarcie odbiornika nawet działa, do kolejnego restartu GUI. Po restarcie GUI spiner przy zmianie kanału.

Kolejny restart odbiornika i od razu spiner przy zmianie kanału.

 

Przywrócenie kopii z przed aktualizacji nettle  przywraca działanie.

 

Powtórzyłem całą procedurę(która zakończyła się spinerem) i kolejne przywrócenie tej samej kopii i niestety już nie działa.

"Nettle" nie jest problemem, a całe zachowanie jest mocno loteryjne.

 

Wychodzi na to ze całość odnosi się do tego co napisałeś z uruchamianiem procesów.

 

Zastanawiało mnie wyłącznie czemu zaczęło się to dziać po aktualizacji,  ale kilka prób rozwiało wątpliwości. Przed aktualizacją również jest ten problem.

 

 

[tux]

Sprawa jest dość dziwna.

Wszystko u mnie zaczęło się (wykryłem) 02.01.2019. Wtedy pierwszy raz powiesiłem tuner i miałem coś ala pętla śmierci. Ani restart tunera, ani GUI nie pomagał. Zmiana kanału i BOOOM.

Żyłem z tym od tego czasu aż do wczoraj (przynajmniej testy robiłem wczoraj). Od wczoraj (i jak narzie nadal) nie mam efektu.

 

Co w międzyczasie sprawdziłem?

• wykluczyłem dysk (jest od stycznia 2019 nowy SSD);
  
• wykluczyłem sam soft — cofnięcie się nawet do stycznia 2018 nie zmieniło faktu;
  
• wykluczyłem OSCam — cofnięcie się do wersji se stycznia 2018 i późniejszych nie przyniosło efektu;
  

Skoro ani soft, ani Oscam cofając się nawet o rok, nie poprawił stanu rzeczy,  to musiało być to coś innego.

Paradoks na razie jest taki, że jak u mnie występował efekt uboczny, to nikomu nie udało się go z reprodukować. Teraz efekt jest powtarzalny u co najmniej trzech osób, ale u mnie zaniknął.

Jedyny wniosek jaki przychodzi mi do głowy to jakies manerwy na orbicie. Efekt czasem jest, czasem go nie nie ma.

Nie rozumiem jedynie w tym wszystkim jednego ← dlaczego efektu nie ma, jeżeli uda się za pierwszym razem zmienić kanał na inny, po tym, jak już uruchomi się AutoTS. Jeżeli to nastąpi to mamy spokój do kolejnego restartu tunera/GUI.

Mam jeszcze jedną hipotezę...grzebali coś z EPG, ogólnie, bo i CP, NC+, ale również np.. SKY. Być może na niektórych kanałach jest nadawane coś nie tak i w efekcie bardzo dużo zależy od tego, kiedy przełączymy się z kanału na kanał.

 

Tak czy inaczej...efekt jest (u mnie obecnie był) i nie mam pomysłu na to, co się dzieje.

Logi są OK, inne czynniki, które podejrzewałem — wyeliminowałem.

 

Jedyne co zostaje to „uruchomienie myślenia użytkowników”. Zabrzmiało może dziwnie, ale być może ja czegoś nie widzę dlatego, że za dużo już jestem „przesiąknięty” kompilacjami, poprawkami itd. Innymi słowy — potrzeba świeżego, niekoniecznie technicznego myślenia, a może na coś wpadniemy.

[314TeR]

Niestety muszę potwierdzić podobną obserwację.

 

Parę miesięcy temu tux poprosił mnie o sprawdzenie stabilności działania PTS i u mnie nie byłem w stanie zreprodukować problemu. Od paru miesięcy miałem non-stop działający PTS i ani jednej zwiechy do aktualizacji w ostatnie weekend. Bum i 95% startów systemu z uruchomionym PTS powodowało padnięcie E2 (spinner) przy pierwszej próbie przełączenia kanału. Co ciekawe, jak np PTS był ustawiony na 10s to przez pierwsze parę sekund zanim zaczął tworzyć się plik dało się przełączyć kanał. Dopiero jak rozpoczął się zapis i następowała próba przełączenia kanału był zwis, ale tylko E2. Po ubiciu i restarcie w konsoli dawało radę dalej robić testy.

 

Ja osobiście stawiam na jakiś babol na styku E2 <-> system. Może to kwestia obsługi ilości plików do zapisu? Open Files? Może to wcale nie wina E2 a np jakaś kombinacja np kompilacja kernela vs jakieś pakiety systemu.

 

 

[tux]

U mnie sprawa jest taka, że cofnięcie się o miesiąc albo trzy nie powoduje efektu. Zjawisko było i już go nie ma.

Kopie systemu mam robioną co najmniej raz w tygodniu (średnio). Po prostu od stycznia do zeszłego weekendu bylo to zjawisko powszechne u mnie. Teraz, nawet na kopii sprzed iluś tygodni/miesiecy wywołać tego nie potrafię.

 

Jak możecie, to sprawdźcie oscam-longterm.

Najnowszy OSCam, to jedyne czego nie sprawdzałem, a grzebali tam w dvbapi.

[mleczyk89]

Ja korzystam z wersji longterm.

To nie to :)

[tux]

Zaczynam mieć coraz większą pewność, że operatorzy coś szykują.

[AbrahaM]

Proponuję do testu "odwrotne podejście", użycie najnowszej wersji OSCam, ze względu na szereg zmian w obsłudze strumieni. Może to coś poprawi.

[tux]

U mnie nie poprawi chwilowo nic. Jak pół roku doprowadzało mnie to do szału tak teraz za diabła nie chce się zepsuć :)

[mleczyk89]

Proponuję do testu "odwrotne podejście", użycie najnowszej wersji OSCam, ze względu na szereg zmian w obsłudze strumieni. Może to coś poprawi.

 

W moim przypadku jednyną zmiana jest dłuższe oczekiwanie na obraz po zmianie kanału na najnowszym Oscam z repo.

 

[m2teusz]

Nie wiem czy to coś wniesie ale od pewnego momentu obserwuje dropp'y na dwóch boxach, pewności nie mam ale tak chyba zaczęło się dziać po któreś aktualizacji

 

salon:~# ifconfig

eth0      Link encap:Ethernet  HWaddr 00:17:9a:23:bd:7e

          inet addr:192.168.1.20  Bcast:192.168.1.255  Mask:255.255.255.0

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:113206 errors:0 dropped:23 overruns:0 frame:0

          TX packets:124822 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:1000

          RX bytes:13894094 (13.2 MiB)  TX bytes:16272631 (15.5 MiB)

 

sypialnia:~# ifconfig

eth0      Link encap:Ethernet  HWaddr 00:17:9a:23:bd:93

          inet addr:192.168.1.30  Bcast:192.168.1.255  Mask:255.255.255.0

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:26074 errors:0 dropped:22 overruns:0 frame:0

          TX packets:17645 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:1000

          RX bytes:2300654 (2.1 MiB)  TX bytes:1199897 (1.1 MiB)

[mleczyk89]

Wczoraj wyłapałem kolejny problem.

 

Nie działa webif.

Przy próbie wejścia we wtyczki dostaje komunikat ostrzeżenia

 

Openwebif cannot import name version

 

Oscam Gos-webif oraz wtyczka openwebif reinstalowane bez rezultatu.

 

Na wersji longterm oscama to samo.

[tux]

Odinstalować z wymuszeniem python-twiated i zainstalować ponownie.

[m2teusz]

openssh - 8.1p1 - An open source implementation of SSH protocol version 2 (core files) install openssh-clients, openssh-server, or both.

 

Działa bardzo niestabilnie a raczej nie działa.  Połączenie możliwe 1/10 jak nie gorzej.

[tux]

Niech ktoś to potwierdzi. U mnie działa OK.

[m2teusz]

Niech ktoś to potwierdzi. U mnie działa OK.

 

u mnie na dwóch box'ach to samo dopiero zainstalowanie poprzedniej wersji openssh - 8.0p1 usunęło problem.

[tux]

U mnie na Vu+ Duo2, Vu+ Zero, H3, i55 jest OK.

Dlatego proszę, aby ktoś to potwierdził lub zaprzeczył.

[pietrek]

U mnie jest wszystko OK.

[JaGrab3]

formuler, wszystko działa OK

[zielonyBB]

Zgemma H2S (GOS aktualny):

 

1. Nie da się połączyć po SSH (Network error: Connection refused) - a dzisiaj rano jeszcze aktualizowałem z terminala listy i pikony

2. TS i nagrania planowe działają poprawnie

 

Edit: po twardym restarcie Zgemmy połączenie SSH wróciło (zainstalowany openssl 1.1.1d)

[314TeR]

VU+ Solo2 wszystko działa po kluczu SSH jak powinno.

[m2teusz]

ponownie zaktualizowałem ssh i problem znów wrócił

 

Microsoft Windows [Version 10.0.18362.418]

© 2019 Microsoft Corporation. Wszelkie prawa zastrzeżone.

 

C:\Users\m2teusz>ssh root@192.168.1.20

Connection closed by 192.168.1.20 port 22

 

C:\Users\m2teusz>ssh root@192.168.1.20

Connection closed by 192.168.1.20 port 22

 

C:\Users\m2teusz>ssh root@192.168.1.20

Connection closed by 192.168.1.20 port 22

 

C:\Users\m2teusz>ssh root@192.168.1.20

Connection closed by 192.168.1.20 port 22

 

C:\Users\m2teusz>ssh root@192.168.1.20

Connection closed by 192.168.1.20 port 22

 

C:\Users\m2teusz>ssh root@192.168.1.20

Connection closed by 192.168.1.20 port 22

 

C:\Users\m2teusz>ssh root@192.168.1.20

Connection closed by 192.168.1.20 port 22

 

C:\Users\m2teusz>ssh root@192.168.1.20

Connection closed by 192.168.1.20 port 22

 

C:\Users\m2teusz>ssh root@192.168.1.20

Connection closed by 192.168.1.20 port 22

 

C:\Users\m2teusz>ssh root@192.168.1.20

Connection closed by 192.168.1.20 port 22

 

C:\Users\m2teusz>ssh root@192.168.1.20

Connection closed by 192.168.1.20 port 22

 

C:\Users\m2teusz>ssh root@192.168.1.20

Connection closed by 192.168.1.20 port 22

 

C:\Users\m2teusz>ssh root@192.168.1.20

Connection closed by 192.168.1.20 port 22

 

C:\Users\m2teusz>ssh root@192.168.1.20

root@192.168.1.20's password:

 

tak wiec nie wiem od czego to zależy skoro inny działa

 

a i po ostatniej aktualizacji wyskakuje takie cudo:

 

sypialnia:~# opkg upgrade

Not selecting sqlite3 3.29.0 as installing it would break existing dependencies.

Not selecting openssh 8.0p1 as installing it would break existing dependencies.

 

[314TeR]

Odpalasz SSH pod windows? Spróbuj z putty.

[m2teusz]

Odpalasz SSH pod windows? Spróbuj z putty.

 

przeinstalowałem obraz i nadal to samo czy to w10 czy linux

 

Microsoft Windows [Version 10.0.18362.418]
(c) 2019 Microsoft Corporation. Wszelkie prawa zastrzeżone.

C:\Users\m2teusz>ssh root@192.168.1.20
root@192.168.1.20's password:
Last login: Sun Nov  3 21:53:11 2019 from 192.168.1.101

    ________              __              .__  .__.
    /  _____/___________ _/  |_  ___________|  | |__|____
  /  \  __\_  __ \__  \\  __\/ __ \_  __ \  | |  \__  \
  \    \_\  \  | \// __ \|  | \  ___/|  | \/  |_|  |/ __ \_
    \______  /__|  (____  /__|  \___  >__|  |____/__(____  /
          \/          \/          \/                  \/

salon:~# ssh 192.168.1.30
Connection closed by 192.168.1.30 port 22
salon:~# ssh 192.168.1.30
root@192.168.1.30's password:
Last login: Sun Nov  3 21:57:54 2019 from 192.168.1.20

    ________              __              .__  .__.
    /  _____/___________ _/  |_  ___________|  | |__|____
  /  \  __\_  __ \__  \\  __\/ __ \_  __ \  | |  \__  \
  \    \_\  \  | \// __ \|  | \  ___/|  | \/  |_|  |/ __ \_
    \______  /__|  (____  /__|  \___  >__|  |____/__(____  /
          \/          \/          \/                  \/

sypialnia:~#

 

w salonie stara wersja ssh nie aktualizowania,

 

z dobrych wieści Time-Shift działa poprawnie oraz zakończenie nagrywania nie kończy się spinerem ;-)

[pietrek]

Użyj putty do połączeń.

W wolnej chwili sprawdzę ten win10 ale putty działa bez zarzutu.

 

https://www.chiark.greenend.org.uk/~sgtatham/putty/latest.html

[m2teusz]

Użyj putty do połączeń.

W wolnej chwili sprawdzę ten win10 ale putty działa bez zarzutu.

 

niestety połącznia box - box nie zrealizuje za pomocą putty

 

salon:~# ssh 192.168.1.30
Connection closed by 192.168.1.30 port 22

[314TeR]

m2teusz[/member] napisz dokładnie co chcesz zrobić.

 

Masz w dekodery w domu? Oba na Graterlia i chcesz z roboczo nazwijmy to G1 połączyć się z G2?