Blackscreen po upgradu - nVidia

Založil kubik, 21. 05. 2012, 21:32:28

Předchozí téma - Další téma

lyon667

#15
Nazdar pánové, včera jsem cca po třech týdnech provedl update Wheezyho a dopadl jsem úplně stejně. U mě došlo k updatu glibc z 2.13-37 na 2.13-38, a nepočítám-li spoustu nesouvisejících balíků, tak ještě větší část xorg. Startující Xka při startu provedou únikový manévr ve stylu Segfault:

#0  0xb72384c0 in realloc () from /lib/i386-linux-gnu/libc.so.6
No symbol table info available.
#1  0xb75a3cea in dixReallocPrivates (privates=0xb87a9074, old_offset=8, bytes=4) at ../../dix/privates.c:96
        new_privates = <optimized out>
#2  0xb75a3b1c in fixupServerClient (fixup=fixup@entry=0xb75a3cb0 <dixReallocPrivates>, bytes=bytes@entry=4) at ../../dix/privates.c:129
No locals.
#3  0xb75a3e22 in dixRegisterPrivateKey (size=0, type=PRIVATE_CLIENT, key=0xb70407e0) at ../../dix/privates.c:233
        offset = <optimized out>
        bytes = 4
#4  dixRegisterPrivateKey (key=0xb70407e0, type=PRIVATE_CLIENT, size=0) at ../../dix/privates.c:181
No locals.
#5  0xb6d850dd in ?? () from /usr/lib/xorg/modules/linux/libglx.so
No symbol table info available.
Backtrace stopped: previous frame inner to this frame (corrupt stack?)


Čímž dojde k zablokování jak grafiky, tak klávesnice/myši, přičemž ssh naštěstí funguje. Z logu, kterýžto končí s "Initializing extension GLX" nelze vyčíst prakticky nic, nicméně vypnutí glx v xorg.conf alespoň kýženou extension přeskočí a nechá Xka naběhnout (pochopitelně bez akcelerace). Zkoušel jsem jak distribuční ovladač, tak několik různých verzí stažených přímo od nVidie, leč bez úspěchu.

Jelikož deb balíky eglibc- 2.13-37 už v repozitáři nejsou, rebuildnu to ze zdrojů a dám vědět. Pokud to náhodou selže, rebuildnu i Xka.

Firzen

Takže přátelé, konečně jsem na to přišel. Byl jsem totiž líný reinstalovat, takže jsem to zkoušel tak dlouho, až se mi to povedlo.
Jak tedy na to..

1. ZÁLOHUJTE SYSTÉM - jedná se totiž o experimentální návod, který byl vyzkoušen pouze jednou a na jednou PC!  Několikrát jsem systém při pokusech rozbil, a bez zálohy bych byl celkem nahraný.

2. restartujte do konzole, nebo killněte grafické prostředí - pro KDE je to:
killall kdm

3. odinstalujte ovladač nvidia grafiky příkazem podobným tomuto:
./NVIDIA-Linux-x86-319.32.run --uninstall
(pokud už instalátor nemáte, tak by myslím mohl fungovat i nějaký jiný stažený ze stránek nvidie)

4. v konzoli zadejte:
aptitude install libc6 libc-bin libc-ares2

5. dále pak spusťte (nevím, jestli je to skutečně potřeba):
aptitude install xserver-xorg xserver-xorg-core

6. nainstalujte znovu nvidia ovladače, a pak restartujte systém

7. enjoy!!!
AMD Phenom II X6 1100T@3,3GHz, Gigabyte GeForce GT 430 1GiB, 8GiB RAM, 1TiB SATA3 HDD, Nokia N900
OS: Debian 6.0 Squeeze, Maemo 5
Nyní můžete počítač bezpečně vypnout.

Antonín Mička

toto asi bude fungovat jen pro instalačku přímo od nvidie, mám pocit, že podobný postup asi na ovladače z distribuce nefungue.  8)

Firzen

Je to možné, že ne.. nezkoušel jsem. Každopádně mně to už funguje, takže jsem více, než spokojený, že nemusím instalovat znovu..
AMD Phenom II X6 1100T@3,3GHz, Gigabyte GeForce GT 430 1GiB, 8GiB RAM, 1TiB SATA3 HDD, Nokia N900
OS: Debian 6.0 Squeeze, Maemo 5
Nyní můžete počítač bezpečně vypnout.

Antonín Mička

