Új hozzászólás Aktív témák
-
Sipi
addikt
válasz
klayton#1
#3410
üzenetére
Asszem ez attól van, hogy genkernellel csináltad, ami RAMdrive-os indítást készít. De ehhez a leírásban kövesd az utasításokat, hogyan kell a grubot beállítani, mert teljesen más! genkernel esetén szinte mindent modulba pakol, még a merevlemez-kezelést is. Emiatt a bootnál betölti a kernel moduljait memóriába, onnan dolgozik, és csak utána csatolja a root fájlrendszert.
A block a blokkeszközt jelöli, nem ismeri fel, mi az az egyes vinyó első partíciója.
S
-
Sipi
addikt
-
Sipi
addikt
válasz
klayton#1
#3406
üzenetére
Ez vagy azt jelenti, hogy nem jó a root= paraméter, nem jól adtad meg a root partíció helyét, vagy esetleg nincs a kernelben az IDE-vezérlőd beleforgatva. (Modulként nem jó.) Ha sda2 a root, akkor az jó, a kerneleddel lesz gond.
Ha kézzel csináltad, akkor a chipsetnek megfelelő drivereket bele kell tenni, de első próbálkozásnak csináld inkább genkernellel, az mindent beletesz modulként és megoldja, hogy jó legyen. (Kell a vezérlőd drivere, meg vinyótámogatás, meg nem emlékszemmég mik.)
Sipi
-
Sipi
addikt
válasz
klayton#1
#3404
üzenetére
Hm, kicsit furcsa, hogy KÉT darab bootolható partíciód van. Nekem dualbootos gépen csak egy, a Windows-é, mert az máshogy nem indul. Szerintem szedd le az sda2-ről a boot csillagot.
Az utolsó sorok meg hogyafenébe ne lennének fontosak! Abból derül ki, meddig jutott és hol hal le.
Sipi
-
Sipi
addikt
válasz
klayton#1
#3402
üzenetére
Szia!
Ha PONTOSAN azt írtad, amit a kézikünyv, az is lehet baj.
Valszeg rossz eszközneveket adtál meg a grub konfigjában. Mi a pontos hibajelzés? Mit ír ki?A Gentoo telepítőcédéjéről be tudsz bootolni, majd a leírás szerint csatold a partíciókat, amire telepítettél, meg a devet, procot, stbt. Vagyis kövesd a telepítési útmutatót (partícionálás és formázás nélkül
) addi, amíg chrootolsz az új környezetbe! Ekkor belemész a telepített Gentoo-ba, és újra konfigolni tudod a grubot.Ha az első vinyóra tetted, akkor hd0 a vinyó neve, a a másodikra, hd1. Az első partíció is 0, vagyis ha pont olyan a vinyókiosztásod, mint a telepítésnél, akkor hd0,0 lesz a root helye.
Sipi
-
Sipi
addikt
Szia!
Az OOo-t nem érdemes forrásaból feltenni, gyorsabb nem lesz tapasztalatom szerint. Ellenben _nagyon_ sokáig tart, és mivel nagyon érzékeny a beállításokra, verziókra, valószínűleg az első pár fordítás hibával le fog állni.
A KDE-t a mobil Pentium3-as laptopomon kb. egy nap alatt cakompakk újrafordítani. Böngészőből Operázok, azt nem lehet fordítani, csak binárisan feltenni. Mozillából i svan bináris csomag, szerintem azt sem érdemes (zgyanaz, mint OOo-nál.)
Szerintem ne aggódj, ha bekapcsolva tudod hagyni a gépet, kb. egy nap alatt meglesz egy újrafordítási ciklus KDE-ből. A többi pedig nem vészes, nem frissül minden naponta.
Ha nem engedélyezed a "béta" programokat (make.conf-ban az ACCEP_KEYWORDS nem ~x86), viszonylag ritkán lesznek frissítések. KDE-ből érdemes minden csomagra egyesével bekapcsolni, meg pár függőséghez, de abból meg havonta egyszer van teljes verziófrissítés.Sipi
-
Sipi
addikt
válasz
VladimirR
#3389
üzenetére
Szerintem a fő rsync szerverrel van valami gond - pár napja időnként "file size not match" hibát kapok sync után. Random ebuildek más méretűek lesznek, mint ami a manifestben van.
Egyszer volt ilyen, amikor a fő rsync merevlemezei teljesen bekepáltak, későn kapcsolták le, és majd az összes alszerver átszinkronizált róla. Akkor azt hittem, szétment a vinyóm, de kiderült, csak a Portage fa volt rossz.
A websync vagy a daily snapshot megoldás ilyenkor.
Sipi
-
Sipi
addikt
Ha a dmesg ki sem írja, hogy megtalálta, nem ez a gond. A haldaemon csoport a hal-nak kell, nem kell, hogy tagja legyél.
Tuti, hogy hiányzik valami a kernelből, ami a dinamikus felismeréshez szükséges. Bootnál felismeri, mert akkor direktben végigszkenneli az összes eszközt.
Sipi
-
Sipi
addikt
Ha ezeket bekapcsolod, mi történik?
[ ] USB announce new devices
[ ] USB device class-devices (DEPRECATED)
[ ] Dynamic USB minor allocation (EXPERIMENTAL)Úgy nézem, ez nagyon új kernel lehet, úgyhogy ne tévesszen meg a deprecated kifejezés. Egy 2.6.26-os kernel eléggé eltér a 2.6.21-től is, de ez utóbbi sem nevezhető réginek.
Sipi
-
Sipi
addikt
válasz
VladimirR
#3352
üzenetére
A bind-tools része az nslookup és a host is.
Az első haosnló a Wineshez, ha nem adsz, a default DNS servert használja, ha kötőjelet teszel utána, az utána álló nevet/címet.A fejlettebb host parancs pedig olyan, hogy ha egy nevet adsz meg neki, azt keresi, ha még egyet, azt a DNS szervernek veszi.
Sipi
-
Sipi
addikt
válasz
VladimirR
#3343
üzenetére
Nem hagysz ki semmit. A kernel üzenetében az van, hogy force use of acpi=ht. Valami miatt bekapcsolja az ACPI-s HyperThreadinget, ami olyan procin, ami nem támogatja, egyenértékű azzal, mintha kikapcsolnád az acpi-támogatást.
Talán a kernelnek meg kellene adni az acpi=noht kapcsolót, vagy kísérletezni a különféle acpi= kapcsolókkal, hátha valamelyiknél nem akar HT-t.
Sipi
-
-
Sipi
addikt
Persze, tapasztaltam. Az ablakkezelő cuccait, kwin, session manager, be kell tölteni - a kdm azt még nem húzza be. Ja, meg elkészül a személyre szabott sycoca adatbázis... Ezt tényleg csak akkor lehet előre tölteni, ha elindítasz valamit.
Tipp: van egy LD_PRELOAD nevű változó. Ezzel indítva rogramokat megadható, hogy a mögé írt libek előre töltődjenek be, minden más előtt. Azt nem tudom, mire vonatkozik, lehet, hogy csak a tényleg betöltődőkre, de egy próbát megér.
A kdm hívását pl.
LD_PRELOAD="azok a kde libek, melyek login után töltődnek" kdm
alakra írod át. Ha mákod van, ez behúz mindent, amit felsorolsz.
Sipi
-
Sipi
addikt
Ez furcsa. A kdm KDE-s program, mikor betöltődik, a qt-t, a kdebase libet be kell töltenie, valamint a kdeinit, dcopserver is elindul, nem?
A local.start-ba tegyél be valami kis hülye KDE-s programot, az a kdm után indul el, amikor már van Xorg. A kimenetét irányítsd a /dev/null-ba. Következő sorban vársz pl. 10 másodpercet, majd kinyírod.A prelink nem ehhez kell, az a programok, könyvtárak szerkezetét alakítja át, hogy ami libeket meghívnak, egy helyen legyen, a loader könnyen, a program indításakor egyből megtalálja, mikre lesz szükség, és be tudja tölteni. Így nem kell az egész kódot átnéznie, miket kell hívni.
Sipi
-
Sipi
addikt
válasz
VladimirR
#3321
üzenetére
Jajj, de kár, hogy csak most olvasom, így nem írhattam be ugyanezt.
A 3.4.6 nem ancient. A 3-as és a 4-es két külön állatfaj, nem fognak elhajtani emiatt.
Én a bugs.gentoo.org-ot jobban csípem, mert az ottani fejlesztők nagyon szoros kapcsolatban szoktak állni a programfejlesztőkkel. A gentoo-t sok progrsmíró használja amolyan homokozóládának, mert a forráskód proglémái itt tutira előjönnek. Ha a Gentoo-soknak írsz, úgyis eljut a gcc-sekhez is.Sipi
-
Sipi
addikt
válasz
VladimirR
#3316
üzenetére
99%-ban mehetsz bugreportolni a gcc-teamnek.
Ha biztos akarsz lenni, próbáld ki (ugyanígy kézzel), hogyg++ -DHAVE_CONFIG_H -I. -I../.. -I./.. -g -I/usr/include/sigc++-2.0 -I/usr/lib/sigc++-2.0/include -MT dht_manager.o -MD -MP -MF .deps/dht_manager.Tpo -c -o dht_manager.o dht_manager.cc
Illetve egyre kevesebb parancssori kapcsolóval. (A -M-esekre gondolok, az include maradhat.
)Sipi
-
Sipi
addikt
válasz
VladimirR
#3307
üzenetére
Jááááá, vagy nem mondtad, vagy nem értettem!
Csinálj hozzá ebuildet! Alap: egy létező rtorrent ebuild, átnevezed rtorrent-9999.ebuild-re. Az elejére beteszed egy másik -9999 ebuildből azt a részt, ahogy az svn-ből cincálja a dolgokat. Szépen megírod.
Vagy ha nem akarsz tökölni: innen letöltöd, beteszed a lokális Portage-fába (alapesetben /usr/local/portage szokott lenni). Aztán unmaszk meg emerge.
Sipi
-
Sipi
addikt
válasz
VladimirR
#3305
üzenetére
Tudom, írtad, csak azért írtam le megint, hogy jelezzem, ez a c++ internal error nem az az internal error, amikor a gcc fejlesztőknek sürgős bugreportot kell írni.
Memory leak csak a gcc-ben lehetne, de ennél a régi verziónál ezt kizárom. Leak lehetne még valamelyik külső lib meghívása miatt, akár a debugolás, akár a 4-es sorozat egzotikusabb dolgainak kihasználásánál. Ez megint kizárt. LD-nél sem lehet gond, mert itt a linkelésig el sem jut.
Én alapból kikapcsolom a make.conf-ban a debugot, totál felesleges... Van még az ipv6 kapcsoló, próbáld meg annak ki- és bekapcsolásával is (meg egy xmlrpc is, azt is), hátha... ipv6-tal más jellegű problémáim már adódtak (ruby, ha jól rémlik), a hibának látszólag semmi közük nem volt az ipv6-hoz.
Szerintem rtorrent-hiba, ez a cc-fájl nem is nagy (a 0.8.0-ás verzióban), lazán vinne kellene a gcc-nek.
Jut eszembe, anno a kmailnél volt olyan kiadás, amit ugyanígy nem tudtam lefordítani. Ott valamelyik -r revvel patkolták. Ma is zabál, de legalább lefordul. Ilyenkor várni szoktam, majd csak kijavítják.Sipi
-
Sipi
addikt
válasz
VladimirR
#3303
üzenetére
Ezt a hibát többnyire akkor dobja, ha kevés, és ezért elfogy a memória és swap, szerintem figyelmen kívül hagyhatod. Debugot miért kapcsolod be? Az is növeli a c++ programok fordításának memória-éhségét (ami egyébként is nagy).
Sorry, hardenedet elfelejtettem. Olyat nem használok. A /usr/profiles/hardened mappában tényleg hardmaszkolva van a teljes 4-es gcc sorozat... Pech.
Itt van pár infó arról, hogy mi vár rád, ha kézzel unmaszkolod a 4-es sorozatot, és hardeneddel akarod használni. (A 4-es még nincs felkészítve erre, ettől még működő kódot készít, csak az új funkciók nélkül.) Az utána következő válaszlevelek is érdekesek lehetnek.
Szerintem nem gcc hiba, a kmail is olyan, hogy a 800 mega memóriám eltűnik a fordítása közben. Evvan, én az rtorrentre gyanakszom. Nem hiba, inkább csak rosszul megírt kód lehet.
Sipi
-
Sipi
addikt
válasz
VladimirR
#3301
üzenetére
Eddig úgy vettem észre, hogy ha a gcc nem ad internal gcc error, contact the developers hibát, akkor az adott programmal van gond.
Az, hogy csak adott revtől jön elő, megerősít ebben. (Csak egy tipp: esetleg a forrás olyan dolgokat használna, amit a 4-es gcc-ben vezettek be.)Egyik gépemen 4.1.2, másikon 4.2-es gcc van, semmi gondom nem volt még egyikkel sem. A 4.1.2 stabil, használhatod. Szerintem érdemes áttérni a 4-es gcc-re, a plusz tudása miatt.
Sipi
-
Sipi
addikt
válasz
Proci85
#3281
üzenetére
Közvetlen lirc modul nincs. Nem ismerem a te tunered, de valszeg arra is integrálva van a vevő. Nálam csak a lirc_i2c és lirc_dev modul töltődik be, az i2c_* modulok mellett.
Viszont a v4l-modulok (bttv, conexant, ...) tartalmaznak kódrészeket, amivel az infrát kezelni lehet. Én mindig modulba teszem az összes v4l-drivert, és azt vettem észre, hogy az újabb kernelek olat is betöltenek, amit régen nem, és szerintem nincs is rá szükség.
A gpio modulra sosem volt szükségem - szerencsére, mert nekem régebben sem fordult le.
Lehet, hogy neked is modulba kellene tenned a v4l-drivereket, hátha van köztük olyan, ami kell a lirc-hez.Ja, a kernel IR moduljai máshoz kellenek, beépített infra-egységekhez, nem távirányítóhoz.
Sipi
-
-
Sipi
addikt
De igen.
Eddig még csak szenvedek vele... Millió kapcsoló, ha nem használom, be akar húzni minden szemetet, a kimenete is elég olvashatatlan. Használni meg nem fogom, mert a manual utolsó 5 oldala csak ezekkel van tele.
I/O: a Portage baja nem az, hogy a telepítés esetleg lassú, hanem hogy egyre lassabb benne minden. A tervezése rossz. A Paludis valóban gyorsabb a csomagkezelési műveletekben, a --sync is egyszerűbb, a különféle cache-eket hamar generálja. Csak hozzá kéne szokni a kezeléséhez...
Sabayon: ugyanúgy, mint a Gentoo-t. A rendes működéséhez kell neki a Portage fa, emellé a Sabayon overlay. Innentől fogva én csak szívtam vele.
Karambol okés, pár hétig segítséggel öltöztem, de azzal már semmi gond. Csak nem merek autóba ülni.
Sipi
-
Sipi
addikt
Van valaki, aki megpróbálkozott a következő, új generációs, nagysebességű cuccokkal?
- Paludis - a Portage package manager kiváltására
- einit - újfajta init system, xml alapú konfig
- initng - ez is, csak rc-config alapúNincs bátorságom feltenni, de érdekelne, mik a tapasztalatok, mekkora a sebesség-növekedés, stb, stb.
Sipi
-
Sipi
addikt
Elméletben lehetséges, csúnya hackeléssel. Ahogy dr_strange írta: átírod az ebuildet, hogy más helyre telepítse.
Az Opera összes fontos cucca alapban a /opt/opera alá megy. Ebben van egy bin könyvtár, ahol a wrapper script van. A lib alatt verziónként eltérő könyvtárak - innen sejthető, hogy fent lehet több verzió is. (Pixmapek, ikonok, kis vackok a szoksásos /usr/share alá mennek, ez nem nagy baj, ha felülíródik más versióval.)De nem hiszem, hogy minden tökéletesen működne. Az Opera egy közös konfigot használ, a /etc/opera6rc-t, ha ez verziónként eltér, gáz.
Az ebuildet alaposan nézd át, mert nagyon sok helyen hivatkozik a végleges telepítési útvonalra, sok helyen kell átírni. Ezen kívül a kész telepítésben a bin könyvtárban lévő opera scriptet is át kell írni, mert az is hivatkozik. És a /usr/bin/opera linket is nézd meg, melyikre mutat.
Szerintem nem ér ennyit a dolog.
Sipi
-
Sipi
addikt
Blokkolás: akkor fordul elő, ha X csomagnak pl. 1.1-es verzió kell valamiből, Y-nak pedig 1.2-es.
Gentoo-nál a stabil ágban leginkább akkor fordul elő, amikor egyes csomagok úgy fejlődnek, hogy átveszik más csomagok feladatát. Ilyen volt pl. a shadow, illetve az udev is. Régebben a hotplug/coldplug külön csomag volt, majd egy újabb udev átvette ezt a feladatot. Ha fenn van a hotplug/coldplug, és frissíteni akarod az udevet, ütközni fognak, hiszen az új udev egyben coldplug is.Most biztosan van fent olyan csomagod, aminek a régi udev kell. A teljes frissítés viszont látja, hogy van újabb udev is, azt akarja feltenni. Az equery d udev kiírja, milyen csomagok függnek az udevtől, estleg azt is, milyen verzió kell neki.
Sipi
-
Sipi
addikt
"avahi Add avahi/Zeroconf support
bash-completion Enable bash-completion support"Mivel ilyenkor azt írja, valami supportot tesz fel, keres rá az adott csomag nevére! Pl. az avahi is egy csomag, a bash-completion is.
links: éppen ezt nem ismerem, de igen, kikapcsolhatod. Egyébként szerintem meg tud képeket is jeleníteni - Linuxon a grafika megjelenítése karakteres konzolon is lehetséges.
A pretend és verbose kapcsolóval az emerge kiírja, az adott csomagot mikkel akarja telepíteni:
emerge -pv csomag
.
net: akkor oké. Annyi és olyan link kell, amennyi és amilyen hálózati csatolód van. Ha csak eth0, akkor net.eth0.
Sipi
-
Sipi
addikt
Net: ellenőrizd, hogy tényleg jó parancsokat írtál bele, s azt is, hogy a megfelelő interfészhez! Létezik az adott ethX interfész? Megcsináltad a szimbolikus linket a net.lo-ra? DHCP kliens két esetben kellhet: direkt azt adtad meg, vagy nem adtál meg semmit az adott interfészhez. Ilyenkor a Gentoo automatikusan úgy veszi, hogy DHCP-t használsz.
A links-et előbb írtam. Ha a pretenddel meg is nézted, láthattad: be van kapcsolva az X flag, vagyis X-támogatást kérsz. Ehhez fel kell raknia.
Desktop: igen, ilyen sorrendben.
Nvidia: nem emlékszem, hogy különösebben piszkálni kellene. Pár opció kell a drivernek, de olyan alapdolgok, amelyek szerintem a genkernellel is beállítódnak.
A genkernel simán futtatva felülírja a .configot, hiszen előre beállított dolgokat készít. Viszont meghívhatod a parancsot a --menuconfig kapcsolóval is, ekkor elkezd molyolni, majd ő maga meghívja a menuconfigot, kézzel bekapcsolhatod, ami kell, kilépsz, és ez alapján folytatja a kernel-generálást.Sipi
-
Sipi
addikt
emerge gentoolkit
Ezután lesz egy euse parancsod:euse -i flag
kiírja, mire való az adott flag, valamint hogy globális (make.conf-ban kell állítani) vagy lokális (pár csomagra érvényes, a /etc/portage/package.use fájlban kell állítani).
Az XFCE-nek nincs külön flagje. A kde, gnome flag nem igazán azt adja meg, hogy neked kde kell, hanem hogy egy adott programhoz készítsen-e kde-támogatást. Ehhez persze a kde nagy részét fel kell rakni.
Telepítés elején a links azért akart annyit emergélni, mert megadtad, hogy X támogatással forduljon. Ha nem kell, akkor a /etc/portage/package.use fájlban kapcsold ki a links-re az X támogatást, vagyis írd be ezt a sort:
www-client/links -X
Mivel a make.confban be van kapcsolva az X, azon programok, melyeknek van X-támogatsa (pl. egyszerűbb grafikus felülete, vagy kihasznál valamit az Xorgból), ezzel fordulnak. A links-nél viszont kézzel kikapcsoltad, tehát jelenleg ennél az egynél nem veszi figyelembe, a lefordított links nem támogatja az X-et.
Az xfce-hez elég az xfce4 metacsomagot emergélni. Ez nem igazi csomag, csak az van benne, hogy egy működő XFCE-felülethez milyen csomagokat telepítsen.
Sipi
-
Sipi
addikt
Miért ne lenne? Olvass csak bele jobban a kézikönyvbe!
A telepítés első lépései pl. a merevlemez előkészítése, illetve a rendszer letöltése. Bármilyen futó Linux alatt tudsz partícionálni... Utána chroot-tal átváltasz az előkészített Gentoo-ba. Ez is megy másik Linux alatt: az egyik terminálon a telepítés alatt lévő Gentoo fut, a többin az eredeti Linux. Csak akkor kell majd rebootolni, amikor az új kerneled is elkészült, és már a kész Gentoo-t akarod izzítani.Egyébként a telepítési kézikönyv a telepítő cédén is fent szokott lenni, másik terminálban én is azt kukkolom links2 vagy lynx karakteres böngészővel.
Nyugi, nekem is csak a kb. harmadik rendszerem lett épkézláb, előtte minden szart beletettem... Egyébként semmi gond. Egy Gentoo-t tényleg nem tudom elképzelni, mikor kellene nulláról újratenni. Ha rájössz, nem kell egy rakás USE flag, akkor kikapcsolod, és az emerge parancs --newuse kapcsolójával újrahúzod azokat a csomagokat, amelyeknél megváltoztak a beállítások. És onnantól olyan, mintha eredetileg így tetted volna fel. (Azt leszámítva, hogy esetleg fenn lesz a gépen pár program, könyvtár, amire nincs szükség többé. De mindegy, max. a helyet fogja.)
Sipi
-
Sipi
addikt
Tanács: NAGYON fontold meg, milyen USE flageket kapcsolsz be. Totál felesleges mindig mindent, így csak nagyméretű binárisokat kapsz, melyeknek kiskmillió "dll"-je lesz. Lassú, nehézkes lesz a géped. Ráadásul rengeteg dolgot kell fordítanod.
Főleg az elején érdemes a -X kapcsolót berakni, mert az alaprendszerhez nem kell grafikus felület, ezzel is időt nyersz. Utána pedig ötször átgondolod, kell-e pl. openexr- vagy musepack-támogatás. Ha nem tudod, mi az, inkább ne.
Hasonló módon felesleges az adatbázis-támogatás (odbc, mysql, postgresql). Otthoni gépen maximum 1-2 program lehet, aminek tényleg kell ilyen, de akkor meg már sqlite, ha választható.Egyébként a legtöbb időt a USE flagek beállítása fogja jelenteni. Nekem ma már, hogy tudom, hogyan kell csinálni, az alaprendszerem egy minimális grafikus felülettel egy nap alatt megvan. Az X is hamar települ. A Gnome, KDE, gcc és glibc az, ami sok idő.
Sipi
-
Sipi
addikt
válasz
zfarkas
#3173
üzenetére
Ja, tényleg, az örök szerelmem: ACPI és IRQ-kiosztás... nVidia/AMD alapú gépeim vannak/voltak, azokon siralmas a chipset. Furcsa fagyásoknál, lassulásnál érdemes kipróbálni a következő kernel-kapcsolókat pl. a grub.conf-ban, bootnál: noapic, pci=biosirq, pci=noacpi, esetleg nolapic, pci=nommconf. Van, hogy a modern gépeken totál rosszul lesznek kiosztva a megszakítások, ugyanazt kapja pl. a hálókártya és a vga.
Flash minden böngésző alatt trágya. A plugin cleaner nekem mindig lefogta a gépet, akkor is, ha nem volt plugin betötve (nem töltöttem be egy oldalt sem).
Sipi -
Sipi
addikt
Nekem mostanság játék, film alatt mindig csontra fagyott a gép. Egyszer sikerült felélednie, immár grafikus felület nélkül. S a dmesg-ben komplett hibaüzenet, az nVidia README-jében pedig ugyanezen hibára komplett megoldás. Azóta nem fagy.
Valószínűleg a driver szarakodik, de ehhez logokat kell nézni. A DRI hiánya official Ati és nVidia alatt kvázi minden gyorsító funkció hiányát is jelenti. Mindenképpen próbáld DRI-re bírni. Ha jól láttam, bináris Ati-drivert használsz.
Sipi -
Sipi
addikt
Akkor passz...
Gondolom, konzolban nem lassú a rendszer. Ilyen szaggatást nekem két dolog szokott okozni: a videodriver nem gyorsítja a Render és Composite funkciókat (Xorg vagy driver-hiba), illetve a kernelből kimaradt egy-két dolog. Ez utóbbit viszont nehéz eldönteni, a legújabb kernelek újdonságaitól csak pislogok.
Ja, azt nézd meg, az xvinfo, glxinfo mit ír ki! Van-e egyáltalán XVideo extension, Direct Rendering.
Sipi -
Sipi
addikt
Instabil rendszert használsz? (~x86) Csak mert most jelent meg az új Xorg, ami sok mindenben lényeges változást hozott. A bináris driverek pl. nem biztos, hogy működnek, az eddigi input-output driverek is újraforgatást igényelnek.
Az xorg-server 1.4-es verziójú. Nézd meg, mi van fent. Az x-es csomagokból javaslom, mindegyiknél kapsold ki a packages.keyword-ben, ha instabilra van állítva, és downgrade-elj az 1.3-as xorg-server és függőségeire.
Nézd meg az xorg logját, valamint a home mappában a .xsession-errors fájlt, hátha van benne valami. Első blikk pl.: valami miatt nincs bekapcsolva (vagy nem is lehet) a Render extension.
Sipi -
Sipi
addikt
Huhh.
ACPI és APM együtt ne legyen kernelben. Sok esetben fedik egymás tudását, úgyhogy vagy összeakad, vagy egyik felesleges. Ha nem őskori a gép, csak ACPI kell.
Az Intel szerint az ondemand governort érdemes használni. Egyik előnye, hogy nem kell piszkálni, másik pedig, hogy ha nem kell, hadd menjen minimumon, de ha valaminek kell az erő, akkor ne fél percig csalinkázzon a sebesség felfele, hanem egyből legyen gyors.
Van egy laptop-mode-tools program, szerintem ezt érdemes feltenni, ha laptopod van. A CPU frekvenciája csak az egyik fogyasztási tényező, nem is a legnagyobb. Ezzel még jópár dolgot lehet bekapcsolni elemes működés közben.
A cpufreqd-nél az is bezavarhatott, hgoy ennél különbözú profilokat kell megadni. Ezek pl. az elemtöltöttség, CPU hőmérséklet, terhelés, hálózati áram megléte, stb. alapján súlyoznak, majd az a profil lesz aktív, ami a legnagyobb pontot kapja. (Pl. elemről használva, egy AC-alapú profil eleve nulla pontos.) Az alapprofilok úgy vannak megadva, hogy a CP terhelés nagyságát is figyelik, százalákban, két érték között. Előfordulhat, hogy mivel az AMD64 csak két frekvencián tud menni, ez lesz: a cpufreqd nézi a terhelést, és a profilban beállítja, hogy 60-100% közötti legyen a frekvencia. Ez AMD64-en ugyanaz, a maximum. Ha viszont úgy van beállítva, hogy 40-100 között, az izgi lesz, mert mindkét fekvencia ebbe a tartományba esik... Kicsit sakkozni kell a cpufreqd-vel, mert az alap nekem sem volt jó AMD64-re, kvázi semmit sem csinált.
Sipi -
Sipi
addikt
Az udevet menet közben is leszedheted, törölheted az összes konfigját, baj nem lesz. Legfeljebb egy ideg (míg fel nem rakod) nem jönnek létre új eszközök. De az udev démon fut.
A duplikált bejegyzés talán amiatt van, hogy elmented az udev-eszközöket leállásnál. Ha régen volt másik eszköz is, akkor bekerül az elmentett fájlba, indulásnál kicsomagolja, ergo ott lesz.
Sipi -
Sipi
addikt
Uhh, eszembe juthatott volna... Ezek szerint _nagyon_ régi udev volt fent. Az udevnél volt egy váltás, a teljes konfig-részt átalakították. Azt javaslom, hogy keresd meg és töröld az _összs_ udev-es könyvtárat (etc, usr-share, usr-lib, lib, ahol találsz), majd emergéld újra. Anno nekem is volt, hogy bezavartak a régi konfigok.
Ja, előtte persze nézd át, mert más csomagok is tesznek konfigot, pl. a digikamera csomagja.
Azért gyanús ez nekem, mert az udev-hez nem kellene semmit szerkeszteni. A gépben lévő eszköz mindenképpen azonosítja magát, csak a halnál voltak anno gondok. (Mert egyes modellek nem adnak jelzést arról, hogy a tálca kinyílt, ergo nem lehetett automountolni. Ekkor tényleg kézzel kellett macerálni.)
Sipi -
Sipi
addikt
Nekem egyik gépemen sincs ilyesmi fájl... A /etc/udev-ben egy udev.conf és egy rules.d könyvtár van, ebben szám-név.rules fájlokkal. A /lib/udev-ben vannak a futtatható scriptek és programok.
A /etc/conf.d/rc-ben beállíthatod, hoy bootlogoljon, hátha az kiír valami érdemlegeset.
Sipi
[Szerkesztve] -
Sipi
addikt
Bekapcs ezeket a flageket: ctype pcre session unicode.
emerge dev-lang/php (ezekkel az új flagekkel fordítod le - amíg nincs lefordítva pl. Unicode támogatással, a phpmyadmin nem tud php-n keresztül Unicode-ot kezelni.)
Bekapcs a mysql flaget is a phpmyadminnak.
emerge phpmyadmin
Sipi -
-
Sipi
addikt
No, még egyszer. A make.conf-ban található beállítások közül csak a CFLAGS, CXXFLAGS, esetleg az LDFLAGS vonatkozik a processzorra. Az összes többi azt adja meg, emerge során mit, milyen támogatással, honnan telepítsen. CSAK a CFLAGS az, amit az architektúrádra lehet/kell szabni. Az összes többi beállítás rád van bízva, ízlés dolga, mit akarsz.
Ha az 1. link alapján megcsináltad a CFLAGS-et, akkor az jó. Ezek biztonságos flagek, ha nem instabil/béta csomagokat telepítesz, tutira menni fog vele.
Amit írtál, az csak annyi, hogy közölted az mc-vel (a beállított USE flageken keresztül), hogy települjön unicode támogatással, ugyanakkor ne ismerje a unicode-ot. Az emerge ki is írta, hogy a teljes unicode támogatáshoz kell a unicode ÉS a slang flag. Nem vagy-vagy - együtt kell mind a kettő.
Megint elmondom: nem tud senki neked ''működő'' make.conf-ot küldeni. Annak tartalmát te szerkeszted, te állítod be, mikre van szükséged. (Illetve még a /etc/portage/package.use fájlban is állítgatod a flageket, csomagonként.) Amit az emerge kiír, hogy miket lehet használni, megnézed és eldöntöd, kell-e. Ha igen, bekapcs, ha nem, kikapcs. Ha szól, hogy így és így nem megy, akkor átállítod annak megfelelően.
Sipi -
Sipi
addikt
Ne is haragudj, de:
1. Ékes angolsággal aprólékosan leírja, mi a gond, hogyan kell megoldani.
2. Ebben hol találsz te olyat, hogy az emerge abszolút nem működik? Te azt állítod, semmit az égvilágon nem tudsz telepíteni, nem tudsz keresni, leszedni - vagyis nem megy az emerge. Ezzel szemben egyetlen csomagot nem telepít. (Ráadásul azt is elmagyarázza, hogy miért nem.)
A make.conf tartalma teljesen gép- és userfüggő. Ebben talán csak a CFLAGS az, ami az adott processzorra vonatkozik, az összes többi egyéni ízlés kérdése. Az, hogy milyen FEATURES, USE, ACCEPT_KEYWORDS, PORT***, ALSA_CARDS, LIRC_DEVICES, VIDEO_CARDS, INPUT_DEVICES, LINGUAS kell, csak attól függ, mit akarsz Te a gépeden.
A biztonságos CFLAG-értékekre itt [link] találsz egy alapos összefoglalót.
Itt [link] pedig egy összefoglaló, hasznos kiindulási alap.
Sipi
[Szerkesztve] -
Sipi
addikt
Vagy vesafb, vagy valamelyik intel. A kettő együtt ne!
Intel ne legyen - az ütközni szokott az Xorggal.
Vesafb helyett vesafb-ng legyen!
A kernelben bekapcsolod a vesafb-tngt, majd alatta a Console display driver supportban a framebuffer console supportot.
Grub: a vram nem biztos, hogy kell. Az mtrr-nek érdemes paramétert adnod, nekem pl. mtrr:4 van. A kerneldpksiban nézz utána, jól le van írva, hogyan kell kitalálni az értékét, ami rendszerenként más lehet. (Vagy ne add meg, enélkül is menni ekell.)
Az xres, yres nekem szinte sosem működött.
Jelenleg:
video=vesafb-ng:mtrr:4,ywrap,1024x768@85 vga=792 áll nekem. A vga paraméter vagy kell, vagy nem, de a 0x342 nincs a doksiban, mint érvényes vga felbontás. (a linux forrásban, Documemtation, fb, vesafb.txt-t nézd meg. Ott csak 1280x1024-ig van megadva, lehet, hogy a tied is jó, de először érdemes olyat megadni, ami tutira a vesa szabvány része. Pl. 1024x768, 16M színhez 0x318 tartozik. De emlékeim szerint a 0x nem kell elé.)
Sipi -
Sipi
addikt
Nekem is integrált, de nvidia.
Azon tényleg ennyi, vesafb kernelbe, bekapcsolni, hogy legyen framebuffer konzol, grubban pedig adatok.
Két mód van. Ha rendesen megy a videokártya, elég a video=vesafb:****,1024x768@32 sort megadni a kernelnek. Egyes videokártyák azonban nem túl jók, ekkor a vga=*** paraméter IS kell nekik, megadni egy szöveges módot. Ez kísérletezés, melyikkel megy...
Másik gépen i815-ös integrált vga van, azon pl. sehogy sem megy a framebuffer. (Bootnál hosszú ideig nincs kép, Az i950esen azonban tudtommal azonnal mennie kell, az rendes videokártya. (Viszont az intelek sem mennek a saját fb-driverrel, csak a vesafb-vel.)
Sipi -
Sipi
addikt
-
Sipi
addikt
Az örök vadászmezőkre.
A 2006-os kiadások már nem támogatják a stage1-2 telepítést, csak a stage3-t. (Lásd telepítési doksik. Sok volt a gond, nullabites júzer is egyből ezzel kezdte, aztán elöntötte a fórumot, levlistákat a panaszáradat.)
Sok hátránya nincs, a stage3-telepítés elkészülte után az első emerge system lényegében stage1-re teszi a gépet.
Sipi -
Sipi
addikt
Ahogy néztem (bár alig van erre találat a neten), azt írják, hogy a 2.6.20-as kernel nem kompatibilis a libdrm jelenlegi verzióival. Emiatt a kernelben lévőt kell használni.
Ezt azonban ugye sosem beleforgatod, hanem modulba teszed?
Mellesleg az Ati-hoz emlékeim szerint sem kell drm modul. (Nem tudok okosabbat mondani, az nVidia-hoz nem kell, ezért nem használom.)
Sipi -
Sipi
addikt
A shutdown parancs működése az, hogy kapcsoló nélkül rescue üzemmódba kapcsol. Az független a telepítéstől, még a disztribúcióktól is. (Esetleg az lehet, hogy x idővel ezelőtt még nem ez votl a shutdown működése, s a másik gépen más verzió van fent. Ennek azonban olyan 1% esélyt adok, vagy annyit sem.)
A másik a dr_strange által írt verzió. rootként konzolban add ki az alias parancsot, ez kiírja, miket definiáltak. Alapesetben csak az ls és grep parancsokra van beállítva némi kozmetikai alias, semmi másra. A másik gép tulaja valószínűleg úgy állította be, hogy amikor beírja a shutdown parancsot, az valójában a ''shutdown -h'' parancsnak feleljen meg.
Egyébként rendszerparancsra nem túl egészséges alias-t tenni.
(Én még sosem láttam sehol, hogy a shutdown magában lelőtte volna a gépet. Minden program, ami ezt hívja meg, a -h vagy -r kapcsolóval teszi. Ha ebbe belepiszkálsz egy alias-szal, esetleg gondot okozhat.)
Sipi -
Sipi
addikt
JEEEEEEEEE!
No, kicsit szokni kell ezt az új logikát. Főleg most, amikor még két ellentétes dolog keveredik.
Noszóval, ki lehet teljesen kapcsolni a régi ATA/MFM/stb IDE-vezérlőt. Teljesen. S elég bekapcsolni az új SATA alatt a SATA és a megfelelő PATA kontrollereket. No meg a fájlrendszereket.
S amit kihagytam: a SCSI alatt a cdrom, merevlemez támogatás is kell... Mivel ezentúl minden eszköz SCSI lesz.
Tökéletesen megy. Ráadásul kavar sincs, mert az eddigi sda merevlemez sda maradt, a CD/DVD eszközök pedig - SCSI szokás szerint - mennek az sr0, sr1, ... néven.
Úgyhogy előre bátran!
Sipi -
#3010
Sipi
addikt
dr_strange
#3007
Sipi
addikt
válasz
dr_strange
#3007
üzenetére
Sajna, nem jött össze az okoskodásom. sda5-től sdh5-ig végigpróbáltam az összes nevet root-partíciónak, de ugyanazzal a hibával áll le. Sajna, mivel így nem tudok semmiféle alaprendszert sem elindítani, nem tudom megnézni, mik lehetnek a létrejövő eszközök. Ezért aztán nem tudom használni ezt az új, előremutató dolgot. Kár.
Sipi -
Sipi
addikt
válasz
attilam
#3008
üzenetére
Gondolom úgy érted, hogy LiveCD-ről bootolsz, csatolod a megfelelő partíciókat és másolgatsz.
Működni fog, de arra ügyelj, hogy a /proc, /sys, /dev dinamikus fájlrendszer, azokat ne másold. Illetve a /dev-ben, amikor nem fut az udev, van pár előre elkészített eszköz, ami kell a boothoz. Ha nem akarsz gondot, vagy ezeket is átmásolod, vagy beállítod a /etc/conf.d/rc-ben az RC_DEVICE_TARBALL értékét ''yes''-re. Ekkor elmenti az eszközöket egy fájlba, és ezt (is) használja következő bootnl.
Sipi -
#3006
Sipi
addikt
dr_strange
#3005
Sipi
addikt
válasz
dr_strange
#3005
üzenetére
Nofene, ha kérdezek, valahogy mindig jó találatokat kapok guglival...
Noszóval. Megjelent egy teljesen új IDE-vezérlő, ami a libata rétegre épül. Korábban ez a réteg csak a SATA-vezérlőket kezelte. Most azonban a régi PATA-t is elkezdték átírni erre, hogy kidobhassák a teljes régi ATA/MFM/stb vezérlő-réteget. (Sok hibája van, alapvetően rossz tervezés, mára csak foltozni lehet.)
Most tehát egy SATA-vezérlő van (de a korábbi SCSI részből átkerült sajátba), valamint két PATA. Egy régi (ATA/MFM), valamint az új (libata alapú), ugyancsak a SATA alatt.
Ha az újat használjuk, akkor viszont, mivel mindent libata-val kezel, eltűnnek a régi hdx nevek. Nekem tehát valószínűleg azért nem leli a kernel a root drive-ot, mert immár nem sda5 a partíció neve (eddig egy IDE CD, egy IDE DVD és egy SATA drive-om volt), hanem elé ''tolakodik'' a két optikai meghajtó. Este meg kell még néznem, de lefogadom, hogy a korábbi sda5 most sdc5 néven flangál.
Sipi
[Szerkesztve] -
#3004
Sipi
addikt
dr_strange
#3003
Sipi
addikt
válasz
dr_strange
#3003
üzenetére
Rendben, akkor kérdés.
Az újabb kernelekben megjelent egy külön menüpont, ahol valami új generációs SATA/PATA vezérlők vannak. De emellett megmaradt a régi IDE/MFM támogatás része is.
Ha csak az újat fordítom bele, nem látja a partíciókat. Csak akkor bootol a gép, ha minden régit visszateszek - de akkor mire való ez az új chipset-támogatás?
Sipi -
#2994
Sipi
addikt
TrollBalint
#2992
Sipi
addikt
válasz
TrollBalint
#2992
üzenetére
Esetleg nincs bent a kernelben az adott IDE/PATA/SATA vezérlő, vagy fájlrendszer meghajtója.
Sipi -
Sipi
addikt
válasz
hroleez
#2981
üzenetére
Széteső keret mc-ben: ha az /etc/rc.conf-ban UNICODE=yes, az /etc/env.d/99locale-ban (vagy amibe tetted) a lokálhoz LC_ALL=***.utf8 (pl. hu_HU.utf8), az /etc/conf.d/consolefont-ban Unicode-képes font (pl. ter-v16b), ugyanitt nem kell consoletrans, a keymaps-ben _sima_ névvel megadtad a konzol-kiosztást (nálam us, lehet hu is), ÉS az mc-t unicode ÉS slang flaggel forgattad, akkor nem tudom, mi lehet a gond. Ilyet nekem akkor csinált, ha a slang-et kihagytam.
Xterm: ha én simán indítom, mindenféle kapcsoló nélkül, tökéletes mind az xterm, mind a benne indított mc. Szerintem a -misc fontok nem Unicode-osak... Ha tudod, add meg a Terminus fontok valamelyikét (az xfontsel segít ebben), vagy ne adj meg semmit.
Ellenőrizd még, hogy ha X-es programot indítasz a terminálból, kiír-e olyasmit, hogy locale not supported. Alapban ugyanis az X máshogy nevezi a Uniucode-os lokálokat - /usr/share/X11/locale, itt a locale.alias fájlban keresd meg a hu_HU: hu_HU.ISO8859-2 sort (fontos a kettőspont!), s szúrd be ide azt, hogy hu_HU.utf8: hu_HU.UTF-8.
Sipi -
Sipi
addikt
válasz
hroleez
#2976
üzenetére
Hihi,
UTF-8 (vagyis Unicode) használatához (ha nem a standard karakterek kellenek) nem árt, ha a fontkészlet is Unicode, nem pedig iso2.
A Terminus nevű font pl. ilyen konzolra. (Abban van az említett ter-16b is.) A /usr/share/consolefonts könyvtárban nézheted meg a fontok neveit.
Sipi -
Sipi
addikt
válasz
hroleez
#2969
üzenetére
A futó konzolban nem elég env-update - az csak frissíti a változókat, hogy ezt az új értéket kapják. De a konzolodban még a régi érték szerepel: ehhez source /etc/profile is kell (vagy login/logoff).
Az is lehet, hogy az az env.whitelist bekavar neki. Én még sosem használtam, tudtommal az valami emergency változó.
Sipi -
Sipi
addikt
válasz
hroleez
#2965
üzenetére
A /etc/env.d a hivatalos helye. A többiből szedd ki, ne legyen keveredés.
A LANGUAGE tudtommal nem létező változó, a LINGUAS az,ami a programoknak megmondja, milyen nyelvek kellenek.
Ha @euro lokált használsz, nem árt megnézni, van-e ilyen. Szerintem alapesetben nem létezik magyarból. (Bár az euro-s lokálokhoz nem értek - én unicode-osat használok.)
Sipi -
Sipi
addikt
válasz
hroleez
#2956
üzenetére
Ahamm, itt a hiba. Az újabb xorgok végre elég intelligensek, képesek a legtöbb dolgot automatikusan felismerni - ezért ha megadod, rosszul működik.
Amit írtam, annyit kell megadni a keyboards szekciónak.
Option ''XkbRules'' ''xorg''
Nem kell megadni, eleve zt használja.
Option ''XkbModel'' ''pc105''
Ezt sem, ha megadtam régebben, mindig rossz lett.
Option ''XkbLayout'' ''hu''
Option ''XkbVariant'' '',101_qwerty_dot_nodead''
Ez pedig fura. EGY layoutot adsz meg, a magyart. A variantra azonban kettőt definiálsz: vesszővel kezdődik, ami azt jelenti, hogy az első, ami a vessző előtt áll, az semmi. Vagyis az egyszem magyar layout az default, majd megadsz a második, nem létező layoutra 101***-ot.
xkb_geometry { include ''pc(pc105)'' };
syntax error: line 1 of pc
The XKEYBOARD keymap compiler (xkbcomp) reports:
> Error: Error interpreting include file ''pc''
Ez is elég csúnyán néz ki. Talán az előző utána megjavul, de ha nem, valószínűleg megsérült a /usr/share/X11/xkb/*/pc fájl. Több helyen is van, mindig // karakterrel kezdődik, mert első sora megjegyzés.
Sipi
[Szerkesztve] -
Sipi
addikt
válasz
tierbatyo
#2959
üzenetére
Szerintem elírás a doksiban. Az xorg-x11 egy wrapper, semmit sem csinál, csak pucér rendszeren behúzza a csomagokat. Az xorg-servernek meg lehet adni a VIDEO_CARDS, INPUT_DEVICES változókkal azt, hogy mely drivereket húzza még be a szerverhez. Én nem lelek dlloader flaget sem az xorg-x11, sem az xorg-server csomaghoz - ez még a 6.8-as sorozatú xorgnál volt. De ez valami eszement régi!Mindenképpen érdemes unmaszkolni az xorg-x11 és xorg-server csomagokat, majd azokat, amelyek miatt sikít, hogy még kellenek neki. Nálam inkább ezek a ''béta'' xorgok futnak jobban.
Mod: fene, elkéstem.
Sipi
[Szerkesztve] -
Sipi
addikt
válasz
hroleez
#2945
üzenetére
Nekem ez olyan, mintha valami ősrégi rc-beállítással menne az új baselayout... Emergéld újra és írasd felül a régi konfigokat!
Én úgy szoktam, hogy tudom fejből, miket írtam át kézzel, és azt törlöm, majd -5 opcióval. Nem sok fájl van ilyen. Sokszor egyébként, ha nem változik a fájl szerkezete, akkor az új verzióban megmaradnak a beállítások, csak hozzácsap pár újat. diffel össze szoktam kézzel hasonlítani.
Ja, még valami. Ez az udev nem kompatibilis a régivel, ergo MINDEN csomagot, ami ettől függ, vagy udev fléagje van, újra kell húzni! revdep-rebuild nem ártana, mert elég sok csomag hibás lesz tőle.
Sipi -
Sipi
addikt
válasz
hroleez
#2941
üzenetére
Ööö, igen, új baselayout nem árt. Nekem 1.12.8-r1 van, de szerintem az 1.12-es sorozat már stabil, és abban benne van... Lehet, hogy nem frissítettél valami konfigot etc-update-tel?
Ez a fránya keyboard section sem javult meg. Mi kell a pontos diagnózis felállításához?
Az xorg.log-ban szerintem benne van, a billentyűzetet mivel kezeli, minek ismeri fel, sikerült-e betölteni a setxkbmap-pal a dolgokat. X-en belül kipróbálhatod, hogy a setxkbmap paranccsal beállítasz valamit. Hátha köp hibát.
Akármelyikre kapcsolom a set-tel, ugyanaz az eredmény. xdriinfo-m nincs.
emerge xdriinfo
Atinál meg tudod, hogy ha hűvösödik az idő, akkor driver kell váltani. Frissíts, downgrade-elj, valószínűleg ez a driver verzió éppen ezt az xorg-servert nem szereti. Mindenképpen unmaszkold az x11-drivers/ati-drivers csomagot, mert majd mindegyik verzió maszkolt! (Vagy csak instabil.) A Portage-ban jelenleg a 8.32.5-ös a legújabb, de ilyenkor végig kell zongorázni egyesével a verziókon, amelyikkel működik, annak örülni kell és kész.
Sipi -
Sipi
addikt
válasz
hroleez
#2939
üzenetére
Nem nem szeresse a coldplug-ot, hanem az új udev ugyanazt ellátja, ergo feleslegessé vált.
Az /etc/conf.d/rc-ben van pár RC_* változó, amellyel beállíthatod, hogyan működjön a plugging.
RC_HOTPLUG - érdemes yes-re tenni, no-n semmi értelme.
RC_COLDPLUG - service/modul coldplugging, az új udev tudását kihasználandó. Ha yes, nem csak a coldplugged modulokat tölti be, hanem az esetleg ehhez tartozó service-eket is, pl. elindul a hálózat! Emiatt érdemes beállítani...
RC_PLUG_SERVICES - ...megadja, mely szolgáltatások induljanak/ne induljanak el az udev coldplug hatására. Nekem !* az értéke, vagyis SEMMI service ne induljon. (Ekkor még ugyanis a boot szinten vagyunk, csomó dolog nemfut, amikor esetleg elindulna valami.)
Az xorg verziója jelenleg már nem sokat jelent... Kvázi szétesett a különálló libekre, protokra, egyebekre. A lényeges talán az xorg-server lehet, ebből az 1.1.1-es és 1.1.99.* verzió is jól megy nálam. Ilyen keyboard-gondok nekem az xgl-lel, esetleg compizzal szoktak lenni. Vagy pedig nem leli a modulok elérési útját, néha változtatnak rajta. Nekem jelenleg egyáltalán nincs ModulePath és hasonlók, CSAK FontPath szerepel az xorg.conf Files szekciójában!
Section ''InputDevice''
Identifier ''Keyboard0''
Driver ''kbd''
Option ''XkbLayout'' ''us,hu''
Option ''XkbVariant'' '',101_qwerty_dot_nodead''
Option ''XkbOptions'' ''grp:switch,grp:menu_toggle,grp:led:scroll''
EndSection
Ezzel minden billentyűm működik.
glxgears: próbáld kézzel ide-oda váltogatni az eselect opengl-lel az openglt. Ilyen akkor van, ha nincs DRI (xdriinfo kiírja), vagy rossz OpenGL-t használ.
Sipi -
Sipi
addikt
válasz
tierbatyo
#2931
üzenetére
Nekem olybá tűnik, rossz fájlok, linkek maradhattak fent, s ezért van az rm: directory. (Pl. egy gcc link nem a régi gcc binárisra mutat, hanem egy gcc nevű könyvtárra.)
Egy manuális tesztet végezhetsz: állítsd be az új gcc profilt, valamelyik (lehetőleg legújabb) binutils profilt, és egy forrást tömöríts ki, majd kézzel configure. Talán többet ír ki, a config.logban talán több infó lesz. (Abban benne kell lennie a példaporogamoknak is, melyekkel teszteli, mi az uint, stb.)
Ha a glibc a régi gccvel készült, meg a kernel is, akkor szedd le az újat. A gcc-configgal az egyszem régi gcc profilt állítsd be, annak jónak kell lennie (mivel azt írtad ).
Miután van egy tiszta rendszered, egyszem működő gcc-vel, gcc-configgal, mehet a 4.1-es sorozat valamelyik tagja. Ne lepődj meg, ha nem fordul, van belőle hibásabb is. De a 4.1.1-es nekem jól megy.
Sipi -
Sipi
addikt
válasz
tierbatyo
#2929
üzenetére
Nem glibc hiba, tutira gcc. És le merem fogadni, hogy egyszerűen keverednek a profilok.
Felteszem, a multislot flag be van kapcsolva, különben nem lehetne két verziójú gcc.
Az eselect binutils list paranccsal nézd meg, hány van fent (ez is slotolható), majd állítsd be valamelyikre! (Az összes ilyen profil-állításra érvényes, hogy ha hiba van, érdemes átállítani valamelyik másra, majd megint vissza. Ilyenkor tuti, hogy az esetleges rossz linkek törlődnek és helyesen jönnek létre.)
Ezután jönne a gcc-config. Írtad, hogy leszedted az _összes_ verziójú eselect-compilert. Ezen kívül szedd le a 2.*-os gcc-configot is! Most nézd meg az envd/gcc-ben, milyen profilok maradtak. Mozgasd el az összes fájlt valami biztos helyre, majd tedd fel a gcc-config 1.3-as sorozatát! Ezek után megnézni, milyen konfigok kerültek fel az envbe. gcc-config -l. Jó lenne, ha felismerné automatikusan mindkét gcc-det.
Ha nem, és a fájlok sem léteznek, akkor másold vissza azokat, amelyerk a tényleges gcc-verzióknak felelnek meg! Nyisd meg mindet, és ellenőrizd, hogy a benne lévő könyvtárak léteznek-e, és arra a verzióra mutatnak-e, amire kell! Ja, és a /etc/env.d/05gcc-t is nézd meg, mi van benne.
Ha ez megvolt, lehet megint a gcc-configgal játszani, ide-oda kapcsolgatni a verziók között. Váltás 4-esre, env-update, source profile, majd gcc -v elvileg már jót kell, hog ykiírjon.
Ja, a ccache írját is töröld le, nehogy bekavarjon! Kapcsold is ki a make.conf-ban. A /usr/lib/ccache-ben vannak linkek, ezek zűrösek, ha a gcc hibádzik. (Ugyanis ezek átveszik a gcc binárisai felett a hatalmat.)
/etc/env.d/gcc/config:
CURRENT=x86_64-pc-linux-gnu-4.1.1
/etc/env.d/gcc/x86_64-pc-linux-gnu-4.1.1:
PATH=''/usr/x86_64-pc-linux-gnu/gcc-bin/4.1.1''
ROOTPATH=''/usr/x86_64-pc-linux-gnu/gcc-bin/4.1.1''
LDPATH=''/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1:/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/32''
GCCBITS=''32 64''
MANPATH=''/usr/share/gcc-data/x86_64-pc-linux-gnu/4.1.1/man''
INFOPATH=''/usr/share/gcc-data/x86_64-pc-linux-gnu/4.1.1/info''
STDCXX_INCDIR=''g++-v4''
/etc/env.d/05gcc:
PATH=''/usr/x86_64-pc-linux-gnu/gcc-bin/4.1.1''
ROOTPATH=''/usr/x86_64-pc-linux-gnu/gcc-bin/4.1.1''
MANPATH=''/usr/share/gcc-data/x86_64-pc-linux-gnu/4.1.1/man''
INFOPATH=''/usr/share/gcc-data/x86_64-pc-linux-gnu/4.1.1/info''
LDPATH=''/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1:/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/32''
GCC_SPECS=''''
A binutils táján is szétnéznék, hogy jó profilt használ-e.
Sipi -
Nézd meg az xorg logot, mit mond, mit hiányol.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
- Kerékpárosok, bringások ide!
- Itt a Galaxy S26 széria: az Ultra fejlődött, a másik kettő alig
- Gyárátalakításokkal kaszálna nagyott a memóriapánikból a Samsung
- PlayStation 5
- TCL LCD és LED TV-k
- LG LCD és LED TV-k
- sziku69: Fűzzük össze a szavakat :)
- Linux kezdőknek
- Geri Bátyó: Agglegénykonyha 14 – Kések, késélezés
- Télbúcsúztató hardvermix
- További aktív témák...
- Kaspersky, BitDefender, Avast és egyéb vírusírtó licencek a legolcsóbban, egyenesen a gyártóktól!
- Windows 10 11 Pro Office 19 21 Pro Plus Retail kulcs 1 PC Mac AKCIÓ! Automatikus 0-24
- Adobe Előfizetések - Adobe Creative Cloud All Apps - 12 Hónap - 15% AKCIÓ
- Windows, Office licencek kedvező áron, egyenesen a Microsoft-tól - Automata kézbesítés utalással is!
- Fallout 4 Pip-Boy Edition eladó
- Beszámítás! HP Elitebook 8 G1i 14 FHD notebook - Ultra 5 235U 16GB DDR5 256GB SSD Intel IGP W11
- ÁRGARANCIA!Épített KomPhone Ryzen 7 5700X 32/64GB RAM RTX 5060 Ti 8GB GAMER PC termékbeszámítással
- Dell Latitude 5300 13,3" FHD IPS touch, i5 - i7 8665U, 8-16GB RAM, SSD, jó akku, számla, 6 hó gar
- Kaspersky, BitDefender, Avast és egyéb vírusírtó licencek a legolcsóbban, egyenesen a gyártóktól!
- 15,6" Dell Latitude laptopok: E5550, E5570, 5590, 5500, 5501, 5510, 5520 / SZÁMLA + GARANCIA
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest