Debian Sid + nvidia: no such device

Asztali gépemen nyomtam egy dist-upgradet, mert a gyorsan kellett szerkesztenem egy prezentációt és valahogy "lekopott" a rendszerről a kpresenter. Elég vicces a dolog mert a frissítés felénél a GTK-s alkalmazások ablakkezelése E17 alatt teljesen széthullottak. Reboot után jött a szokásos nvidia96xx telepítése, de a gyári telepítő SIGTERM-el kilép. Mivel gyorsan kellett a gép, gondoltam, megpróbálkozom repoból telepíteni az xorg-nvidia-legacy csomagot. Az szépen fel is ment, aztán X indításakor dobott egy nvidia.ko: No such device hibaüzenetet. Némi netezés után kiderült, hogy a nouveau xorg csomag a bűnös. A probléma megoldása: leszedni az xserver-xorg-video-nouveau csomagot (panaszkodni fog xserver-xorg-video-all).

Továbbá, jó lenne rálépni vagy az apt vagy a dpkg készítőinek a golyóira, mert továbbra sem ellenőrzi a telepítésnél a rendelkezésre álló lemezterületet, és megint eljátszotta, hogy rendszer frissítése közben kifogyott a szabad hely. Szerencsére dist-upgradenél, figyelmen kívül hagyja az egyszer megkezdett és félbeszakított telepítést, ezért újratelepíti a törött csomagokat is...

( uid_194 | 2011. 04. 30., szo – 18:50 )

Elvileg az apt megmondja, hogy a telepites +ennyi helyet fog hasznalni. Akkor van lehetoseged megnezni, hogy van-e annyi szabad.

Magatol nem fogja megnezni, mert igen nehez lenne azt korrektul megcsinalni. Pelda kedveert, tegyuk fel, hogy az /usr vagy annak egy resze kulon particion van. A /-n van 3G szabad hely, /usr-en van 1Mb. Telepitenel egy programot, az apt annyit tud, hogy kibontva az 300Mb, de arrol fogalma sincs amig le nem tolti, hogy az hova telepulne, igy nem tud rakerdezni. Persze megkerdezheti ezt letoltes utan is, amikor mar at tud szaladni a csomagon es osszeszamolhatja, hogy hova mennyit nyitna ki, de... ez parszaz csomag letoltesenel es telepitesenel irgalmatlanul lassu lenne.

Sokkal jobb, szerintem, a jelenlegi megoldas, miszerint megmondja, hogy ennyi helyet fog pluszban foglalni az upgrade, "yes/no?". Az ember megnezni, konstatalja, hogy jajjhat mar megint elfogyott a hely, es irt egy picit, es utana nyom yest, nem pedig agyatlanul leokezza.

--
|8]

Archlinux: kitorlok kezzel a cache-bol (/var/cache/pacman/pkg ami amugy backupra tokeletes)

Viccen kivul meg sosem nyomtam update-et tele gepen, kivancsi lennek en is.

Xorg no such device pedig driverproblema szokott lenni tobbnyire (bar akkor el se indul az X es ugy dobja ezt)

Amugy itt pl. nem is lehet fent egyszerre binaris nvidia driver es nouveau, libgl utkozik az nvidia-utilsszal, ha felkerul az egyik, megkerdezi, hogy torolje-e a masikat. Sose ertettem debianeknal ezt a kenyszeredve "rakjuk fel az osszes video drivert" szerencsetlenkedest

Ez nagyon szar kifogás.
Az apt tudja, hogy hol van a cache könyvtár helyileg, ebből adódóan ismeri a teljes elérési utat. Ezen elérési út elemei összevethetőek pl. a df kimenetében található elérési utakkal, ergo a máris tudhatja, hogy elegendő hely áll-e majdan rendelkezésre a letöltéshez ÉS mennyivel lesz kevesebb a hely a letöltés után. Ezzel már alapban sok fejfájás megoldható, mert a legtöbb rendszeren a cache rendszerpartíción van, és sokszor pont annyi hely hiányzik amennyit a cache vesz el.
Az dpkg jelenlegi felállásban képes követni és ellenőrizni az összes csomag függőségét, egy csomag leírásába mindössze pár extra sor jönne be azzal, ha az elérési utakhoz tartozó méretekre lenne bontva a csomag mérete. Ha képes a user kivárni, míg végignyálazza a csomagok adatbázisát a telepítő, szerintem kibírja azt az extra 30 vagy 40 másodpercet ami a méretek ellenőrzésével megy el.
T'od, userfriendly...
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

Igen, az apt meg tudja nezni, hogy hova fogja letolteni. Es ott meg is nezhetne, hogy van-e eleg szabad hely. De az eleg felesleges, mert ha nincs, akkor meg telepites elott, letoltes kozben ez kiderul, es nem tortenik nagyobb baj.

Ketsegtelen, meg lehet csinalni, hogy a dpkg is ellenorizze a szabad helyet, csak baromira felesleges, amikor az elejen megmondja neked az apt, hogy mennyi helyet fog foglalni, es ezt te leokezhatod. Ad lehetoseget arra, hogy ellenorizd, es felszabadits. Sokkal egyszerubb es baratsagosabb igy, mint minden csomagnal mindezt vegigjatszani, es sokkal kevesebb hibara ad lehetoseget.

Ha te olyan hulye vagy - mar elnezest - hogy ugy okezod le, hogy nem nezed meg, hogy az ugy jo lesz-e, az mar a te hibad.

Arrol nem is beszelve, hogy egy csomag helyfoglalasat nem is tudja mindig megallapitani a dpkg: pl ha maintainer script letrehoz pl egy adatbazist, maris ott a lehetoseg, hogy akozben telik be. Szinten elofordulhat, hogy a hely ugyan nem, de az inodeok elfogynak, vagy n+1 mas furcsa lehetoseg amire nem gondoltal se te, se a fejlesztok.

Baratsagosabb az, ha az apt az elejen ker egy Y-t. Csak nem kell mindig reflexbol entert nyomni ra, hanem esetleg at kell nezni masik terminalra es kiadni egy gyors df -h -t. Esetleg beallitani valami monitoringot, ami kiabal, ha telik a hely.

--
|8]

"Baratsagosabb "

Ertsd: lustak voltak felkeszulni az osszes hibaesetre.

"pl ha maintainer script letrehoz pl egy adatbazist"

Ergo, akkor meg a kiirt adat is hulyeseg. -> Nagyjabol ugyanott vagyunk.

Egyebkent a dolog nagyon egyszeruen megoldhato: infok kozott le kell irni, hogy jo, de meg ennyi helyet keszitsen elo a felhasznalo, azt szamolja bele, a fentebbi cumok koze be lehet irni, es hopp, maris ellenorizheto automatizaltan.

Jobb helyeken a rendszer van a felhasznalokert...

----------------
Lvl86 Troll

> Ertsd: lustak voltak felkeszulni az osszes hibaesetre.

Bzzt. Felkeszultek erre. Az elejen szol, hogy ennyi helyet fog kb foglalni, mehet-e? Ha hulye vagy es yest nyomsz, az a te bajod. A program nem fog megvedeni a sajat hulyesegedtol.

> Egyebkent a dolog nagyon egyszeruen megoldhato: infok kozott le kell irni, hogy jo, de meg ennyi helyet keszitsen elo a felhasznalo, azt szamolja bele, a fentebbi cumok koze be lehet irni, es hopp, maris ellenorizheto automatizaltan.

Ooo, jah, es a csomag maintainerek tartsak mindezt karban, naprakeszen? Most oszinten, te bevallalnad, hogy meg erre is figyelj? Mert en nem. En kinezem a felhasznaloimbol, hogy nem idiotak. Lehet, hogy en varok el sokat? :P

> Jobb helyeken a rendszer van a felhasznalokert...

Sajnalom, akkor ezek szerint a Unix tipusu rendszerek nem neked valok, mert azok bizony siman megengedik, hogy labon lodd magad.

--
|8]

"Bzzt. Felkeszultek erre. "

A "felkeszültek erre" számomra nem azt jelenti, hogy egy random számot kiír, ami aztán vagy annyi vagy nem annyi, ráadásul egy összesített számból én döntsem el, hogy az hova fog pakolni és hova nem VS. normális helyen szól, hogy te figyu, ez nem fog elférni, folytatod?

Máshol érdekes módon meg tudták oldani.

"Ooo, jah, es a csomag maintainerek tartsak mindezt karban, naprakeszen?"

Igen, a kedves maintainerek tartsák karban a szarjukat, ha már elvállalták. És igenis ismerjék azt, amit karbantartanak. (Persze, Debillánynál már láttuk példáját annak, hogy ez nem létfontosságú a feladat végrehajtásához).

"Sajnalom, akkor ezek szerint a Unix tipusu rendszerek nem neked valok"

Meglepő módon, ezt OSX alatt képesek voltak megoldani. Persze, ez meg GNU. Nincs több kérdésem.

--

Szóval az, hogy technikailag nehéz az ne legyen már kifogás.

----------------
Lvl86 Troll

Nem vilagos, hogy jon ez ide. Drepper egy pocs, ugyanugy ahogy azon emberek is, akik sirnak hogy jajj ezt nem tudja a rendszer, jajj azt nem tudja, de se arra nem hajlandoak, hogy utanajarjanak, hogy vajh' miert nem, es esetleg megertsek, hogy nem olyan egyszeru a problema, mint amilyennek ok latjak a kenyelmes karosszekben hatradolve, sem arra, hogy esetleg barmit is tegyenek az ugy erdekeben (akar egy bugreport, akar patch formajaban).

Az ilyen emberekert nem kar. Akinek nem tetszik, ne hasznaljon linuxot, nem valo az mindenkinek, es ez igy teljesen rendben is van.

--
|8]

> A program nem fog megvedeni a sajat hulyesegedtol.

Még szerencse, hogy feltalálták a számítógépet a számítási feladatokra. A binuxos számítógépek pedig feltalálták az algernon-t, ami egy olyan igénytelen biológiai DSP, ami visszakérdezés és gondolkodás nélkül elvégzi a nevezett műveleteket, igaz lassabban és hibával teli. De ehhez csak egy kis kannás bor kell neki.

Hat, epp most hasalt el egy .Net 3.5 telepites windowson, mert telepites elott, amikor megnezte ugyan volt meg eleg hely, kozben valami szepen feltoltotte. Oops.

Az apt pedig teljesen felhasznalobarat. Ha a dependenciakkal bajod van, az legfeljebb a csomagolok hibaja lehet, nem az apt sajatossaga. Persze kivancsi lennek, hogyan maskepp oldanad meg.. De tenyleg.

--
|8]

Javaslom olvasd el amit irtam. Amikor "Next" -et nyomtam, meg volt hely.

Arrol volt szo, hogy az ablak user friendly, es megved, pedig nem. Annyival tesz tobbet, mint az apt, hogy telepites elejen megnezi a helyet, es arra ker egy nextet (az apt meg nem nezi meg, hanem kiirja mennyit fog foglalni, kb). Utkozben ha elfogy, pontosan ugyanugy elhasal.

Nem igazan latom, hogy ez a megoldas mennyivel lenne baratsagosabb, sot. Ha megnezte hogy van eleg hely, es tovabbment, akkor hogy kepzeli, hogy nem nezi folyamatosan, es miert hasal megis el? :P

--
|8]

Nezd, az egesz onnan indult, hogy az apt kiirta, hogy ennyi helyre van szukseg, user meg leokezta, pedig nem volt annyi hely. Hulyeseg ellen apt nem ved.

Aztan jottetek, hogy dehat mashol jol mukodik, megnezi, van-e hely! Persze, megnezi. Aztan ha kozben elfogy, ugyanugy elhasal. Igy a megnezesnek kb semmi ertelme nincs, mert hulyeseg ellen az sem ved.

Jelzem, epp most csinaltam egy masik tesztet, telepitettem egy programot winre, aminek egy resze ment (volna) a system konyvtarba, a masik resze meg ahova mondtam. Tok jol megnezte a telepito, hogy a D:\-n van rengeteg hely, de az fel se tunt, hogy a C:\-n semmi nincs neki, es siman tovabbengedett.

Ez mennyivel jobb, mint az apt megoldasa? Az legalabb nem vezet felre. En baratsagosabbnak tartom azt, ha egy program inkabb ram biz valamit, minthogy hulyeseget csinaljon, mert o aztan biztosan jobban tudja.

--
|8]

Magyarazd el, miert jobb a windowsos megoldas, mert en nem ertem, komolyan.

Foleg azutan nem ertem, hogy - idezek toled -:

Ahhaha, pedig a Windowson, OS Xen is megoldott ez.

Es nem, nem megoldott, mint azt fentebb irtam. Windowson ugyanugy elhasal az install, ha epp azon a particion nincs hely, amit nem figyelt valami furcsa oknal fogva. Mert bar megvan benne a helyfigyeles egy evtizede, azota se tudtak beleirni, hogy korrektul mukodjon. Ejnye.

--
|8]

Koszonom. Ezesetben szeretnem udvozolni a threadben az aptot hasznalni nem tudokat is, mert az a gyanum, hogy mindket esetben rettento egyszeru a helyzet: a user hulye, es nem nezett korbe.

(Ami alatamasztja azon allitasom, hogy a hulyeseg ellen semmilyen program nem ved, ezert felesleges is ezzel probalkozni :P)

--
|8]

Persze, le lehet egyszerusiteni a problemat, es a szonyeg ala soporni. Valo igaz, az is egy megoldas, mea culpa! Elfelejtettem, hogy vannak akik megelegszenek latszat-javitasokkal. "Sorry, ha tobb particiod van akkor ez az informacio lehet hogy teljesen szar!"

De most tenyleg, magyarazza mar el nekem valaki, hogy miert jobb az, hogy a program azt mondja, hogy van eleg szabad hely, es utana megis elfailel, mint az, hogy ram bizza, nezzem meg, es ha felrenezem, akkor hasal el? Mert hamar olyan jol meg van valositva a szabad hely ellenorzes mas rendszereken, amit masok (tobbek kozt te is) emlitettel, akkor miert nem mukodik az korrektul? Es miert jobb az a takolt megoldas annal, mint amit az apt csinal?

--
|8]

En sem ertem hogyan jutottal el attol a problematol amit saxus felvetett (kiir egy X szamot es megsem annyit hasznal valojaban) odaig, hogy a telepito minden masodpecrben figyelgesse nem-e fogyott-e el alola a terulet (amit amugy trivialisan semmi ertelme, ugyis megtudod amikor bekovetkezik).

> En sem ertem hogyan jutottal el attol a problematol amit saxus felvetett

Nagyon egyszeruen: atgondoltam a problemat. Ime a gondolatmenet:

- Tegyuk fel, hogy van egy programunk, pontosan tudjuk mekkora a merete, es mennyi helyet igenyel a telepites.
- Megnezzuk, hogy van-e eleg hely a celteruleten, ha nincs, szolunk usernek, ha van, akkor vagy megyunk tovabb automatice, vagy varunk egy okera a biztonsag kedveert.
- Ha ezen tuljutottunk, elindul a telepites.
- Mi tortenik, ha ekozben valami megis elfogyasztotta a helyet? Mert pl egy particio van, es mennek egyeb letoltesek? Vagy n+1 egyeb lehetoseg van? (Az pedig, hogy egy szamitogep, plane otthoni, mast is csinal, mint egy terminalt futtat, lassuk be, eleg valoszinu helyzet)
- Elszallunk, pontosan ugyanugy, ahogy most.

Na, ezt hogyan veded ki? Vagy ha nem akarod kivedeni, akkor mi ertelme az egesz bohockodasnak? Csak rosszabbodik tole a helyzet.

Na, igy jutottam el odaig, ahova.

> amit amugy trivialisan semmi ertelme, ugyis megtudod amikor bekovetkezik

Igen, most is ez tortenik, es ez az egesz siras, hogy dehat az apt nem szol elore, butasag. Mert ha telepites elott van is hely, semmi nem garantalja, hogy kesobb is lesz, amikor a telepites tenyleg megkezdodik.

--
|8]

Te tenyleg bolcsesz lehetsz... A problema amit felvetettek nem az, amit te "atgondoltal". Ennyi erovel 20 masik problemat is atgondolhattal volna, pontosan ugyanannyira lenne igazad.

Nem ugy tunik hogy felfogtad volna az eredeti problemat.

Azt, ami te feszegetsz, pedig mar reg megoldottak (leven trivialis) azzal, amit irtam. Ha menet kozben fogy el a hely, akkor ertesulsz a hibarol es szepen rollback.

> Azt, ami te feszegetsz, pedig mar reg megoldottak (leven trivialis) azzal, amit irtam. Ha menet kozben fogy el a hely, akkor ertesulsz a hibarol es szepen rollback.

Ez tortenik most, egy picit magasabb szinten. Es ez nem jo (allitolag).

Nincs eleg hely -> ertesulsz a hibarol es szepen rollback.

--
|8]

azert teny, hogy en is hozzaszoktam a dolgok atgondolasahoz Linuxon yes nyomasa elott.

De ket egyeb jo ervem az apt ellen:

-x86_64 vs x86: egyedul debianhoz es buguntuhoz kell kulon 64 bites valtozatot csomagolni (pl. Skype-bol), nem azert, mert azokhoz van, hanem mert az apt 2011-re nem volt kepes lehetove tenni (yummal, zypperrel pacmannel stb.-vel ellentetben) hogy ugyan ne kelljen mar egy 32 bites debhez dpkg --force-architecture kapcsolot hasznalni, es annak a hasznalata utan google-ezni egy ilyen felhasznalobarat rendszeren, mint az Ubuntu.

-felraktam a LibreOffice-t Archlinuxra:
pacman -S libreoffice
libreoffice conflicts with openoffice.org, remove openoffice.org? y
es fent volt, minden ment tovabb.
Ennek oromore buzditottam egy Ubuntus haveromat is, aki nem mellesleg nem hulye hozza, hogy tegye fel az Ubrokajara a LibreOffice-t, egy ora mulva anyazva irta, hogy a ppa-bol felteve minden apt inditasnal mittudomenmilyen hibauzenetet kapott, es apt-get -f sem segitett ha jol emlekszem, ujrarakta az Ubuntut (bar lehet en talatam volna neki ra megoldast)

> -x86_64 vs x86

Ez nem apt hiba, hanem a Debian rendszer hianyossaga (apthoz is nyilvan kellett support, de az onmagaban meg edeskeves, es az volt az egyszerubb resz). Volt. 2011-re kepesek voltak megoldani (a most kijott Ubuntu Natty mar tamogatja ezt, ha nem csalnak az informacioim), szerintem egesz elegansan.

http://wiki.debian.org/Multiarch - erdemes atolvasni, tanulsagos.

> hogy a ppa-bol felteve minden

Ne hasonlitsunk mar ossze egy ppa-t hivatalos distro csomaggal... Ennyi erovel anyazzunk egy sort azon, hogy ha ./configure && make && make installal felteszek valami random programot az szetszedi a rendszert izekre.. fuj mekkora szar ez a $csomagkezelo...

(Igen, a PPA-k tobbsege hasznalhatatlan szar. De ez megint nem az apt hibaja, hanem aze, aki a kerdeses ppa-t osszeganyolta.)

--
|8]

furcsamod amit aur-bol feltettem az sosem kurta meg el a dependency-ket (pedig az se keves csomag volt)

Yumhoz (2 eve) meg agyatlanul adogattam anno hozza a repokat, full nem is ertettem meg hozza, megse sirt soha hogy rossz update, egyszer az nvidia drivert kurtam el, de annyi volt az egesz, helyre lehetett hozni

A multiarch meg 2011-ben legyen mar default, ha masoknal mar 2008-ban is regota az volt

Ez mindossze annyit jelent, hogy akik a csomagokat csinaltak, azok nem olyan szutykokat raktak ossze, mint ami a PPA-k tobbsegeben fellelheto. Az eszkozrol ez nem sokat mond.

Multiarch mehetett volna gyorsabban is, valoban, foleg hogy ~2003-4 korul kezdodott a mozgolodas ha jol remlik.

--
|8]

"Akkor van lehetoseged megnezni, hogy van-e annyi szabad."

Azt hittem, a szamitogepet azert talaltak fel, hogy megkonnyitse az eletunket...

"Magatol nem fogja megnezni, mert igen nehez lenne azt korrektul megcsinalni. "

Most attol eltekintve, hogy mar csak emiatt is hulyeseg ez a szanaszetszort konyvtarstruktura (mennyivel egyszerubb egy OSX-s /Application vagy egy Program Files), oszinten szolva kit erdekel? Nem megoldhatatlan feladat, oldjak meg.

----------------
Lvl86 Troll

> Azt hittem, a szamitogepet azert talaltak fel, hogy megkonnyitse az eletunket...

Igen. Az en eletemet a jelenlegi rendszer sokkal jobban megkonnyiti, mintha mindig ki kene kapcsolnom, hogy minden egyes csomagnal nezze vegig van-e eleg szabad hely, mert en vagyok annyira intelligens, hogy nem allok neki vakon upgradelni.

Ennyi erovel dobjuk mar ki a C-t, mert siman lehet vele szar programot irni, ergo nem baratsagos, nem konnyiti meg az eletunk, es lehet olyan nyelvet irni, aminel peldaul nem kell pointerekkel torodni, es az mennyivel jobb mar!

> Most attol eltekintve, hogy mar csak emiatt is hulyeseg ez a szanaszetszort konyvtarstruktura (mennyivel egyszerubb egy OSX-s /Application vagy egy Program Files), oszinten szolva kit erdekel? Nem megoldhatatlan feladat, oldjak meg.

Patcheket biztos elfogadnak. Hajra!

--
|8]