zkouším ověřit, ale na starším stroji už musím použít legacy ovladač a na novějším to nějak nefunguje, ale tam zas mám optimus, těžko říct, kte u něj je chyba.
Ale jde mi to pomalu... :(

RayeR

Citace od: Firzen kdy 25. 10. 2013, 11:00:43
Takže přátelé, konečně jsem na to přišel. Byl jsem totiž líný reinstalovat, takže jsem to zkoušel tak dlouho, až se mi to povedlo.
Jak tedy na to..

Tak jsem zkousel tento postup na svem Wheezy s libc6 2.13-27 a naslednym updatem na 2.13-38 a driverem NVIDIA-Linux-x86-304.88.run, ale zas to skoncilo probliknutim a cernotou a komplet zatuhlym systemem. Kdyz jsem downgradnul na libc6 2.13-27 a preinstaloval driver, tak to zas slo.

Tak uz jsem se nasral a provedl celkovy update distribuce na Jessie (testing). Tam jsem narazil na problem, ze novy udev vyzadoval v kernelu zapnutou volbu mountovani devtmpfs do /dev, coz jsem ve sve konfiguraci zaple nemel a ani dpkg --force-all tam ten novy udev nenarval, takze sem jeste ze vseho prekladal jadro (nasledne sem ho musel kompilovat jeste jednou protoze se aktualizoval balik gcc 4.7.2 na 4.8.2). Nasledne jsem uspesne dokoncil dist-upgrade (v Jessie je libc6 2.17), nainstaloval nvidia driver a vsechno slape jak ma  :)
Ale pozor, kdyz sem si chtel prelozit novy kernel 3.13 (kvuli podpore rtl-dvb-t), tak jsem zas narazil, protoze ti kkti zmenili v souboru /src/drivers/i2c/i2c-core.c funkci int i2c_del_adapter(...) na void i2c_del_adapter(...), cimz pri pekladu nvidia kernel modulu doslo na teto funkci k erroru, protoze tam prirazovali promenne navratovou hodnotu te funkce a ono to s voidem moc dobre nejde. Tak sem to prepsal po staru, ale zas to chciplo na nakych dalsich warningach treated as error, takze sem to vzdal a vratil s ke kernelu 3.6.0 (ta zmena je minimalne od 3.10.x). Aspon ze se nerozbil VMWare, jen si znovu prelozil sve moduly a maka.
No proste hotovy instalacni porod, skoncil sem s tim nekdy rano a spal asi 3 hodiny, to cloveka nauci milovat sve Windows ;)

Kdyby nekdo potreboval, tak jsem uploadnul ty stare balicky s libc6 2.13.27 zde: http://ulozto.cz/xdT93iYt/debian-wheezy-libc6-2-13-27-tgz

RayeR

Tak koukam, ze tu chybu nekdo nahlasil uz pred pul rokem a zatim se nic nedeje. Patrne to postihuje jadra 3.9.x a novejsi
http://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-310/+bug/1195618

Palo M.

A je nejaky dovod, preco si sa zufalo pokusal pouzit NVIDIA-Linux-x86-304.88.run (balik priamo od Nvidie)?

IMHO si mal nasledujuce moznosti:
1. Na Wheezy so standardnym jadrom 3.2 pouzit standardne baliky (nvidia-glx vo verzii 304.88 teda tej istej co si instaloval). Netreba ziadne spekulacie a malo by to chodit.
2. Ak si z nejakeho dovodu potreboval novsie jadro (napriklad ak mas novu dosku), vo wheezy-backports je jadro 3.10 a nvidia-glx vo verzii 319.72, teda novsej - opat by to spolu malo chodit.

Distribucne baliky driverov obsahuju totiz patche, ktore zarucuju, ze ta konkretna verzia drivera funguje s tym konkretnym distribucnym jadrom. Balik stiahnuty od Nvidie taketo patche neobsahuje, takze je vzdy kompilovatelny len s istou podmnozinou verzii jadra v danom case - s novsimi alebo starsimi sa skratka skompilovat neda, pretoze hlavicky jadra sa skratka menia, ako sa jadro postupne vyvija.

Distribucia tymi patchami spravila za teba kopec roboty (a byvaju tam aj ine patche, nielen take co su nutne aby sa ti vobec skompiloval modul v DKMS, ale aj rozne ine bugy), plus bude vydavat pripadne updaty - a ty si tu ich robotu vobec nevyuzil, kaslal si sa s nejakymi zabugovanymi verziami od Nvidie, zabil si kopec casu a nakoniec si to "poriesil" prechodom na testing, dalsou kompilaciou (a trojhodinovym spankom)... :P A to este nie je z tvojho postu jasne, ako si to vlastne "kompiloval", ci si vobec vyrobil .deb balik, alebo si len spustil ten nvidiacky .run, ktory sa s nejakym balickovanim vobec neobtazoval a rovno nakopiroval binarky "niekam" do /usr - a pri nejakom dalsom update v buducnosti ta mozno opat privita cierna obrazovka a zase budes musiet riesit (teda neviem, ci to este ta instalacka od Nvidie robi, kedysi to robila a vzdy to riadne rozbilo system, takze nasledny pokus o instalaciu normalnych balikov z distribucie zlyhal, museli sa najprv najst a manualne pomazat vsetky tie humusy, co tam nvidiacky instalator kde-kade porozhadzoval, az potom sa mohli nainstalovat normalne baliky).

Inak to s tymi drivermi plati rovnako aj pre AMD - kompilovat surovy driver od AMD je kopec roboty a pritom fglrx-driver v distribucii je plne funkcny, takze vacsinou netreba vobec spekulovat.

Jedine odovodnenie vo vlastnej kompilacii driverov vidim v pripade, ze potrebujes velmi novu verziu ovladaca, pretoze mas cerstvo zakupenu grafiku a ta starsia verzia ovladaca v distribucii s novym hardverom robi problemy. Vtedy za to ten kopec roboty s vlastnou kompilaciou stoji. Ale to zjavne nie je tvoj pripad, pouzil si starsiu verziu ovladaca, ktora je normalne vo Wheezy...

RayeR

Citace od: Palo M. kdy 17. 12. 2013, 06:15:48
A je nejaky dovod, preco si sa zufalo pokusal pouzit NVIDIA-Linux-x86-304.88.run (balik priamo od Nvidie)?
IMHO si mal nasledujuce moznosti:
1. Na Wheezy so standardnym jadrom 3.2 pouzit standardne baliky (nvidia-glx vo verzii 304.88 teda tej istej co si instaloval). Netreba ziadne spekulacie a malo by to chodit.
2. Ak si z nejakeho dovodu potreboval novsie jadro (napriklad ak mas novu dosku), vo wheezy-backports je jadro 3.10 a nvidia-glx vo verzii 319.72, teda novsej - opat by to spolu malo chodit.

To je moc hezky, ze jsou na vsechno pripraveny balicky, jenze minimalne kvuli DVB-T tuneru potrebuju novejsi jadro (spolupracoval sem s jednim manikem z linuxtv.org na testovani ovladace, ktery byl pro ten muj tuner pridany az ve verzi 3.7 RC), tudiz si ho kompiluju sam. Na jiny tuner s RTL2832U se objevil driver az v kernelu 3.8 (pro nej a pro 3.9 by mel jit este nvidia driver zkompilovat (funkce na i2c este vraci int)).
Predpokladam, ze ty balicky nvidia-glx jsou pouze binarni s uz zkompilovanym kernem modulem pro distribucni jadro nebo se pletu a taky se preklada pri instalaci? Cili pro me nepouzitelne. Verzi 304.88 pouzivam proto, ze je to posledni verze, ktera podporuje GeForce 7xxx, novejsi verze driveru jsou, ale jen pro GTXxxx novejsi karty. Tim jsem asi do budoucna v pytli, protoze nvidie patrne driver pro tyhle starsi karty dal aktualizovat nebude, zatimco kernel se furt prekotne vyviji, ze vyvojari nemuzou nechat delsi chvili nake konzistentni API aby vyrobci driveru nemuseli ovladace neustale dokola prepisovat (zrejme proto to vetsinu nebavi a tak pro svuj HW vydaji 1 ci 2 ovladace pro windows, pokud jsou dobre napsane, vydrzi i treba 10let)...

Jinak nvidiacky instalator jsem pouzival mnoho let dozadu (poprve tusim s Debian Sarge a GeForce MX440) a nemel jsem s nim vetsinou problem, pokud jsem mel spravne nastavene nakonfigurovane kernel sourcy a povedl se zkompilovat ten kernel modul, tak uz to pak vzdy fungovalo vyborne a zadne jine baliky mi to nerozbilo - nvidia deb baliky sem ani neinstaloval. Ten instalator ma i volbu --uninstall, kera po sobe vycisti (i kdyz...). O moznosti udelat z toho jejich runu deb jsem teda nevedel (nejaka obdoba make-kpkg?), ale u jednoho baliku mi to zily netrha...

Palo M.

1. Mas zvlastnu kombinaciu HW, ked potrebujes nove jadro kvoli (asi novemu) DVB-T tuneru a pritom mas starsiu grafiku... ale aj toto vyzera byt riesitelne s balikmi:
Vo wheezy-backports je metabalik nvidia-legacy-304xx-driver (pouzit namiesto metabaliku nvidia-glx) - mal by fungovat spolu s jadrom z wheezy-backports (s jadrom 3.11 alebo 3.10). Takze by si mal mat aj patricny nvidiacky driver na tvoju kartu a aj dostatocne novu verziu jadra.

2. Tvoje poznatky o balickoch s proprietarnymi ovladacmi (napriklad nvidia-glx) su uz zastarale. Moduly jadra sa uz nejaky cas nedistribuju binarne, ale ako zdrojaky pre DKMS. Takze v pripade, ze dojde k instalacii novsieho balika jadra, tak sa "sama" spusti kompilacia modulu jadra (s novymi hlavickami jadra) a takto skompilovany (uz binarny) modul jadra sa prida do patricneho adresara v /lib/modules/... ak nahodou kompilacia DKMS neprejde (napriklad ak sa zmenia hlavicky jadra v novsej verzii), tak to pri tom update zanadava a ty o tom vies (takze to bud vyriesis, alebo sa aspon vratis k predchadzajucej verzii - hlavne nemusis zapasit s fenomenmi typu "blackscreen po update"). Okrem toho, proprietarny "ovladac" pre grafiku nie je v Debiane len jeden balik. Jeden balik je pre samotny modul jadra, jeden je pre Xorg a este je niekolko dalsich balikov (pozri napriklad ake vsetky sa generuju z nvidia-legacy-304xx-driver). To, ze je to rozdelene do viacerych balikov ma svoj vyznam, pretoze od tych balikov zavisia zase nejake ine baliky... takze ked nenainstalujes baliky z distribucie, tak sa ti moze pri nejakom programe stat, ze mu bude chybat zavislost => baliky su v podstate rozbite, aj ked sa ta to momentalne mozno nedotyka a nevidis to a dokonca mozes tvrdit "funguje mi to vyborne".

3. S kompilovanim vlastneho jadra je extra robota. "Skompilovat vlastne jadro" pritom moze viest k viacerym vysledkom, podla toho, ako to urobis: Mozes napriklad zobrat zdrojak z kernel.org a ist cez menuconfig, make, make install - co je velmi zly napad. Mozes zobrat jadro z kernel.org a ist cez make-kpkg, vyrobit tak .deb balik a ten nainstalovat (to uz je omnoho lepsi napad). Ale ked si pozries zdrojovy balicek jadra v Debiane (je jedno v ktorej vetve), uvidis tam vzdy plno roznych patchov (oproti kernel.org jadru) na tu konkretnu verziu jadra - a tie by si tam nemal (znova, toto je kus roboty co za teba spravili ludia z distribucie!). Takze dalsia moznost je nainstalovat balik linux-source, ktory ma tie patche v sebe tiez a tiez je vysledkom .deb balik (samozrejme tato moznost pada, ak potrebujes taku specialnu verziu jadra, ktora v distribucii prave nie je - ale potom fakt musis ocakavat problemy s nekompatibilitou).
IMHO ma vlastna kompilacia jadra ale vyznam len v tom pripade, ak potrebujes zapnut nejake specialne volby v tom menuconfig-u, ktore v standardnych balikoch zapnute nie su (napriklad chces pouzit konkretny process scheduler, alebo chces osekat jadro pre konkretnu masinu kde mas malo pamate, vies co tam nepotrebujes a da sa na tom usetrit pamat, pripadne mas velmi dobry dovod na vyrobu velkeho monolitickeho jadra a vypnuti podpory dynamickych modulov) - skratka mas nejake naozaj specificke potreby a stoji ti za to sa s tym kaslat.
Ale z tvojho popisu mi vobec nepripada, ze by si vobec musel kompilovat vlastne jadro. Ty podla vsetkeho potrebujes len ten ovladac na DVB-T prijimac. S vysokou pravdepodobnostou je to jednoducho dosiahnutelne nasledovne:
a) Ovladac je v jednom z jadier vo wheezy-backports: Nainstalujem jadro, hotovo, nic ine netreba riesit.
b) Ovladac nie je v ziadnom z jadier, ale je s nejakym kompatibilny: stiahnem zdrojak ovladaca, vyrobim z neho DKMS balik (to uz nie je uplna trivialita, ale rozhodne je to lepsie nez kompilovat cele jadro), otestujem ze chodi, hotovo.
Skratka kvoli jednemu zariadeniu (DVB-T) sa neoplati prirobit si kopec roboty, rozbit si balicky jadra a potencialne prist o updaty jadra.

Vies, ide to urobit aj uplne prasacky a stale to bude akoze fungovat: Sam si skompilujes nejake jadro a len tak ho nejako svacnes do suboroveho systemu (make install, ci dokonca cp), skompilujes prasacky nvidiacky .run ktory rozkopiruje vselico hore-dole, dopises do grub.cfg staticku polozku s vlastnym jadrom aby ti to vobec bootlo a ked pouzijes vzajomne kompatibilne verzie, tak to nakoniec mozes dostat do chodiveho stavu a bude to asi aj celkom funkcne... v tom danom case... ak nenarazis na to, ze nejaky iny program ktory by si chcel bude potrebovat nejake zavislosti... Ale potom priebezne sleduj, ci nebola vydana opravna verzia jadra a opakuj to cele znova...

Ale v tom pripade vobec nemusis mat Debian, mozes si dat nejaky Linux From Scratch alebo nieco podobne. Vyhoda Debianu je prave v jeho balickovacom systeme, v bezpecnostnych updatoch a pri stable vetve aj v tom, ze jednotlive verzie balikov spolu funguju - a pre vela z nas su tie vyhody take vyrazne, ze nam nevadia mierne starsie verzie jednotlivych programov. Ale ked zacnes v systemovych zalezitostiach (akou jadro rozhodne je) obchadzat balickovaci system, tak tym stratis vyhody, ktore to prinasa, stratis stabilitu... a ostanu ti akurat tie starsie verzie programov. A pritom sa este aj narobis a budes zlozito robit nieco "po starom" aj ked dnes uz sa to da urobit omnoho jednoduchsie.

Mozno je to trocha frustrujuce, ze kedysi si sa naucil ako kompilovat jadro a instalovat ovladac a dnes uz ten postup nie je najlepsia cesta a treba sa zase nieco nove naucit... plus kopec navodov na webe je uz zastaralych a zbytocne ta dopletu... Ale podla mna sa prave veci suvisiace s jadrom vyvijaju celkom dobrym smerom.

RayeR

#25
Citace od: Palo M. kdy 18. 12. 2013, 06:51:55
1. Mas zvlastnu kombinaciu HW, ked potrebujes nove jadro kvoli (asi novemu) DVB-T tuneru a pritom mas starsiu grafiku... ale aj toto vyzera byt riesitelne s balikmi:
Vo wheezy-backports je metabalik nvidia-legacy-304xx-driver (pouzit namiesto metabaliku nvidia-glx) - mal by fungovat spolu s jadrom z wheezy-backports (s jadrom 3.11 alebo 3.10). Takze by si mal mat aj patricny nvidiacky driver na tvoju kartu a aj dostatocne novu verziu jadra.

