- This topic has 49 hozzászólás, 6 résztvevő, and was last updated 19 years, 9 months telt el by
.
-
Bejegyzés
-
supermount-2.0.4-2.6.3.patch.gz
2.6.12-05„a teljesen újratelepített, frissített kernel forrásának könyvtárában /usr/src/linux/ alatt az /include könyvtárban érintetlenül megvan minden, hiszen ez újonnan települt, még érintetlen, mert egyáltalán nem indul a make menuconfig.”
Nem, azzal, hogy eltávolítottad a kernel headereket pont ezeket távolítottad el, amiket hiányol.alatt az /usr/include/linux könyvtárban keresi a fcntl.h nevû filet
vagy a /usr/src/linux/include/asm könyvtárban (ez talán valószínûbb, hiszen ez a sajátja)
csinálj egy linket és menni fog – valami miatt nem tudja, hogy intel 386 kompatibilis – nekem még nem fordult elõ, de már sokaknak igen (bizonyára a headerek eltávolítása miatt)
(most, ha zsaru lennék azt mondanám: „Higgy nekem, hisz zsaru vagyok!” :)))Esetleg még próbálkozz CD-rõl újra pakolni amit leszedtél
dpkg -i /ahol_/a csomag_van/csomagnév.uhu
Nekem még anno uhu1.0 alatt volt, hogy manuálba nem szándékosan letöröltem a bzImage-t.supermount-2.0.4-2.6.3.patch.gz
2.6.12-05„a teljesen újratelepített, frissített kernel forrásának könyvtárában /usr/src/linux/ alatt az /include könyvtárban érintetlenül megvan minden, hiszen ez újonnan települt, még érintetlen, mert egyáltalán nem indul a make menuconfig.”
Nem, azzal, hogy eltávolítottad a kernel headereket pont ezeket távolítottad el, amiket hiányol.alatt az /usr/include/linux könyvtárban keresi a fcntl.h nevû filet
vagy a /usr/src/linux/include/asm könyvtárban (ez talán valószínûbb, hiszen ez a sajátja)
csinálj egy linket és menni fog – valami miatt nem tudja, hogy intel 386 kompatibilis – nekem még nem fordult elõ, de már sokaknak igen (bizonyára a headerek eltávolítása miatt)
(most, ha zsaru lennék azt mondanám: „Higgy nekem, hisz zsaru vagyok!” :)))
[align=right][snapback]148133[/snapback][/align]Helló Vizsla!
Hiszen írtam, hogy ma ismét letöltöttem az UHU ftp szerverérõl a 2.6.9-21-es kernelt, annak headers és source csomagjait is, és újratelepítettem mindhármat. Tehát az elõzõleg kiürített /usr/src könyvtárba a Synaptic ismét betette az éppen csak letöltött szûz kernel csomagokat (mindhármat.). Hogy biztos legyek a dolgomban, még a lemezeket is kiszedtem, nehogy véletlenül a nem frissített kernelcsomagok települjenek, hanem a /var/cache/apt/archives könyvtárból történt a telepítés. Ez tehát egy teljesen új csomagtelepítés. A /usr/src/linux/include könyvtárban pedig az asm link az asm-i386-ra mutat. A hibaüzenetek sorait is átnéztem, de az általad példaként felhozott fcntl.h is megtalálható mind az include/linux, mind a /include/asm-i386 könyvtárban. De ugyanígy megvannak a hibaüzenetben hivatkozott
scripts/basic/fixdep.c:105:23: sys/types.h: Nem létezõ fájl vagy könyvtár
scripts/basic/fixdep.c:106:22: sys/stat.h: Nem létezõ fájl vagy könyvtár
scripts/basic/fixdep.c:107:22: sys/mman.h: Nem létezõ fájl vagy könyvtár, stb. sorok is a helyükön.
Azt nem tudom, hogy a fixdep.c-ben alkalmazott szintaktika helyes-e.
Részlet:
#include
#include
#include , stb. Azt viszont nem tudom, hogy amiket be kell include-olni, azok hol találhatók.
Nem ellenõriztem végig a hibaüzenet összes sorát, de szerintem minden a helyén van. Hogy mégsem ismeri fel a fixdep script a dolgokat, annak talán az lehet az oka, hogy az adott programnyelv interpreter-je hibás, de én azt sem ttudom, hogy melyik az.Tehát szerintem nem a kernelforrás és a header csomag a hibás, mert az fent van, méghozzá frissiben.
Esetleg még próbálkozz CD-rõl újra pakolni amit leszedtél
dpkg -i /ahol_/a csomag_van/csomagnév.uhu
Nekem még anno uhu1.0 alatt volt, hogy manuálba nem szándékosan letöröltem a bzImage-t.” Azóta már teljesen eltávolítottam a 2.6.12-5-ös kernel könyvtárát,”
Nézz rá az /usr/include könytárban a linkek hova mutatnak!
Ha a fent emlitett könyvtárba akkor nem is csoda hogy nem talélja!
Az /usr/include könytárat jobb nem piszkálni. 🙂
Amit vizsla is említett velem is elõfordult gentoo alatt,
csak az aktuális kernel forrásába linkeléssel sikerült megoldani, hogy a fordítás menjen.” Azóta már teljesen eltávolítottam a 2.6.12-5-ös kernel könyvtárát,”
Nézz rá az /usr/include könytárban a linkek hova mutatnak!
Ha a fent emlitett könyvtárba akkor nem is csoda hogy nem talélja!
Az /usr/include könytárat jobb nem piszkálni. 🙂
Amit vizsla is említett velem is elõfordult gentoo alatt,
csak az aktuális kernel forrásába linkeléssel sikerült megoldani, hogy a fordítás menjen.
[align=right][snapback]148188[/snapback][/align]Mindig csak a kernel verzióhoz írt patch-et használd mert nem fog mûködni! Ez nagyon fontos!!!!
Egyébként az a baj, hogy fordítva közelíted meg a dolgot.
A normális az lenne, hogy „mit akarok, milyen hw-em van” -> „benne van a kernelemben” -> „ha nincs betenni”.
Elképzelhetõ, hogy nem is kell patch…A kernel pachelésrõl itt olvashatsz, ráadásul magyarul (sõt patch elérések is vannak, és a website-ok linkjei is, amin le van írva, hogy mire való)
http://www.hup.hu/wiki/index.php/Linux_kernel_patchelésMindig csak a kernel verzióhoz írt patch-et használd mert nem fog mûködni! Ez nagyon fontos!!!!
Egyébként az a baj, hogy fordítva közelíted meg a dolgot.
A normális az lenne, hogy „mit akarok, milyen hw-em van” -> „benne van a kernelemben” -> „ha nincs betenni”.
Elképzelhetõ, hogy nem is kell patch…A kernel pachelésrõl itt olvashatsz, ráadásul magyarul (sõt patch elérések is vannak, és a website-ok linkjei is, amin le van írva, hogy mire való)
http://www.hup.hu/wiki/index.php/Linux_kernel_patchelés
[align=right][snapback]148306[/snapback][/align]Helló Vizsla!
Igazad van, kicsit rosszul közelítettem meg a problémámat. Megpróbálom összefoglalni:
– Tehát adott egy újonnan feltelepített UHU 1.2 rendszer, amelynek 2.6.9-19-es kernele, a kernel-headers és a kernel-source fájlok az UHU ftp szerverérõl lettek frissítve 2.6.9-21-re.– A frissen telepített rendszer nem ad vissza keycode-ot a 16 db multimédiás billentyûbõl 6 db. lenyomására.
Ugyanez nem jelentkezett gondként a korábbi UHU 1.1-ben.– Hosszas vizsgálódás eredményeként kiderült, hogy a billentyûkhöz keycode-ot rendelõ setkeycodes parancsra és annak párjára, a getkeycodes parancsra a rendszer az alábbi hibaüzenetekkel reagál:
a getkeycodes-re:
„KDGETKEYCODE: Nem létezõ eszköz
failed to get keycode for scancode 0x59
0x58: 88″a setkeycodes xx yyy-ra:
„KDSETKEYCODE: Nem létezõ eszköz
failed to set scancode xx for keycode yy– Sikerült kideríteni, hogy egy újonnan fordított 2.6.12-5-ös „vanilla” kernellel bootolva a fenti hiba nem jelentkezik, mûködik a getkeycodes és a setkeycodes parancs, a 6 db, keycode-al nem rendelkezõ billentyûkhöz a setkeycodes paranccsal hozzá lehet rendelni keycode-ot, ezt követõen minden multimédiás billentyû látható.
– Fentiek alapján az a következtetés alakult ki, hogy a 2.6.9-19(21)-es kernelben van a hiba. Ezzel párhuzamosan az is kiderült, hogy a fenti problémát nem okozó 2.6.12-5-ös kernelbe viszont nincs beforgatva a supermount, ami viszont a 2.6.9-19(21)-es kernellel jól mûködik.
– Itt választás elé kerültem:
a.) vagy megpatch-elem a 2.6.12-5-ös kernelt a supermount patch-el, és utána fordítok egy 2.6.12-5-ös kernelt supermount támogatással; vagy
b.) megpróbálom megpatch-elni a régi, 2.6.9-19(21)-es kernelt egy olyan patch-el, amelyik a getkeycodes és setkeycodes parancsokra nem ad hibaüzenetet.Nos, számomra könnyebbnek tûnt az a.) változat választása, hiszen a 2.6.12-5-ös kernelt már sikerült lefordítani. Nem jött be, a patch-elés sikerült (a https://svn.uhulinux.hu/packages/1.2/kernel/patches/30-fs könyvtárból letöltött supermount patch-el), azonban patch-elés után a kernelfordítás egy idõ után hibaüzenettel megszakad. Ahogy korábban írtam, én nem vagyok linux-guru, nem tudok mit kezdeni a hibaüzenetekkel, csak a végeredmény érthetõ: Error!
A b.) változat szimpatikusabb, hiszen itt csak olyan foltot kellene találni, ami a szóban forgó hibaüzenetet okozza, azt a kernelrészt meg kellene patch-elni, majd újraforgatni a 2.6.9-19(21)-es kernelt, amelyhez végül is az egész UHU 1.2 igazítva lett.
Nos, ez sem sikerült, a fentebb megjelölt címen egyik patch gyûjtõkönyvtárban sem találtam olyan patch-et, amely a billentyûzettel lenne kapcsolatos (legalábbis az én tudásom szerint).
Erre c.) megoldásként megpróbáltam a 2.6.9-19(21)-os kernelt a kernel.org-ról letöltött (http://www.kernel.org/pub/linux/kernel/v2.6/patch-2.6.12.gz) full patch-al megfoltozni, hogy 2.6.12-es legyen belõle. Ez sem jött be, a foltozás során rengeteg hibaüzenet keletkezik, és már a make menuconfig sem indul el.” Fentiek alapján az a következtetés alakult ki, hogy a 2.6.9-19(21)-es kernelben van a hiba. Ezzel párhuzamosan az is kiderült, hogy a fenti problémát nem okozó 2.6.12-5-ös kernelbe viszont nincs beforgatva a supermount, ami viszont a 2.6.9-19(21)-es kernellel jól mûködik.”
Ha csak a supermount hiányzik, akkor keress a „submount” szóra!
Nekem gentoo alatt ezzel csatolja: floppy, cdrom, usb stick (kütyük) 🙂
patch nélkül is megy! 🙂De ha az /etc/fstab bejegyzed, sztem gnome vagy kde alatt egy katt és csatolja ill leválasztja! 🙂
„Nos, számomra könnyebbnek tûnt az a.) változat választása, hiszen a 2.6.12-5-ös kernelt már sikerült lefordítani. Nem jött be, a patch-elés sikerült (a https://svn.uhulinux.hu/packages/1.2/kernel/patches/30-fs könyvtárból letöltött supermount patch-el), azonban patch-elés után a kernelfordítás egy idõ után hibaüzenettel megszakad. Ahogy korábban írtam, én nem vagyok linux-guru, nem tudok mit kezdeni a hibaüzenetekkel, csak a végeredmény érthetõ: Error!”
Mondtam, hogy ne onnan töltsd le, mert az nem ahhoz a kernelhez való…A supermounttal meg csak szívás van… és részint automatikus parancsokkal helyettesíthetõ, a cserélhetõ médiáknál meg egy gombnyomással (billenytû, egér, desktopikon, irtávirányító bármi) helyettesíthetõ a csatolás (sõt egyúttal ezzel párhuzamosan megoldható a lemez ki-beadása – természetesen, ha az eszköz képes rá – ami meg még több is a supermountnál) – ha egy billenytûnyomás meg „nehézkes”, akkor pl. az osx egy bonyolultan használható, felhasználó ellenség, amit még senki nem mondott eddig – pedig ott is pont így történik.
- Be kell jelentkezni a hozzászóláshoz.
legutóbbi hsz