tux

Masz dwa wyjścia: [*]Sprawdzić co poszło nie tak - Linux na 100% coś napisał a nawet jak nie to można przeedytować skrypt by coś napisał :) [*]Użyć gotowca: http://forum.xunil.pl/index.php?topic=871.msg15943#new

Musisz zrobić restart lub: zabić evremote2 zabić lircd odpalić lircd odpalić evremote2 z & na końcu Paczka na czas kiedy jest zainstalowana podmienia pliki na systemie. Tu nie ma przełączników bo po co? Po deinstalacji paczki system wraca na domyślny tryb obsługi pilota. Podobnie jest ze sterownikami np. WiFi czy DVB-T. Instalujesz sterownik i tyle. Nie trzeba nic ustawiać i wybierać.

Zrestartować boxa :)

XMP-Long tak. Póki co nie zaimplementowane jeszcze u nas.

Brak 100% kompatybilności z XMP. Możesz wgrać obsługę RAW. Poczytaj o OPKG. Możesz też wymienić czytnik IR/Pilota.

Chodzi o wyłączenie obsługi sieci czy danego kontrolera?

Dlatego obawiam, że to będzie w najlepszym razie robota na długie zimowe wieczory lub nawet niemożliwa do wykonania. Piszę o linii 3.x.x oczywiście :)

Zamiary zamiarami a oficjalne pacze to oficjalne pacze. Jeszcze nie wiem co da się zrobić i czy takie coś jak np. player2 bez ALE poleci na linii 3.x.x Na początek na 100% będzie linia 2.x.x i przygotowanie tego po naszemu czyli jajko + moduły "core" + moduły dodatkowe + generator initrd. Zapewne skończy się też poprawką env. Ale co tam...to ma działać po naszemu :) Może bardziej powinienem napisać - po Linuxowemu :)

Dzisiaj zabieram się za porządki Systemu i aktualizację release. Będzie jazda :)

Fakt, może i tak być. Wtedy będzie o tyle problem, że nie pominiemy sterownika sieci. Przynajmniej do czasu kiedy nie posiekam jajka na moduły i nie będę generował initrd per box.

hmm.. WiFi?

Zaktualizować do wersji z TEST. Tam są już nowe skrypty startowe i uruchamiane są tylko interfejsy skonfigurowane w /etc/network/interfaces.

Uwazaj na PIG. CoolTvGuide od ktorejs wersji ma PIG a ten moze skutecznie ukatrupic Twojego Boxa.

Przy okazji - jakiego masz Boxa? SagemCom czy ADB?

mkfs.ext2 -b 4096 -I 128 -L "system" /dev/sda1 Przy czym to dla partycji systemowej a nie SWAP :)

Kolejność parametrów nie ma znaczenia.

Nie widzę nic niepokojącego na żadnym z podanych kanałów.

Ja dodam, ze bledy rowniez tworza sie podczas zlego wylaczania systemu czy zawieszania sie. Wczesniej nie bylko kontroli systemu plikow. Nie wiem jak jest we wszystkich softach ale w pierwszej Graterlia oraz wczesniejszych mod by tux nie bylko kontroli. Nie ma jej tez w czystych kompilacjach TDT. Kumulowanie sie bledow moze doprowadzic w najleprzym przypadku do njestabilnej pracy systemu a w gorszych przypadkach nawet do jego unieruchomienia. Dlatego doposalismy kontrole systemu plikow by uniknac takich zdarzen. Niestety czasem zaskakuje to uzytkownika bo jak pisalem wyzej - tej funkcji nie widzialem wczesniej w tunerach sat.

Stawiam na bledy na hdd. Sprawdz czy mozesz zalogowac sie po telnet i naprawic partycje. Poki co u nas jest kontrola dysku a inni ida na y zywial i czesto czyta sie o niestabilnej pracy, zawieszaniu sie itp.

oscam-1.20.server-svn9664 Niestety zakład energetyczny zafundował mi restart serwerowni (ponad 2h brak prądu i UPS nie dał rady) daję nowszego OSCama. Póki co ten siedzi u mnie na serwerze do czasu jak nie poinformuję, że nastąpiła zmiana :) EDIT tux: W załączniku screen z działania OSCama. Działa już 23 dni bez problemów. Testy trwają dalej :) oscam-1.20.server-svn9664.i686.rpm

<< 19 Kwiecień 2014 >> aktualizacja paczek pikon 220x132 dla list @Richter; aktualizacja graterlia-scripts; aktualizacja OScam; aktualizacja graterlia-system-core-metapack; dodanie paczki graterlia-locale-pl; Paczka graterlia-locale-pl będzie sukcesywnie uzupełniana o potrzebne pliki lokali systemowych.