Tak HW konfigurace existuji ruzne, pravda, tahle uz neni nejnovejsi, ale zatim mi vykon na vse staci, tak proc zbytecne vyhazovat penize (kor kdyz vykon treba poslednich generaci core i3/5/7 moc neroste, jak opadla ta rivalita intel-AMD, tak i motivace, hlavne ze se drzi ceny...)
Ani ten tuner neni uz nejnovejsi, ale par let to trvalo nez nekdo napsal driver, takze minimalni verze s kerou jde pouzit je 3.7.1 a debian je i u unstable teprv na 3.1.2 koukam... Jinak prechod na Jessie jsem stejne uz potreboval kvuli dalsim programum mimo repo, ktere vyzadovaly libc >=2.15...

Citace od: Palo M. kdy 18. 12. 2013, 06:51:55
2. Tvoje poznatky o balickoch s proprietarnymi ovladacmi (napriklad nvidia-glx) su uz zastarale. Moduly jadra sa uz nejaky cas nedistribuju binarne, ale ako zdrojaky pre DKMS. Takze v pripade, ze dojde k instalacii novsieho balika jadra, tak sa "sama" spusti kompilacia modulu jadra (s novymi hlavickami jadra) a takto skompilovany (uz binarny) modul jadra sa prida do patricneho adresara v /lib/modules/... ak nahodou kompilacia DKMS neprejde (napriklad ak sa zmenia hlavicky jadra v novsej verzii), tak to pri tom update zanadava a ty o tom vies (takze to bud vyriesis, alebo sa aspon vratis k predchadzajucej verzii - hlavne nemusis zapasit s fenomenmi typu "blackscreen po update").
...

Aha, o DKMS jsem nevedel, to je pokrok. I kdyz jak rikas, muze to stejne pohoret pri zmene hlavicek, nu o neco lepsi jak BSOD. Ale bez nejake dlouhodobejsi konzistence a nakych standardu to problem stejne neresi, porad to znamena pro vyrobce vetsi naklady na udrzbu ovladacu a tak se na to po par letech stejne vykasle...
Vlastne tohoto chovani jsem si vsimnul u VMWare, kdyz jsem nainstaloval novejsi prelozene jadro a spustil ho, tak si to samo prelozilo asi 5 kernel modulu.

Citace od: Palo M. kdy 18. 12. 2013, 06:51:55
3. S kompilovanim vlastneho jadra je extra robota. "Skompilovat vlastne jadro" pritom moze viest k viacerym vysledkom, podla toho, ako to urobis: Mozes napriklad zobrat zdrojak z kernel.org a ist cez menuconfig, make, make install - co je velmi zly napad. Mozes zobrat jadro z kernel.org a ist cez make-kpkg, vyrobit tak .deb balik a ten nainstalovat (to uz je omnoho lepsi napad). Ale ked si pozries zdrojovy balicek jadra v Debiane (je jedno v ktorej vetve), uvidis tam vzdy plno roznych patchov (oproti kernel.org jadru) na tu konkretnu verziu jadra - a tie by si tam nemal (znova, toto je kus roboty co za teba spravili ludia z distribucie!). Takze dalsia moznost je nainstalovat balik linux-source, ktory ma tie patche v sebe tiez a tiez je vysledkom .deb balik (samozrejme tato moznost pada, ak potrebujes taku specialnu verziu jadra, ktora v distribucii prave nie je - ale potom fakt musis ocakavat problemy s nekompatibilitou).
IMHO ma vlastna kompilacia jadra ale vyznam len v tom pripade, ak potrebujes zapnut nejake specialne volby v tom menuconfig-u, ktore v standardnych balikoch zapnute nie su (napriklad chces pouzit konkretny process scheduler, alebo chces osekat jadro pre konkretnu masinu kde mas malo pamate, vies co tam nepotrebujes a da sa na tom usetrit pamat, pripadne mas velmi dobry dovod na vyrobu velkeho monolitickeho jadra a vypnuti podpory dynamickych modulov) - skratka mas nejake naozaj specificke potreby a stoji ti za to sa s tym kaslat.
Ale z tvojho popisu mi vobec nepripada, ze by si vobec musel kompilovat vlastne jadro. Ty podla vsetkeho potrebujes len ten ovladac na DVB-T prijimac. S vysokou pravdepodobnostou je to jednoducho dosiahnutelne nasledovne:
a) Ovladac je v jednom z jadier vo wheezy-backports: Nainstalujem jadro, hotovo, nic ine netreba riesit.
b) Ovladac nie je v ziadnom z jadier, ale je s nejakym kompatibilny: stiahnem zdrojak ovladaca, vyrobim z neho DKMS balik (to uz nie je uplna trivialita, ale rozhodne je to lepsie nez kompilovat cele jadro), otestujem ze chodi, hotovo.
Skratka kvoli jednemu zariadeniu (DVB-T) sa neoplati prirobit si kopec roboty, rozbit si balicky jadra a potencialne prist o updaty jadra.

Ano, jsem si vedom, ze v distribuci je kernel patchovany proti ciste verzi z kernel.org Nevim jake patche vsechny tam davaji lidi z linuxTV.org ale minimalne  ty, co se tykaji video/TV zarizeni. Subsystem kolem tehle ovladacu se vyviji tak rychle, ze se neda jednoduse bez uprav vytahnout ovladac z 3.7.x a prelozit pro mnohem starsi jadro co ma Debian. Jadro si konfiguruju v menuconfigu a pak udelam deb balik. Pritom tam mam i naka sva dalsi specificka nastaveni, uz v minulosti jsem tam musel sahat kuli RAID radici a jinym vecem, takze si prenasim a aktualizuju svuj .config. Take obcas prekladam orezana jadra pro mala embedded PC z duvodu kere si zminil.

