abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×

dnes 11:33 | IT novinky

Red Hat kupuje společnost Codenvy stojící za stejnojmenným webovým (cloudovým) integrovaným vývojovým prostředím (WIDE) postaveném na Eclipse Che.

Ladislav Hagara | Komentářů: 0
dnes 08:55 | Nová verze

V listopadu 2014 byl představen fork Debianu bez systemd pojmenovaný Devuan. Po dva a půl roce jeho vývojáři oznámili vydání první stabilní verze 1.0. Jedná se o verzi s dlouhodobou podporou (LTS) a její kódové jméno je Jessie, podle planetky s katalogovým číslem 10 464.

Ladislav Hagara | Komentářů: 6
včera 20:22 | Zajímavý článek

Nadace Raspberry Pi vydala již osmapadesáté číslo (pdf) stostránkového anglicky psaného časopisu MagPi věnovanému Raspberry Pi a projektům postaveným na tomto jednodeskovém počítači a druhé číslo (pdf) časopisu Hello World primárně určeného pro učitele informatiky a výpočetní techniky.

Ladislav Hagara | Komentářů: 0
včera 19:55 | Humor

Portál Stack Overflow informuje na svém blogu, že pomohl ukončit editor Vim už více než milionu vývojářů. V loňském roce například hledal odpověď na otázku Jak ukončit editor Vim v průměru 1 z 20 000 návštěvníků.

Ladislav Hagara | Komentářů: 10
včera 19:22 | Nová verze

Po pěti měsících od vydání verze 3.5.0 byla vydána nová stabilní verze 3.6.0, tj. první z nové řady 3.6, minimalistické linuxové distribuce zaměřené na bezpečnost Alpine Linux (Wikipedie). Z novinek lze zmínit například podporu dvou nových 64bitových platforem little-endian POWER machines (ppc64le) a IBM z Systems (s390x) nebo nové balíčky Rust 1.17.0, Cargo 0.18.0, GHC 8.0.2 a Julia 0.5.2.

Ladislav Hagara | Komentářů: 0
24.5. 21:33 | Bezpečnostní upozornění

V Sambě byla nalezena a opravena bezpečnostní chyba CVE-2017-7494. Má-li útočník právo ukládat soubory na vzdálený server, může tam uložit připravenou sdílenou knihovnu a přinutit smbd server k jejímu načtení a tím pádem ke spuštění libovolných příkazů. Chyba je opravena v upstream verzích 4.6.4, 4.5.10 a 4.4.14. Chyba se týká všech verzí Samby od verze 3.5.0 vydané 1. března 2010.

Ladislav Hagara | Komentářů: 5
24.5. 20:44 | Nová verze

Byla vydána nová stabilní verze 4.3.0 integrovaného vývojového prostředí (IDE) Qt Creator. Z novinek lze zmínit například integraci editoru kódu do Qt Quick Designeru.

Ladislav Hagara | Komentářů: 1
24.5. 20:11 | Bezpečnostní upozornění

Společnost Check Point informuje na svém blogu o novém vektoru útoku. Pomocí titulků lze útočit na multimediální přehrávače VLC, Kodi, Popcorn Time, Stremio a pravděpodobně i další. Otevření útočníkem připraveného souboru s titulky v neaktualizovaném multimediálním přehrávači může vést ke spuštění libovolných příkazů pod právy uživatele. Ukázka na YouTube. Chyba je opravena v Kodi 17.2 nebo ve VLC 2.2.6.

Ladislav Hagara | Komentářů: 11
23.5. 15:18 | Zajímavý software

CrossOver, komerční produkt založený na Wine, je dnes (23. 5. 2017) dostupný ve slevě. Roční předplatné linuxové verze vyjde s kódem TWENTYONE na $21, resp. $1 v případě IP z chudších zemí. Firma CodeWeavers, která CrossOver vyvíjí, významně přispívá do Wine. Přidaná hodnota CrossOver spočívá v přívětivějším uživatelském rozhraní, integraci do desktopu a podpoře.