... Pingwiny nie dość, że małe to jeszcze nieloty :) Co do reszty :) Na systemach linuxowych czy sieciach się znam. Nawet całkiem nieźle. Trochę gorzej z innymi dziedzinami ale tu w devel już ładnie się uzupełniamy i każdy "dzierga" w czym dobry się czuje. EDIT tux: Jeszcze tak dla ścisłości. Wyżej wymieniłem to co trzeba jeszcze zrobić. SysVinit to tylko część tego wszystkiego.

Nie mam w sumie ochoty na tłumaczeni totalnych podstaw ale... Do tej pory wszystko było w jednym pliku rcS (no prawie wszystko). Normalnie w Linuxie masz dostępne tak zwane levele ładowania. Standardowo jest ich 6. Możesz w nich włączyć lub wyłączyć skrypty startowe, które ładowane są w określonej kolejności. Tu też nie będę się zagłębiał co i jak. W skrócie - dzięki tym założeniom możliwe jest praktycznie bezbolesne doinstalowywanie/deinstalowanie komponentów systemu bez konieczności co chwilę edycji pliku rcS czy innych startowych. Nad wszystkim czuwa odpowiednie oprogramowanie. Przykład zastosowania jest bardzo prosty. Instalujesz transmission. OPKG ładuje pliki gdzie trzeba, chkconfig dodaje transmission do runlevel zgodnie z założeniami...wystarczy wpisać: /etc/init.d/transmisstion start/stop/inne Po dodaniu go automatem do określonego runlevel (np. 3 czy 5) jeżeli też runlevel jest okreslony w pliku /etc/inittab automatem system zaaduje Ci transmision podczas startu systemu. Ty nie musisz tykać tego palcem. OPKG deinstaluje a chkconfig usuwa z runlevel informacje i system już nie wie nic o transmission a działa dalej. Kolejne składowe to module-init-tools czyli narzędzie od ładowania modułów podczas startu systemu. Też będzie dostępne w Graterlia. Skończą się kłopoty z ładowaniem modułów i włączeniem ich w PPanel czy szukaniem danego modułu skryptami i ładowanie go jak jest. Do tego będzie moża określać parametry modułów w plikach czyli wreszcie tak jak to jest w normalnych dystrybucjach. Wtykam kartę WiFi i o ile sterownik jest automatem system go ładuje i konfiguruje ta kartę. Podobnie podczas startu systemu. Jak nie ma karty to kulturalnie nic nie jest ładowane bo po co? Dzięki temu nie trzeba będzie pisać skryptów wymyślających jak ładować dany moduł itd. Całość może nie będzie aż tak spektakularnie użyteczna dla zwykłego użytkownika, ale w pewnych fragmentach użyteczności bardzo mu ułatwi życie a osobom z devel team będzie o wiele łatwiej to wszystko składać razem. Do tego dojdzie jeszcze jądro z initrd (tak - też da się odpalić) i wreszcie koniec z tym, że w jądrze na sztywno wkomplowane są wszystkie potencjalnie potrzebne systemy plików czy sterowniki. Będzie małe jądro + ramdysk startowy z tym co niezbędne do zamontowania rootfs (naszego) i uzyskania dostępu do plików na rootfs. Wtedy ramdysk jest usuwany z pamięci a dalsze ładowanie czegokolwiek przebiega już ze struktury rootfs. Czyli np. Sterownik ATA nie musi być w jądrze na sztywno jak system startuje z NAND/NOR. Jak nie mamy HDD to system pominie ten sterownik. Jak mamy to załaduje go module-init-tools podczas startu i tyle. Trochę to skomplikowane ale dzięki temu całość staje się mniej skomplikowana. Przed ostatnie zdanie też mam wrażenie, iż jest zagmatwane :)

Przede wszystkim - czy był update PPanel? → [shadow=red,left]Odpowiadam - nie było :)[/shadow] Dlaczego nie było update PPanel? → [shadow=red,left]ponieważ będzie inna finalna nazwa pliku jak skończę SysVinit. [/shadow]

Stan przejściowy do wprowadzenia SysVinit. W momencie Tworzenia konkretnych skryptów, a właściwie dostosowaniu tych co są, oraz stworzeniu systemu symlinków (chkconfig) skrypty mają "g" w nazwie. Dzięki temu mogę na raz korzystać z obu "systemów" ładowania i wszystko dopracować. Na koniec będzie aktualizacja skryptów + SysVinit + inne potrzebne narzędzia a skrypty dostaną finalne nazwy.