Citace od: Palo M. kdy 18. 12. 2013, 06:51:55
Vies, ide to urobit aj uplne prasacky a stale to bude akoze fungovat: Sam si skompilujes nejake jadro a len tak ho nejako svacnes do suboroveho systemu (make install, ci dokonca cp), skompilujes prasacky nvidiacky .run ktory rozkopiruje vselico hore-dole, dopises do grub.cfg staticku polozku s vlastnym jadrom aby ti to vobec bootlo a ked pouzijes vzajomne kompatibilne verzie, tak to nakoniec mozes dostat do chodiveho stavu a bude to asi aj celkom funkcne... v tom danom case... ak nenarazis na to, ze nejaky iny program ktory by si chcel bude potrebovat nejake zavislosti... Ale potom priebezne sleduj, ci nebola vydana opravna verzia jadra a opakuj to cele znova...

Radsi tedy budu mit nekoser jadro mimo distribuci, kde mi vsechen HW funguje nez naopak. Neprovozuju zadny server nebo tak neco, kde bych muzel mit 100% bezp. zaplaty.

Citace od: Palo M. kdy 18. 12. 2013, 06:51:55
Ale v tom pripade vobec nemusis mat Debian, mozes si dat nejaky Linux From Scratch alebo nieco podobne. Vyhoda Debianu je prave v jeho balickovacom systeme, v bezpecnostnych updatoch a pri stable vetve aj v tom, ze jednotlive verzie balikov spolu funguju - a pre vela z nas su tie vyhody take vyrazne, ze nam nevadia mierne starsie verzie jednotlivych programov. Ale ked zacnes v systemovych zalezitostiach (akou jadro rozhodne je) obchadzat balickovaci system, tak tym stratis vyhody, ktore to prinasa, stratis stabilitu... a ostanu ti akurat tie starsie verzie programov. A pritom sa este aj narobis a budes zlozito robit nieco "po starom" aj ked dnes uz sa to da urobit omnoho jednoduchsie.

Jo, to je mozny. Tehda mi Debian pripadal jako dobra volba nekde uprostred mezi distribucema pro klikace typu Ubuntu kde si poradne nic nenastavim a nic se nenaucim a harcore distibucema typu LFS, Gentoo, Arch... kde se zas musi kompilovat vsechno. Proste jsem chtel minimalni instalaci s prikazovou radkou, dointalovat si X a do nej spravce oken podle sveho vyberu (zadne KDE a pod. molochy) a postupne si to tak rozvijet. Ale postupne jsem se dostal ke spicializovanym programkum, kere stejne nejsou v distru a musim si je prekladat, zaroven to ma fungovat i jako klasicky desktop. Tak nevim jesi je neco lepsiho, mozna jo, ale jit na uplne jinou distribuci se mi nechce...

Palo M.

Tak pises, ze potrebujes verziu jadra minimalne 3.7.1. A ja som uz predtym napisal, ze vo wheezy-backports je 3.11. Rovnako je 3.11 aj v testingu ci unstable. IMHO 3.11 > 3.7...

Ja som si cez DKMS musel pridat modul pre senzorovy chip, odvtedy som to nemusel updatovat vobec. Zmenene hlavicky jadra sa nedeju v ramci jednej verzie jadra (ak mas povedzme verziu 3.2 z distribucie a chodia k nej priebezne updaty, hlavicky sa nemenia nekompatibilnym sposobom, takze je to stale rovnako kompilovatelne). Az ked si povies, ze namiesto jadra 3.2 pouzijes jadro 3.10, tam uz mozu byt hlavicky ine (ale nemusi sa to tykat tvojho modulu), ale to sa ti neupdatne "samo", v takom pripade to robis manualne, mas na to cas a skontrolujes aj, ci DKMS zafunguje (a ak nie, tak ten modul doplnis o podporu noveho jadra).

Prave co sa tyka ovladaca grafiky a jadra, ist mimo distribucnych balikov moze neskor vyrobit zavislostne problemy, z ktorych sa tazko vysekava. To, ze v distribucnych balickoch nie je nejaky specialny program, ktory chces pouzivat, takze si ho musis sam skompilovat, vacsinou nie je vobec problem (pretoze od toho programu potom nezavisi plno inych veci).

S libc byva otrava, ale doteraz som nastastie nemal problem so zdrojakmi programov (isli skompilovat aj so starsou verziou libc), len s binarkami (dynamicky linkovali libc a ocakavali nejaku minimalnu verziu, novsiu nez ta co bola v systeme). Potom je este moznost hacknut to pomocou LD_PRELOAD a novsiu verziu libc mat nakopirovanu niekde mimo systemu s tym progamom (tato finta sa inak dost casto pouziva napriklad pri niektorych hrach - nie je to sice idealne mat aj inu verziu dynamickych kniznic oproti systemovej, ale zase je to funkcne riesenie, vo vacsine pripadov ta nedostatok pamate netrapi a hlavne to nerozbija cely system kvoli nejakemu jednemu specifickemu programu).