Fluttershy, yay! | Komentářů: 26
23.5. 15:11 | Zajímavý projekt

V únoru loňského roku bylo představeno několik útoků na celou řadu bezdrátových klávesnic a myší s názvem MouseJack. Po více než roce lze chybu opravit, tj. aktualizovat firmware, také z Linuxu. Richardu Hughesovi se podařilo navázat spolupráci se společností Logitech, získat od nich dokumentaci, přesvědčit je, aby firmware poskytovali přímo a ne jako součást .exe souboru, aby mohl být popis začleněn do služby Linux Vendor Firmware Service (LVFS) a aktualizace tak mohla proběhnou přímo z Linuxu pomocí projektu fwupd.

Ladislav Hagara | Komentářů: 2
Chystáte se pořídit CPU AMD Ryzen?
 (6%)
 (32%)
 (1%)
 (8%)
 (44%)
 (9%)
Celkem 620 hlasů
 Komentářů: 62, poslední 19.5. 01:57
    Rozcestník

    Dotaz: Špatně zabalené CPIO

    16.1.2013 21:36 joseff | skóre: 4
    Špatně zabalené CPIO
    Přečteno: 584×
    Dobrý den,

    již dlouho řešíme jeden problém v našem open source projektu.

    Provádíme aktualizaci Firmware do jednoho set-top-boxu, aby mohl přijímat HDTV a IPTV.

    Napřed byl problém tento balíček rozbalit. To se po delší době povedlo.

    Ale nyní je opačný problém.

    Rozbalíme ho, provedeme úpravu, zabalíme, do boxu se překopíruje, ale před rozbalením to vypíše, že nesouhlasí kontrolní součet, nic nerozbalí a tím šou končí, box je zatuhlý, dokud se neprovede reboot.

    Pokud se do boxu nahraje ta samá verze, ale bez našeho zásahu, tak jí tam rozbalí a perfektně funguje, pouze do ní není přístup ani přes konzoli, protože to chce heslo pro root.

    To znamená, že program (Firmloader napsaný asi ve Visual Basicu) který k překopírování používáme, funguje, zde chybu nehledat.

    Ale pokud to rozbalíme, neuděláme žádný zásah a opět zabalíme, tak tato verze nefunguje.

    Ta chyba je určitě na naší straně.

    1) moc tomu nerozumíme

    2) nepoužíváme čistě Linux, ale Windows a v něm přes nějaký emulátor nebo něco podobného Linux, takže i zde je hodně příležitostí pro chyby

    - buď nevhodná verze Linuxu, nebo nevhodná nebo starší verze zabalovacího programu

    Je možno nějak zjistit, pomocí jakého programu, jakou verzí a s jakým nastavením to bylo zabaleno?

    Zde to řešíme, jsou tam volně ke stažení všechny potřebné soubory a naše poznatky a výpis z konzole:

    http://forum.ican3800.zajsoft.net/viewtopic.php?f=5&t=309

    Pokud někdo tuší, jak na to, tak to může též zkusit rozbalit, nebo použít již rozbalené,

    v souboru /etc/shadow odstranit řetězec (heslo) pro root, zabalit a nahrát třeba na uloz.to.

    Já to otestuji a budu informovat, co to dělá.

    Předem děkuji za pomoc.

    Řešení dotazu:


    Odpovědi

    Jendа avatar 16.1.2013 21:48 Jendа | skóre: 73 | blog: Výlevníček | JO70FB
    Rozbalit Rozbalit vše Re: Špatně zabalené CPIO
    Rozbalíme ho, provedeme úpravu, zabalíme, do boxu se překopíruje, ale před rozbalením to vypíše, že nesouhlasí kontrolní součet, nic nerozbalí a tím šou končí, box je zatuhlý, dokud se neprovede reboot.
    Hele, já nevím, ale tohle by podle mě mohlo znamenat, že nesouhlasí nějaký kontrolní součet.

    Ten FW si nejspíš někde v tom archivu drží ještě checksum a ta pochopitelně po změně nesouhlasí. Musíš zjistit, kde ta checksum je a jak ji přepočítat, nebo alternativně v tom flasheru najít, kde se kontroluje, a zařídit, aby se nekontrolovala. Možná by pomohlo zjistit, kdo že vypíše tu hlášku o nesouhlasícím součtu. Pokud je to ten flasher, od kterého máš zdrojáky, tak to tam prostě zakomentuj.
    16.1.2013 22:00 joseff | skóre: 4
    Rozbalit Rozbalit vše Re: Špatně zabalené CPIO
    Ano, přesně toto víme již 2 měsíce, bohužel vůbe netušíme, co s tím. Hodně pokusů se zabalením bylo provedeno, ale žádný úspěch.

    Na ABCLINUXU jsem se obrátil až nyní, protože již dál nevíme a projekt tímto bohužel končí.

    Což by byla škoda, protože nějaká ta stovka uživatelů tohoto boxu doufá v novou verzi. Bohužel nikdo z těch uživatelů nám nepomohl, protože se jedná o běžné uživatele.
    Jendа avatar 16.1.2013 22:18 Jendа | skóre: 73 | blog: Výlevníček | JO70FB
    Rozbalit Rozbalit vše Re: Špatně zabalené CPIO
    Tak kdo hlásí ten špatný kontrolní součet?
    16.1.2013 22:33 joseff | skóre: 4
    Rozbalit Rozbalit vše Re: Špatně zabalené CPIO
    Na set-top-box jsem napíchnut přes konzoli (COM PORT) a putty zobrazuje hlášky z boxu.

    Z PC se to pomocí Firmloaderu překopíruje do set-top-boxu. Po překopírování se Firmloader ukončí. Zatím OK, ale do této doby putty vůbec nic nevypisuje.

    Po rebootu to sice chtělo rozbalit, ale...

    A nyní to teprve začíná psát text:
    RebootLinux version 2.6.11.12_stm20-33 (A.Mielcarek@autogrator1) (gcc version 3.4.3 (STMicroelectronics/Linux Base 3.4.3-19) [build Mar 10 2006]) #1 Wed Sep 8 11:32:36 CEST 2010
    ADB STB initialisation
    STb7100 version 3.x
    Built 1 zonelists
    Kernel command line: console=ttyAS0,115200 splasharea=4096,0x0B000000           
    PID hash table entries: 512 (order: 9, 8192 bytes)
    Calculated peripheral clock value 65108 differs from sh_pclk value 66000000, fixing..
    PLL1     : 531.00MHz
    PLL2     : 402.00MHz
    ST40 CPU : 265.50MHz
    ST40 BUS : 132.75MHz
    ST40 PER :  66.37MHz
    SLIM     : 265.50MHz
    ST231    : 402.00MHz
    STBUS    : 201.00MHz
    EMI      : 100.50MHz
    LMI      : 201.00MHz
    Console: colour dummy device 80x25
    Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
    Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
    Memory: 67712k/126976k available (1898k kernel code, 59196k reserved, 227k data, 39412k init)
    Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
    CPU: STb710x
    Kernel panic - not syncing: invalid compressed format (err=1)
    Jendа avatar 16.1.2013 22:44 Jendа | skóre: 73 | blog: Výlevníček | JO70FB
    Rozbalit Rozbalit vše Re: Špatně zabalené CPIO
    Tohle podle mě není chyba nějakého CRC, ale jako kdyby byl ten soubor/filesystém zabalený tak, že ho kernel prostě nedokáže namountovat. Problémů může být spousta - parametry cpio, flasher to špatně zapíše do flashky…
    16.1.2013 23:53 MadCatX
    Rozbalit Rozbalit vše Re: Špatně zabalené CPIO

    Schválně jsem zkusil ten firm.gzip rozbalit a znovu zabalit, aniž bych v obsaženém CPIO něco měnil. Je zajímavé, že mnou vytvořený archiv má jinou velikost než archiv originální - stupněm komprese to není, to jsem zkoušel. Kontrolní součty CPIO ale sedí z obou archivů. Můžete zkusit nahrát do STB ten můj archiv. Pokud ani ten nebude fungovat, napadají mě v podstatě dvě možnosti. Buď je už originální archiv chybný, nebo se něco stane až při kompresi do gzip. Link

    Pochopil jsem z vámi odkazované diskuse správně, že je potřeba ten rozkuchaný firmware po modifikaci zase poskládat zpátky? Pokud ano, máte jak ověřit, že nevzniká problém až tam?

    17.1.2013 03:29 MadCatX
    Rozbalit Rozbalit vše Re: Špatně zabalené CPIO
    Zkusil jsem ještě jednu věc, a sice to CPIO rozbalit, v ./images přidat jeden řádek do README.txt a zase ho složit zpátky. Vzniklý CPIO jsem zagzipoval a doplnil nulami tak, aby seděla velikost gzip archivu. Momentálně mám z jádra vyřazenou podporu JFFS2, takže přímo ten image upravovat nemůžu. Pokud by vám ale aspoň jeden z mých pokusů zafungoval, zaktivním JFFS2 a zkusím upravit i ten image.

    FW pokus 2
    17.1.2013 09:48 jeninicicek
    Rozbalit Rozbalit vše Re: Špatně zabalené CPIO
    Příloha:

    ahoj všem,

    Josef mi hodil odkaz, že pro radu s boxem šel i sem, trošku zkusím nastínít líp, co máme a co jede a co už ne. Rozbalení není problém a zabalení, které používám je momentálně viz příloha. 
    Pokud při postupu neudělám žádné změny ve firmware dostanu identický soubor s originálním. Pokud však udělám jakoukoli sebemenší změnu už to nefunguje. Já osobně mám na virtuálním stroji debian a občas fedoru, postup funguje vždy. Ale stačí kdekoli změnit čárku (např. jsem zkusil do jednoho z readme přidat písmeno) a spadne to...

    17.1.2013 12:43 MadCatX
    Rozbalit Rozbalit vše Re: Špatně zabalené CPIO

    Na podobný postup jsem přišel včera taky, nicméně všiml jsem si několika případných zádrhelů.

    • Kontrolujete při rozbalování toho CPIO, že se rozbalí skutečně celé, tedy všech 83574 bloků? Obsažený adresář /dev se mi rozbalil, až když jsem cpio spustil pod rootem.
    • Pokud pro balení zpět do CPIO používáte doporučený postup
         find . -depth | cpio -ova -H newc > ../myfirm.cpio
        
      vytvoří se archiv, kde budou soubory v jiném pořad. Tomu se dá zabránit např. tím, že sestavíte seznam souborů obsažených v originálním CPIO:
          cpio -it < orig.cpio > flist.txt
          cat ../flist.txt | cpio -ova -H newc > ../myfirm.cpio
        
      Netvrdím, že by to mělo vadit, ale určitě to stojí za pokus.
    • mkfs.jffs2 mi též vytvořil jiný RAW soubor, i když jsem v původím přímountovaném image nic neměnil. To jsem vyřešil tím, že jsem nakopíroval RAW do /dev/mtdblock0, ten mountnul, upravil /etc/shadow a přes dd vytvořil RAW
         modprobe mtdblock
         modprobe mtdram total_size=39000 erase_size=16
         dd if=NAND.raw of=/dev/mtdblock0
         mount -t jffs2 -w /dev/mtdblock0 /media/raw
         ...
         umount /media/raw
         dd if=/dev/mtdblock0 of=modNAND.raw
        
      Výsledný soubor bude větší než originál, ale přebývající 0xFF na konci by mělo být možné useknout.
    Tímto způsobem jsem dal dohromady poslední pokus, tak uvidíte:)

    Celý firmware i s úvodním souborem, padovaný na velikost firmbcrc
    Pouze CPIO s upraveným image

    17.1.2013 14:47 Milan Roubal | skóre: 25
    Rozbalit Rozbalit vše Re: Špatně zabalené CPIO
    Neni potreba po tom poslednim dd provest jeste toto?
    jffs2dump -r -e modNAND.raw -l new_modNAND.raw
    Tedy prevest mezi sebou little a big endian?
    17.1.2013 15:27 MadCatX
    Rozbalit Rozbalit vše Re: Špatně zabalené CPIO

    Tohle mě taky napadlo, ale SH4 procesory jsou bi-endianové a původní NAND.raw a můj modNAND.raw jsou až na úpravu paddingu na konci a obsah /etc/shadow stejné, v tom bych problém tedy nehledal; kontroloval jsem to vbindiffem.

    Ještě jsem zkusil toto:

    1. Rozbalit gzip
    2. Rozbalit CPIO
    3. Přepsat pár znaků v images/README.txt
    4. Zabalit, zagzipovat, přidat úvodní soubor a napadovat na velikost původního FW, na NAND.raw jsem vůbec nesahal
    Pokud nefunguje ani tohle, něco se zprasí buď už při rozbalování nebo při zpětné kompresi(link).

    17.1.2013 15:50 jeninicicek
    Rozbalit Rozbalit vše Re: Špatně zabalené CPIO
    Pod rootem pracuji vždy, tohoto problému jsem si všiml dřív, co se týče pořadí programů, tak mi to nepřijde důležité, pokud je verze ověřována bude to po změně vždy špatně, je-li to balením tak ne tímto, protože jinak by těžko vydávali časem nové verze firmware... příkaz mkfs.jffs2 mi taky háže pod novými liny jiný výsledek, ale to je asi jinou verzí, naučil jsem se používat systém(starší debian), ve kterém se podařilo upravit jednu ze starších verzí firmware španělům(http://forum.ican3800.zajsoft.net/download/ican3800--1.45GB.rar). Potom dostanu identický raw. popřípadě stejně jako ty jsem měnil věci přímo v mountnutém obraze. Takže testovat a radit další možnosti dále a dále, jednou na to přijdem a já se rád něčemu přiučím...
    17.1.2013 16:29 Milan Roubal | skóre: 25
    Rozbalit Rozbalit vše Re: Špatně zabalené CPIO
    Na tom postupu je zajimava ta cast

    Otevøeme v hexeditoru a pøepiseme datum vytvoøeni (jde o 5-8 byte souboru gzip).

    bez toho ten firmware nejede? Tedy pokud se vezme ten jejich originalni soubor a prepsou se mu bajty 5-8 treba na dnesek, tak to funguje ci nikoliv?
    17.1.2013 10:18 jeninicicek
    Rozbalit Rozbalit vše Re: Špatně zabalené CPIO
    A ještě poprosím, posíláte-li nám soubory na zkoušku, posílejte už komplet firmware, ne jen gzip soubor bez úvodní části a nedoplněný na originál velikost firmware. Někteří z těch co to testují se to zatím neumějí dát dohromady. Pokud jste jako výchozí soubor již použili gzip(ten je na foru icanu pro ty co ho neuměli z firmware dostat) napište to do příspěvku, aby to někdo doplnil a mohli testovat všichni ochotní majitelé boxů. Jinak pokud sami nevíte co doplněním myslím, vyzkoušejte si vše včetně rozbalování od začátku, třeba najdete chybu už tam(vše potřebné i s návodem, abyste nestrávili noc na foru icanu zde http://uloz.to/xCq6aWv/jaknao2czfirmware-zip)...
    17.1.2013 10:22 jeninicicek
    Rozbalit Rozbalit vše Re: Špatně zabalené CPIO
    Ano firmware je rozkuchaný, komplet i s návodem jak jsem dal níže. Já osobně předpokládám, že to bude někde tam, bohužel těch co dokáží firmware kuchat na gzip a zbytek a složit zpět mezi námi moc není... Kdyby mi někdo popsal co přesně dělá část firmware před gzipem, byl bych moc rád...
    17.1.2013 14:08 joseff | skóre: 4
    Rozbalit Rozbalit vše Re: Špatně zabalené CPIO
    Zkusil jsem nahrát mdzf_firm od MadCatX.

    Dobré je, že po překopírování do boxu a rebootování to chtělo rozbalit.

    Bohužel opět stejný problém.

    Nerozbaluje se to, box zatuhne a konzola zobrazí skoro stejnou závadu:
    RebootLinux version 2.6.11.12_stm20-33 (A.Mielcarek@autogrator1) (gcc version 3.4.3 (STMicroelectronics/Linux Base 3.4.3-19) [build Mar 10 2006]) #1 Wed Sep 8 11:32:36 CEST 2010
    ADB STB initialisation
    STb7100 version 3.x
    Built 1 zonelists
    Kernel command line: console=ttyAS0,115200 splasharea=4096,0x0B000000           
    PID hash table entries: 512 (order: 9, 8192 bytes)
    Calculated peripheral clock value 63520 differs from sh_pclk value 66000000, fixing..
    PLL1     : 531.00MHz
    PLL2     : 402.00MHz
    ST40 CPU : 265.50MHz
    ST40 BUS : 132.75MHz
    ST40 PER :  66.37MHz
    SLIM     : 265.50MHz
    ST231    : 402.00MHz
    STBUS    : 201.00MHz
    EMI      : 100.50MHz
    LMI      : 201.00MHz
    Console: colour dummy device 80x25
    Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
    Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
    Memory: 67712k/126976k available (1898k kernel code, 59196k reserved, 227k data, 39412k init)
    Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
    CPU: STb710x
    Kernel panic - not syncing: invalid compressed format (err=1)
    17.1.2013 16:09 joseff | skóre: 4
    Rozbalit Rozbalit vše Re: Špatně zabalené CPIO
    Zkusil jsem nahrát verzi mdz_nomod od MadCatX.

    Bohužel naprosto stejná závada i výpis je naprosto stejný, proto ho nepřidávám.
    17.1.2013 16:21 joseff | skóre: 4
    Rozbalit Rozbalit vše Re: Špatně zabalené CPIO
    Hledal jsem další informace a nechal to v tomto stavu bloknuté asi déle jak 10 min a ono to najednou vyhodilo další informace, asi to moc nepomůže, ale dávám to sem:
    RebootLinux version 2.6.11.12_stm20-33 (A.Mielcarek@autogrator1) (gcc version 3.4.3 (STMicroelectronics/Linux Base 3.4.3-19) [build Mar 10 2006]) #1 Wed Sep 8 11:32:36 CEST 2010
    ADB STB initialisation
    STb7100 version 3.x
    Built 1 zonelists
    Kernel command line: console=ttyAS0,115200 splasharea=4096,0x0B000000           
    PID hash table entries: 512 (order: 9, 8192 bytes)
    Calculated peripheral clock value 65108 differs from sh_pclk value 66000000, fixing..
    PLL1     : 531.00MHz
    PLL2     : 402.00MHz
    ST40 CPU : 265.50MHz
    ST40 BUS : 132.75MHz
    ST40 PER :  66.37MHz
    SLIM     : 265.50MHz
    ST231    : 402.00MHz
    STBUS    : 201.00MHz
    EMI      : 100.50MHz
    LMI      : 201.00MHz
    Console: colour dummy device 80x25
    Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
    Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
    Memory: 67712k/126976k available (1898k kernel code, 59196k reserved, 227k data, 39412k init)
    Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
    CPU: STb710x
    Kernel panic - not syncing: invalid compressed format (err=1)
     <1>Unable to handle kernel NULL pointer dereference at virtual address 0000000c
    pc = 84438808
    *pde = 00000000
    Oops: 0000 [#1]
    
    Pid : 1, Comm:              swapper
    PC is at __queue_work+0x28/0xa0
    PC  : 84438808 SP  : 86df7eac SR  : 400081f0 TEA : 0000000c    Not tainted
    R0  : 00000000 R1  : 00000008 R2  : 845f4634 R3  : 00000000
    R4  : 00000001 R5  : 845f4634 R6  : 86cab044 R7  : 86cab03c
    R8  : 845f4634 R9  : 00000000 R10 : 00000000 R11 : 86df6000
    R12 : 86df7ed0 R13 : 86caad3c R14 : 844251a0 R15 : 86df7eac
    MACH: 0000008b MACL: 000000c0 GBR : 00000000 PR  : 84438800
    
    Call trace:
    [<844388dc>] queue_work+0x5c/0xe0
    [<8442f95c>] run_timer_softirq+0xdc/0x260
    [<844f6e20>] blank_screen_t+0x0/0x20
    [<84445852>] handle_IRQ_event+0x52/0xe0
    [<8442ac7a>] __do_softirq+0x5a/0xe0
    [<8442ad46>] do_softirq+0x46/0x60
    [<844d1980>] __const_udelay+0x0/0x20
    [<844170c0>] do_IRQ+0x0/0x60
    [<8442ae66>] irq_exit+0x46/0x80
    [<8441ee80>] sub_preempt_count+0x0/0xa0
    [<844170ee>] do_IRQ+0x2e/0x60
    [<8441406e>] ret_from_irq+0x0/0x12
    [<844d1960>] __delay+0x0/0x20
    [<844d1980>] __const_udelay+0x0/0x20
    [<844d1962>] __delay+0x2/0x20
    [<84424398>] panic+0xb8/0x100
    [<84411112>] init+0x32/0xf20
    [<84412004>] kernel_thread_helper+0x4/0x20
    
    Kernel panic - not syncing: Aiee, killing interrupt handler!
    13.3.2013 13:24 joseff | skóre: 4
    Rozbalit Rozbalit vše Re: Špatně zabalené CPIO
    Kolega již přišel na postup, jak to zabalit:

    Tak po dlouhém testování, konečně dokáži zabalit firmware pro box tak, aby s ním šlo flashovat. Takže tady je doufám srozumitelný návod:

    Co potřebujeme:

    Já jsem vycházel z originál firmwaru O2, ale většina návodu funguje i pro ostatní verze. Pracoval jsem s hexeditorem xvi32 pod windows a potřebné části pod Fedora 17. Celé by to mělo jít provést pod libovolným linux systémem i třeba na virtuálních mašinách.

    1) Rozbalíme O2 firmware na části vmlinux(tak se oficiálně nazývá část firmwaru před gzip souborem) a gzip soubor.

    2) V hexeditoru odřízneme ze souboru gzip nuly na konci(potřebujeme vědět jeho velikost bez nich). Soubor tím nijak nepoškodíme.

    Odtud je doporučené a místy potřebné pracovat jako root pod linuxem.

    3) Rozbalíme gzip soubor do nové složky pomocí příkazu

    cat _gzipsoubor_ |gunzip| cpio -i --make-directories

    4) Nyní potřebujeme získat místo(sami si vyzkoušejte, že nedokážete beze změn vytvořit stejně velký gzip jak originál-jako originální velikost beru velikost gzipu bez nul). Bohužel jsem nepřišel na způsob jak omezit velikost souboru NAND.raw(ten bude upravován v dalších krocích, ale i po upravách v něm se mi neměnila jeho velikost). Stejně tak většina souborů je zde potřebných. Bez problémů můžeme odstranit soubor README ve složce images, ale to nestačí, takže jsem ještě(ač je to prasárna) odstranil téměř všechny komentáře v souboru \etc\init.d\rcS. Pokud provedete tyto úpravy zkuste si vytvořit(podle návodu dále) pokusný gzip a ověřte zda má menší velikost než originál. Pokud ano můžeme pokračovat k té pravé editaci.

    5) Nyní budeme editovat budoucí systém boxu, ten je ukryt v jffs2 obrazu \images\NAND.raw. Zkopírujeme si ho na jiné místo(je lepší mít originál v záloze)a namountujeme zkopírovaný obraz pomocí příkazů: mknod /dev/mtdblock0 b 31 0 modprobe mtdblock modprobe mtdram total_size=65536 erase_size=256 modprobe jffs2 dd if=_zkopirovanyobraz_ of=/dev/mtdblock0 mount -t jffs2 /dev/mtdblock0 \_složka,kekterechcempripojit_

    6) El artista ve svých návodech doporučoval nepracovat přímo na mountované složce, já však měk s následným vytváření jffs problémy a proto jsem pracoval přímo v ní. Mnou testované úpravy zatím spočívaly v odstranění hesla. Tedy upravíme potřebně soubory \etc\passwd a \etc\shadow. Popřípadě můžeme přidat další věci jako telnet, části mediacentra, atd... Omezeni jsme velikostí...

    7) Pomocí umount odmountujeme složku s obrazem.

    8) Prací ve složce jsme vlastně přímo upravovali soubor obrazu, takže ho teď nakopírujeme zpět do složky \images v rozbaleném gzipu.

    9) Vytváříme nový gzip:

    Po dlouhých problémech jsem došel k závěru, že nevhodnější je vytvořit si jednoduchý script, kterým vytvoříme cpio archiv a ten následně zagzipujeme.

    script:
    #!/bin/bash
    echo "Menim opravneni init"
    chmod 0755 /_slozkasrozgzipem_/init
    CPA=`pwd`
    echo "Tvorim cpio"
    cd _slozkasrozgzipem_ && find . | cpio -o -H newc > $CPA/newfirmware.cpio
    echo "Tvorim gzip"
    cd $CPA && cat newfirmware.cpio |gzip -nfcr9 >> newfirmware.gzip)
    echo "Mazu nepotrebne cpio"
    rm newfirmware.cpio
    echo "Hotovo"
    Spustíme script jako root: sudo ./_nasscript_

    Vytvoří se nám soubor newfirmware.gzip.

    10) Zkontrolujeme, zda je newfirmware.gzip menší nebo roven originálnímu gzipu bez nul, pokud ano, pokračujeme dále, pokud ne musíme něco oželet, promazat....

    Odteď je už opět jedno na jakém systému pracujeme.

    11) Před newfirmware.gzip vložíme v hexeditoru zpět vmlinux, a na konci ho doplníme na originální velikost firmwaru nulami(důležité).

    12) Máme hotovo můžeme flashovat (doporučuji novou univerzální verzi flashovacího nástroje)...

    --------------------------------------------------------

    Po neúspěších s úpravou NAND tak aby neobsahovala crc chyby jsem se rozhodl nepoužít NAND.raw ale obyčejný tar.gzip...

    Systém spočívá v upravení rcS souboru a místo souboru NAND.raw jsem tam dal firmout.gzip, myslím, že ten by jste měli být schopni upravit každý, je to teď velmi jednoduché... soubor je také menší než s použitím NAND.raw..., takže další výhoda...

    Takže postup:

    1) Stáhněte firmware níže (nutno, je v něm upravený soubor rcS a pár dalších změn)

    2) provedeme s ním kroky 1-3

    3) ve složce images je soubor firmout.gzip, je to běžný tar-gzip archiv, rozbalte ho a můžete upravovat...

    4) po upravení zabalíme (já použil: tar cf - * |gzip -9 >> ../firmout.gzip)

    5) vzniklý soubor překopírujeme do složky images

    6) Pokračujeme od kroku 9

    ---------------------------------------------------------

    Napadlo mne to při rozbalování cybervacy, kterej používá bzip kompresi, prostě jsem si řek, že když to šlo jemu, nám musí taky...

    Tady posílám první beta test-test verzi s funkčním telnetem a přístupem na placené IPTV od O2, je do ní nakopírováno i mediacentrum.

    Obsahuje upravené Flashovací instrukce, takže opakované Flashování je možné bez potíž.

    - v této verzi zatím nejsou odchytané chyby, ale docela funguje, v této verzi USB zatím nefunguje, ale v další verzi bude

    http://uloz.to/xDcuiSu/o2damectelnet-rar

    Obrana proti O2 updatu:

    OPCH musí být ta od O2, aby jela O2TV, ale port nastavit špatně.

    O2TV běží, ale firmware O2 nejde updatnout...

    Nyní by mělo být možné provádět v boxu úpravy a používat IPTV bez nutnosti Flashovat zpět na nepoužitelnou O2 verzi.

    Kdo má zájem, tak se může připojit.

    Založit nové vláknoNahoru

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.