Neviem co presne za "specializovane programky" pouzivas, ci su sirene len ako binarky alebo aj ako zdrojaky. Ale v pripade vlastnej kompilacie som zistil, ze je velmi vhodne vyhnut sa "make install". Lepsie je dany program skompilovat vo virtualnej masine a tam pouzit checkinstall a takto vygenerovany balik potom nainstalovat na hlavnej desktopovej masine. Ak mam balik, viem ho kedykolvek odinstalovat (nie vsade sa autori zdrojakov "obtazuju" s "make uninstall", skor by som povedal, ze vacsinou uninstall target v makefile uplne chyba). A virtual je dobre pouzit z dvoch dovodov: 1. Ten checkinstall nemusi vzdy 100% zafungovat, ak su makefiles nie celkom korektne a robia nejake kopirovacie divociny, tak sa moze do systemu nakopirovat aj nieco, co nie je sucastou vysledneho balika a je to potom "neodinstalovatelne" a tazko sa to hlada. Oproti tomu pri instalacii vygenerovaneho balika system presne vie, co sa kde nakopirovalo a vie to v pripade potreby kompletne purgnut (mozni "neodinstalovatelni duchovia" ostanu vo virtuale a nezahnoja desktopovy stroj). 2. Na skompilovanie programu mozu byt potrebne rozne *-dev baliky, ktore na desktopovom stroji inak nemaju opodstatnenie, pripadne ani nie su v distribucii (alebo su distribucne baliky vyrobene s inymi volbami, napriklad curl, cares, wxwidgets, ...) a pre dany program treba najprv kompilovat/instalovat 3rd party kniznice. Skratka vo virtuale sa s tym da vyhrat a ked to nahodou neklapne, tak rozhaseny buildovaci virtual ti neprirobi tolko roboty, co rozhaseny hlavny desktop. A nie je to prakticky ziadna robota navyse, ak sa ti jednoduchy program normalne skompiluje, tak checkinstall tiez vzdy zafunguje.

Takze z tvojho popisu pouzitia mi Debian stale pripada ako vhodny (vlastne aj ja ho pouzivam podobne)... ovsem do jadra a ovladacov nerypem kym nemusim (a z tvojho popisu sa mi tiez zda, ze by si nemusel any ty a vyhol by si sa problemom typu $SUBJECT).

RayeR

Citace od: Palo M. kdy 19. 12. 2013, 05:51:10
Tak pises, ze potrebujes verziu jadra minimalne 3.7.1. A ja som uz predtym napisal, ze vo wheezy-backports je 3.11. Rovnako je 3.11 aj v testingu ci unstable. IMHO 3.11 > 3.7...

Aha, pardon, tak to jsem se prekouk, myslel jsem, ze to je 3.1.1, nejak sem byl zvyklej na to ze druhy cislo je jednociferny a treti 1-2 ciferny...
Tak to este prubnu, jesi to rozjedu debianim balikem nvidia glx...

Citace od: Palo M. kdy 19. 12. 2013, 05:51:10
Ja som si cez DKMS musel pridat modul pre senzorovy chip, odvtedy som to nemusel updatovat vobec.
...

OK, na to se budu muset podivat, jaik ses tim DKMS naraba, jesi mas po ruce link na nejaky tutorial...

Citace od: Palo M. kdy 19. 12. 2013, 05:51:10
S libc byva otrava, ale doteraz som nastastie nemal problem so zdrojakmi programov (isli skompilovat aj so starsou verziou libc), len s binarkami (dynamicky linkovali libc a ocakavali nejaku minimalnu verziu, novsiu nez ta co bola v systeme). Potom je este moznost hacknut to pomocou LD_PRELOAD a novsiu verziu libc mat nakopirovanu niekde mimo systemu s tym progamom (tato finta sa inak dost casto pouziva napriklad pri niektorych hrach - nie je to sice idealne mat aj inu verziu dynamickych kniznic oproti systemovej, ale zase je to funkcne riesenie, vo vacsine pripadov ta nedostatok pamate netrapi a hlavne to nerozbija cely system kvoli nejakemu jednemu specifickemu programu).

Aha, to taky neznam, muzes k tomu  LD_PRELOAD neco bliz? Slo mi o uz hotove binarky, kdyz byla kompilace prilis komplikovana nebo nebyl src a byla tam ta zavislost na novejsich libc. Pod woknama se to snadno vyresi nakopirovanim DLL do adresare k EXE a on primarne hleda knihovnu tam a az pak v systemu, takze tohle je nejaka obdoba?

Citace od: Palo M. kdy 19. 12. 2013, 05:51:10
...
Na skompilovanie programu mozu byt potrebne rozne *-dev baliky, ktore na desktopovom stroji inak nemaju opodstatnenie, pripadne ani nie su v distribucii (alebo su distribucne baliky vyrobene s inymi volbami, napriklad curl, cares, wxwidgets, ...) a pre dany program treba najprv kompilovat/instalovat 3rd party kniznice. Skratka vo virtuale sa s tym da vyhrat a ked to nahodou neklapne, tak rozhaseny buildovaci virtual ti neprirobi tolko roboty, co rozhaseny hlavny desktop. A nie je to prakticky ziadna robota navyse, ak sa ti jednoduchy program normalne skompiluje, tak checkinstall tiez vzdy zafunguje.

Jo to ma neco do sebe. Vlastni baliky programu zatim delat neumim, jak rikas s make uninstall bejva problem. Moje vlastni programky sou zatim jednoducha binarka - 1 soubor, takze tam nakou instalaci neresim, ale u dalsich programu, kde sou i nake knihovny a vic souboru by se to hodilo udelat distribucni deb.

Palo M.

Citace od: RayeR kdy 19. 12. 2013, 19:21:37OK, na to se budu muset podivat, jaik ses tim DKMS naraba, jesi mas po ruce link na nejaky tutorial...
Predpokladam, ze DKMS uz mas nainstalovane (kvoli tym VirtualBox modulom), takze si pozri:
more /usr/share/doc/dkms/HOWTO.Debian
more /usr/share/doc/dkms/examples/sample.conf
man dkms

V podstate ide len o rozbalenie zdrojaku toho konkretneho modulu do /usr/src/<menomodulu>-<verziamodulu>, vytvorenie spravneho dkms.conf a potom uz len frcis s jednotlivymi prikazmi podla HOWTO.Debian. Ten dkms.conf vacsinou staci pomerne jednoduchy, mozes sa inspirovat aj tuto: https://wiki.kubuntu.org/Kernel/Dev/DKMSPackaging a samozrejme si mozes aj pozriet, ako je to urobene v tych virtualboxovych DKMS moduloch (tam je myslim z jedneho zdrojoveho adresara generovanych niekolko modulov jadra, takze je to uz trocha komplexnejsi priklad). A tiez sa cely proces kompilovania da absolvovat vo virtualnej buildovacej masine, nakoniec vyrobit balik cez dkms mkdeb a na desktope potom staci len nainstalovat ten dany balik.

Citace od: RayeR kdy 19. 12. 2013, 19:21:37Aha, to taky neznam, muzes k tomu  LD_PRELOAD neco bliz? Slo mi o uz hotove binarky, kdyz byla kompilace prilis komplikovana nebo nebyl src a byla tam ta zavislost na novejsich libc. Pod woknama se to snadno vyresi nakopirovanim DLL do adresare k EXE a on primarne hleda knihovnu tam a az pak v systemu, takze tohle je nejaka obdoba?
Suchu teoriu o dynamickom linkovani najdes v:
man ld.so
Premennu LD_LIBRARY_PATH asi poznas, ta sa pouziva ak potrebujes pridat cestu k nejakym dalsim dynamickym knizniciam (typicky specificke kniznice pre dany program, kde nema zmysel robit ich systemove, pretoze ich pouziva len tento program). Premenna LD_PRELOAD je nieco podobne, akurat ze sluzi na override (aj systemovych kniznic).
Hodim priklad, aby ta teoria mala zmysel: Mas dynamicky linkovanu binarku v /opt/app1/bin/app1 a cez ldd zistis, ze dynamicky linkuje (systemovu) /lib/libc.so.6, ale ldd zaroven zanadava, ze GLIBC_2.xx nebolo najdene (tj. systemova libc.so.6 je skompilovana so starsou verziou glibc). Pri pokuse o spustenie /opt/app1/bin/app1 ti to samozrejme zhuci. Takze urobis to, ze nakopirujes novsiu verziu libc.so.6 (pre jednoduchost povedzme ze ju manualne vypitves z novsieho balika z unstable/testing, v horsom pripade ju budes musiet sam skompilovat) do /opt/app1/lib/libc.so.6
No a urobis si jednoduchy wrapper /opt/app1/run:
#!/bin/sh
LD_PRELOAD=/opt/app1/lib/libc.so.6 /opt/app1/bin/app1

A ked spustis /opt/app1/run, tak uz to frci (pouzije sa /opt/app1/lib/libc.so.6 namiesto systemovej /lib/libc.so.6).
A ldd tiez berie LD_PRELOAD do uvahy, takze:
LD_PRELOAD=/opt/app1/lib/libc.so.6 ldd /opt/app1/bin/app1
ti ukaze, ze sa bude pouzivat prave ta specialna verzia (a uz nenadava, ze GLIBC_2.xx nebolo najdene, pretoze v tej specialnej verzii dane glibc je)

Citace od: RayeR kdy 19. 12. 2013, 19:21:37Jo to ma neco do sebe. Vlastni baliky programu zatim delat neumim, jak rikas s make uninstall bejva problem. Moje vlastni programky sou zatim jednoducha binarka - 1 soubor, takze tam nakou instalaci neresim, ale u dalsich programu, kde sou i nake knihovny a vic souboru by se to hodilo udelat distribucni deb.
Vhodny priklad na vyuzitie checkinstall je tu: http://josesantiagojr.com/post/41299188705/install-ffmpeg-on-ubuntu-from-source
Pre vlastnu potrebu je to vacsinou postacujuci sposob na vytvorenie balika (nie je to vhodne na zlozitejsie baliky, ak vyzadujes zavislosti na inych balikoch, patche voci upstreamu a podobne).

RayeR

Tak nakonec jsem si prelozil jadro 3.12.6 z debian source balicku (stejne byla potreba jedna mala uprava v modulu tuneru), nainstaloval dkms a nvidia-legacy-304xx-driver a vali to dobre. Jak jsem koukal, tak tam zrovna resi tu podobu funkce i2c_del_adapter() pomoci nakych ifdefu podle verze jadra se definuje makro a takovy obskurity...

>Palo M.
Dik za rady, postupne si to nejak zpracuju :)