Ehüm. Kösz a tippet, sose jöttem volna rá ....
A devfs-hez kell kernelpatch vagy csak a supermounthoz? Most dolgozom, de ha hazaérek megnézem a kernel konfigban. (mert ha van benne devfs opció, akkor csak tegnap este voltam fáradt).
OK. Még 1-2 óra és meglátjuk...
A supermounthoz nem ragaszkodom, elvégre a rendszerhdd és a 2 optikai meghajtó fix, csak a mobilrackhez és pendrive-hoz/memóriakártyaolvasóhoz lenne értelme (scripttel megoldható)
btw. találkoztam azzal az érdekes jelenséggel, hogy a pendrive nem mindig sda-ként jelentkezik fel. Konkrétan: elindul a gép, pendrive bedug, sda lesz belőle. kihúz, másik gyártmányú pendrive bedug ---> sdb. Látott már ilyet valaki? ez ugye akkor ciki, ha az fstabban az sda van megjelölve mint a /mnt/pendrive könyvtár eszköze, mert ide az sdb-t csak rootként lehet mountolni.
hát megláttam! Az experimental részben volt a devfs, amit kikapcsoltam (a stabilitás miatt).
A 2.4.26-tal sikerült eljutnom az X-ig; USB működik.
A flash olvasómmal rendben írtam a fényképezőgépem CF kártyáját. Megint dev lista...
vmiklos:
igen, ez otthon járható út, de pl az egyetemen naponta 6-8 fajta pendrive megfordul és ez a szám növekszik, ahogy egyre olcsóbbak+nagyobbak lesznek. Arra vagyok kíváncsi, vajon supermount / amd nélkül megoldható-e ez? tud-e valaki arról hogy esetleg rá lehet-e venni a scsi alrendszert, hogy a feldugott eszköznek a legkisebb elérhető ID-t adja?
igen, ezt én udevvel oldottam meg, de ahhoz 2.6.xes kernel kell :wink:
ott nincs semmilyen plusz filerendszer, a /dev is sima könyvtár, és amint kiveszed a pendrivet, az sda eltűnik, amikor bedugod a másikat, akkor pedig (ha nincs sda) akkor eszébe nem fog jutni sdbt létrehozni ;-)
szóval ez az udev a 2.6-ban olyan mint a devfs?
....
http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev-FAQ
Hát az UHU fejlesztőknek lesz dolga ...
a devfs az egy ***
az udevnek az a nagy poénja, hogy mindezt userspaceban csinálja
ráadásul a rules configjaival tud devfsként meg "normál /dev"-ként is viselkedni. imho nagyon ott van :wink:
[quote:a7fb61f760="vmiklos"][quote:a7fb61f760="pete"]Hát az UHU fejlesztőknek lesz dolga ...
amikor majd néhány év múlva szembetalálják magukat ezzel a problémával :wink:
Csak úgy jelezném, hogy a fejlesztői ágban 2.6-os kernel van, igaz, egyelőre devfs, és még nem teljesen biztos, hogy a következő UHU-ra átállunk udev-re, de meg fogjuk vizsgálni. Igenis nagyon rég óta, bőven az 1.1 kiadása előtt tudtuk már, hogy a devfs nem lesz örök életű, le fogjuk egyszer váltjuk udev-re.
OK, olvastam a dev-en, és ez nem is annyira fontos jelenleg (a recode jól megy). Ha már a kérdésnél tartunk, éppen az előbb akartam írni a dev listára egy összefoglaló levelet erről...
Lesz javítás, vagy várjak a következőig (1.2) és írjak Gnoppix CD-t? :)
[quote:a0cf66dffd="pete"]Lesz javítás, vagy várjak a következőig (1.2) és írjak Gnoppix CD-t? :)
Minden bizonnyal nem lesz javítás. A kernelt meglehetősen sok usb eszközzel teszteltük, nyilván ettől még lehet olyan, amelyikkel nem megy jól. Ahhoz, hogy elkezdjük a hibát levadászni, mindenképp szükségünk lenne a konkrét hibásan kezelt kütyüre és gépre, és ez csak a legelső lépés volna. Ha esetleg mutatsz egy minimális méretű áttekinthető patchet, amelyről teljesen nyilvánvaló, hogy javítja a hibát, és senkinek semmi mást nem ront el, akkor azt berakjuk. Nem engedhetjük meg, hogy utólag egy javítás reményében bárkinek is kockáztassuk, hogy a kernel frissítése után neki ne működjön az, ami eddig működött. Gyökeres átalakításról, komoly verziófrissítésről utólag szó sem lehet a kiadott rendszerben. Az UHU 1.1 az egy egyszer kiadott, fix, változatlan rendszer, melybe csak súlyos hibák (leginkább biztonsági rések) foltozását tesszük bele a későbbiekben, amennyiben azokról látható, hogy semmit nem rontanak el. Verziófrissítés, nagyobb átdolgozás stb. szóba sem jöhet. A rendszer nem kritikus hibáit nem az UHU 1.1-ben javítjuk, hanem a készülő következő verzióban igyekszünk.
Dolgozunk az UHU 1.2-n, hamarosan várhatók béta kiadások, megköszönjük, ha teszteled azokat és megírod majd, ha valami gond adódik velük. Itt a béta fázisban, a végleges 1.2 kiadása előtt van lehetőség arra, hogy megfogjuk a hibát. A végleges 1.2 kiadása után ugyanígy minden bizonnyal itt sem lesz lehetőség rá. Nincs arra kapacitásunk (de a legtöbb nagy disztribnek sincs, tehát itt nem arról van szó, hogy hány főből áll a csapat), és értelmét sem látjuk, hogy visszamenőlegesen foglalkozzunk a disztribbel. Előrefelé akarunk haladni, nem hátra. A 2.4-es kernelt a magunk részéről lezártuk, leszámítva természetesen az olyan sec.hibák javítását, mint a minap a clear_cpu() bibi.
Sajnos nem vagyok olyan szinten hogy patch-et tudjak küldeni, csak a tapasztalataimat tudom összefoglalni :(
A 2.4.24-es kernel tartalmaz egy bug-ot, ami miatt az USB 2.0-s eszközök csatlakoztatásuk után lefagyaszthatják a rendszert. Az 1.1-es eszközök gond nélkül mennek.
A teszt - hardver: USB 1.1 és 2.0 pendrive, USB 2.0 6in1 olvasó
Gépek:
1, GA-7N400-L, AMD Barton 2500+, 256 DDR (UHU)
2, I440BX, Celeron 400, 128 SD (Debian)
3, i810, Celeron 433, 320 SD (UHU)
Az 1-esen és a 3-ason UHU 1.1.1 van, próbáltam a CD-ről jött és a 2 frissített kernellel is. A 2-es gépen 2.4.24-es kernel van, saját fordítás, USB Mass Storage debug opcióval. A naplófájlok tanúsága szerint az olvasó nem fogadja el a neki kiosztott device id-t, a pendrive esetén pedig timeoutok voltak. Az eszközök egy régebbi Gnoppix alatt működnek, és lett tesztelve 1.1 és 2.0 host controllerekkel több különböző alaplapon is, így szerintem egyértelműen a 2.4.24-es kernel a ludas. A debbyn nem használok kernel foltokat, így ez sem lehet hibaforrás.
A gyanúmat megerősíti, hogy kipróbáltam az olvasót és a pendrive-ot egy "production" szerveren 2.4.22-es foltozatlan kernellel (utólag belátom ez nem volt jó ötlet). A hiba nem jelentkezett, de a pendrive-ból csak az első 256 mega látszott, win98SE és 2k alatt is (a 2k megint egy másik gép, egy HP Vectra VE). A méretprobléma HW-es hiba, garanciás lévén visszavittem.
A kapott infóval egy új kernel fordításához láttam hozzá. Letöltöttem a 2.4.26-os kernel a kernel.org-ról és engedélyezett devfs-sel elindult az új rendszer. Supermount nem volt, így kézzel mountoltam az olvasót, ami korrektül működött, többszöri le-fel csatlakoztatás után sem volt vele probléma. Az új kernel szintén mass storage (és egyéb) debug opciókkal fordult, a naplófájlban sem volt hibaüzenet. A Changelogban írtak "USB fixes"-ről, gondolom az segített.
Megértem a support politikátokat és szívesen tesztelem az új UHU-t ha lesz béta belőle. Van valami fájdalommentes módja annak hogy kipróbáljam anélkül hogy feladjam a jelenlegi rendszeremet?
UI: Tetszik az UHU-klub, ha lesz benne bugtrack-support, én benevezek rá.
:twisted:
UI2: Van közelebbi hír a csomagoló tanfolyamról (hol, mikor lesz)?
[quote:07226d040c="egmont"]Csak úgy jelezném, hogy a fejlesztői ágban 2.6-os kernel van, igaz, egyelőre devfs, és még nem teljesen biztos, hogy a következő UHU-ra átállunk udev-re, de meg fogjuk vizsgálni
bocs, akkor le vagyok maradva :D
igazában majd akkor lesz probléma, ha majd eltűnik a kernelből. az pedig imho néhány év múlva lesz ;-)
[quote:07226d040c="egmont"]
Igenis nagyon rég óta, bőven az 1.1 kiadása előtt tudtuk már, hogy a devfs nem lesz örök életű, le fogjuk egyszer váltjuk udev-re.
a devfs is érdekesen csinálja, EXPERIMENTALból egyből OBSOLETE, az azért szép :D
igen, a belinkelt oldalon írták, hogy azért mert lelépett a fejlesztője, meg voltak el nem ismert / ki nem javított hibák. szerintem nem vészes a hiány mert tud devfs-kompatibilis elrendezést.
Vettem egy 1G-s pendrive-t (USB 2.0) és lehalt tőle a bagoly. A 2.0-s 6in1 olvasómtól szintúgy. Tippem szerint kernel bug, winfos 98 alatt megy mindkettő. A 26-ban találtam olyat, hogy USB fix, szóval megpróbálom. Ezt még megúszhatom gányolás nélkül is akár...
Az lenne a kérdésem, hogy van-e valaki aki csinált már ilyet az UHUval? A fejlesztők kernel config fájljából szeretnék kiindulni, és kísérletezgetni. Elég ha a headers csomag felpakolása után elérhető configot átmásolom az új source tree megfelelő helyére?
nem, ezt néztem. Van a release-nél frissebb, de az is csak 24, és detto nem megy a cucc. Az előbb t@koltem vele, mert a belecsomagolt (új) kernelnek ugyanúgy "2.4.24-7"-es szignója van, mint a release-nek, és én azt hittem, nem frissült. Pedig igen...
A fordítás meg amúgy már régóta érik, mert qrva sok cucc van bele + modulban, ami nekem nem kell (firewire, sata, raid, true scsi, usb hányások driverei, stb. )
pete:
"A fejlesztők kernel config fájljából szeretnék kiindulni, és kísérletezgetni. Elég ha a headers csomag felpakolása után elérhető configot átmásolom az új source tree megfelelő helyére?A fejlesztők kernel config fájljából szeretnék kiindulni, és kísérletezgetni. Elég ha a headers csomag felpakolása után elérhető configot átmásolom az új source tree megfelelő helyére?"
imho nem tul nyero otlet, se a disztro kernel forrasa, se a .configja;
vanillabol csinalj egy sajatot;
http://fellow.linuxforum.hu/kernel_felkonfig
mivel usb hardwarem nincs nagyon jol jonne, ha irna vki par szot;
gondolom itt mass storage support kell; meg az lspci mindig jo kiindulas;
* A 2.4.22 nem fagy, de csak 262 Mb-ot lát a diskből
* A .24 debby alatt ugyanúgy 262 MB-ot látott, de belefagyott.
* A .26 nem birkózik meg vele. Ezt csak a logokból tudom, mert valahogy az új kernelem nem tudott konzolt nyitni.
Ötlet? A virtual "console support" meg a "console on VT" fixre be volt fordítva. :roll:
Hozzászólások
Ehüm. Kösz a tippet, sose jöttem volna rá ....
A devfs-hez kell kernelpatch vagy csak a supermounthoz? Most dolgozom, de ha hazaérek megnézem a kernel konfigban. (mert ha van benne devfs opció, akkor csak tegnap este voltam fáradt).
Csak a supermounthoz kell patch! http://www.suprmount-ng.sourceforge.net/
Próbáltad saját magad mountolni az UHU automountere nélkül?
OK. Még 1-2 óra és meglátjuk...
A supermounthoz nem ragaszkodom, elvégre a rendszerhdd és a 2 optikai meghajtó fix, csak a mobilrackhez és pendrive-hoz/memóriakártyaolvasóhoz lenne értelme (scripttel megoldható)
btw. találkoztam azzal az érdekes jelenséggel, hogy a pendrive nem mindig sda-ként jelentkezik fel. Konkrétan: elindul a gép, pendrive bedug, sda lesz belőle. kihúz, másik gyártmányú pendrive bedug ---> sdb. Látott már ilyet valaki? ez ugye akkor ciki, ha az fstabban az sda van megjelölve mint a /mnt/pendrive könyvtár eszköze, mert ide az sdb-t csak rootként lehet mountolni.
csinálj az fstabba még1 ugyanolyan sort, de az már az sdbt mountolja!
azután mount /dev/sdb, és kész :wink:
hát megláttam! Az experimental részben volt a devfs, amit kikapcsoltam (a stabilitás miatt).
A 2.4.26-tal sikerült eljutnom az X-ig; USB működik.
A flash olvasómmal rendben írtam a fényképezőgépem CF kártyáját. Megint dev lista...
vmiklos:
igen, ez otthon járható út, de pl az egyetemen naponta 6-8 fajta pendrive megfordul és ez a szám növekszik, ahogy egyre olcsóbbak+nagyobbak lesznek. Arra vagyok kíváncsi, vajon supermount / amd nélkül megoldható-e ez? tud-e valaki arról hogy esetleg rá lehet-e venni a scsi alrendszert, hogy a feldugott eszköznek a legkisebb elérhető ID-t adja?
igen, ezt én udevvel oldottam meg, de ahhoz 2.6.xes kernel kell :wink:
ott nincs semmilyen plusz filerendszer, a /dev is sima könyvtár, és amint kiveszed a pendrivet, az sda eltűnik, amikor bedugod a másikat, akkor pedig (ha nincs sda) akkor eszébe nem fog jutni sdbt létrehozni ;-)
szóval ez az udev a 2.6-ban olyan mint a devfs?
....
http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev-FAQ
Hát az UHU fejlesztőknek lesz dolga ...
a devfs az egy ***
az udevnek az a nagy poénja, hogy mindezt userspaceban csinálja
ráadásul a rules configjaival tud devfsként meg "normál /dev"-ként is viselkedni. imho nagyon ott van :wink:
[quote:5c06ba9147="pete"]Hát az UHU fejlesztőknek lesz dolga ...
amikor majd néhány év múlva szembetalálják magukat ezzel a problémával :wink:
nem hiszem hogy annyit kell várni, már hegesztik az UTF-8 konzolt és a 2.6-ot 8)
[quote:a7fb61f760="vmiklos"][quote:a7fb61f760="pete"]Hát az UHU fejlesztőknek lesz dolga ...
amikor majd néhány év múlva szembetalálják magukat ezzel a problémával :wink:
Csak úgy jelezném, hogy a fejlesztői ágban 2.6-os kernel van, igaz, egyelőre devfs, és még nem teljesen biztos, hogy a következő UHU-ra átállunk udev-re, de meg fogjuk vizsgálni. Igenis nagyon rég óta, bőven az 1.1 kiadása előtt tudtuk már, hogy a devfs nem lesz örök életű, le fogjuk egyszer váltjuk udev-re.
[quote:900431791c="pete"]nem hiszem hogy annyit kell várni, már hegesztik az UTF-8 konzolt és a 2.6-ot 8)
A következő UHU-ban UTF-8 konzol sajnos még nem lesz, marad a Latin-2.
OK, olvastam a dev-en, és ez nem is annyira fontos jelenleg (a recode jól megy). Ha már a kérdésnél tartunk, éppen az előbb akartam írni a dev listára egy összefoglaló levelet erről...
Lesz javítás, vagy várjak a következőig (1.2) és írjak Gnoppix CD-t? :)
[quote:a0cf66dffd="pete"]Lesz javítás, vagy várjak a következőig (1.2) és írjak Gnoppix CD-t? :)
Minden bizonnyal nem lesz javítás. A kernelt meglehetősen sok usb eszközzel teszteltük, nyilván ettől még lehet olyan, amelyikkel nem megy jól. Ahhoz, hogy elkezdjük a hibát levadászni, mindenképp szükségünk lenne a konkrét hibásan kezelt kütyüre és gépre, és ez csak a legelső lépés volna. Ha esetleg mutatsz egy minimális méretű áttekinthető patchet, amelyről teljesen nyilvánvaló, hogy javítja a hibát, és senkinek semmi mást nem ront el, akkor azt berakjuk. Nem engedhetjük meg, hogy utólag egy javítás reményében bárkinek is kockáztassuk, hogy a kernel frissítése után neki ne működjön az, ami eddig működött. Gyökeres átalakításról, komoly verziófrissítésről utólag szó sem lehet a kiadott rendszerben. Az UHU 1.1 az egy egyszer kiadott, fix, változatlan rendszer, melybe csak súlyos hibák (leginkább biztonsági rések) foltozását tesszük bele a későbbiekben, amennyiben azokról látható, hogy semmit nem rontanak el. Verziófrissítés, nagyobb átdolgozás stb. szóba sem jöhet. A rendszer nem kritikus hibáit nem az UHU 1.1-ben javítjuk, hanem a készülő következő verzióban igyekszünk.
Dolgozunk az UHU 1.2-n, hamarosan várhatók béta kiadások, megköszönjük, ha teszteled azokat és megírod majd, ha valami gond adódik velük. Itt a béta fázisban, a végleges 1.2 kiadása előtt van lehetőség arra, hogy megfogjuk a hibát. A végleges 1.2 kiadása után ugyanígy minden bizonnyal itt sem lesz lehetőség rá. Nincs arra kapacitásunk (de a legtöbb nagy disztribnek sincs, tehát itt nem arról van szó, hogy hány főből áll a csapat), és értelmét sem látjuk, hogy visszamenőlegesen foglalkozzunk a disztribbel. Előrefelé akarunk haladni, nem hátra. A 2.4-es kernelt a magunk részéről lezártuk, leszámítva természetesen az olyan sec.hibák javítását, mint a minap a clear_cpu() bibi.
Sajnos nem vagyok olyan szinten hogy patch-et tudjak küldeni, csak a tapasztalataimat tudom összefoglalni :(
A 2.4.24-es kernel tartalmaz egy bug-ot, ami miatt az USB 2.0-s eszközök csatlakoztatásuk után lefagyaszthatják a rendszert. Az 1.1-es eszközök gond nélkül mennek.
A teszt - hardver: USB 1.1 és 2.0 pendrive, USB 2.0 6in1 olvasó
Gépek:
1, GA-7N400-L, AMD Barton 2500+, 256 DDR (UHU)
2, I440BX, Celeron 400, 128 SD (Debian)
3, i810, Celeron 433, 320 SD (UHU)
Az 1-esen és a 3-ason UHU 1.1.1 van, próbáltam a CD-ről jött és a 2 frissített kernellel is. A 2-es gépen 2.4.24-es kernel van, saját fordítás, USB Mass Storage debug opcióval. A naplófájlok tanúsága szerint az olvasó nem fogadja el a neki kiosztott device id-t, a pendrive esetén pedig timeoutok voltak. Az eszközök egy régebbi Gnoppix alatt működnek, és lett tesztelve 1.1 és 2.0 host controllerekkel több különböző alaplapon is, így szerintem egyértelműen a 2.4.24-es kernel a ludas. A debbyn nem használok kernel foltokat, így ez sem lehet hibaforrás.
A gyanúmat megerősíti, hogy kipróbáltam az olvasót és a pendrive-ot egy "production" szerveren 2.4.22-es foltozatlan kernellel (utólag belátom ez nem volt jó ötlet). A hiba nem jelentkezett, de a pendrive-ból csak az első 256 mega látszott, win98SE és 2k alatt is (a 2k megint egy másik gép, egy HP Vectra VE). A méretprobléma HW-es hiba, garanciás lévén visszavittem.
A kapott infóval egy új kernel fordításához láttam hozzá. Letöltöttem a 2.4.26-os kernel a kernel.org-ról és engedélyezett devfs-sel elindult az új rendszer. Supermount nem volt, így kézzel mountoltam az olvasót, ami korrektül működött, többszöri le-fel csatlakoztatás után sem volt vele probléma. Az új kernel szintén mass storage (és egyéb) debug opciókkal fordult, a naplófájlban sem volt hibaüzenet. A Changelogban írtak "USB fixes"-ről, gondolom az segített.
Megértem a support politikátokat és szívesen tesztelem az új UHU-t ha lesz béta belőle. Van valami fájdalommentes módja annak hogy kipróbáljam anélkül hogy feladjam a jelenlegi rendszeremet?
UI: Tetszik az UHU-klub, ha lesz benne bugtrack-support, én benevezek rá.
:twisted:
UI2: Van közelebbi hír a csomagoló tanfolyamról (hol, mikor lesz)?
[quote:07226d040c="egmont"]Csak úgy jelezném, hogy a fejlesztői ágban 2.6-os kernel van, igaz, egyelőre devfs, és még nem teljesen biztos, hogy a következő UHU-ra átállunk udev-re, de meg fogjuk vizsgálni
bocs, akkor le vagyok maradva :D
igazában majd akkor lesz probléma, ha majd eltűnik a kernelből. az pedig imho néhány év múlva lesz ;-)
[quote:07226d040c="egmont"]
Igenis nagyon rég óta, bőven az 1.1 kiadása előtt tudtuk már, hogy a devfs nem lesz örök életű, le fogjuk egyszer váltjuk udev-re.
a devfs is érdekesen csinálja, EXPERIMENTALból egyből OBSOLETE, az azért szép :D
igen, a belinkelt oldalon írták, hogy azért mert lelépett a fejlesztője, meg voltak el nem ismert / ki nem javított hibák. szerintem nem vészes a hiány mert tud devfs-kompatibilis elrendezést.
Vettem egy 1G-s pendrive-t (USB 2.0) és lehalt tőle a bagoly. A 2.0-s 6in1 olvasómtól szintúgy. Tippem szerint kernel bug, winfos 98 alatt megy mindkettő. A 26-ban találtam olyat, hogy USB fix, szóval megpróbálom. Ezt még megúszhatom gányolás nélkül is akár...
Az lenne a kérdésem, hogy van-e valaki aki csinált már ilyet az UHUval? A fejlesztők kernel config fájljából szeretnék kiindulni, és kísérletezgetni. Elég ha a headers csomag felpakolása után elérhető configot átmásolom az új source tree megfelelő helyére?
Hi!
Szerintem az UHU-Linux honlapjan tutira talalsz forditott kernelt.
By(t)e
TBS::Antiemes
nem, ezt néztem. Van a release-nél frissebb, de az is csak 24, és detto nem megy a cucc. Az előbb t@koltem vele, mert a belecsomagolt (új) kernelnek ugyanúgy "2.4.24-7"-es szignója van, mint a release-nek, és én azt hittem, nem frissült. Pedig igen...
A fordítás meg amúgy már régóta érik, mert qrva sok cucc van bele + modulban, ami nekem nem kell (firewire, sata, raid, true scsi, usb hányások driverei, stb. )
mit tippelsz, menni fog így?
Hi!
Szerintem ha a kernel maradt ugyanolyan verzioju, akkor nem hiszem, de erdemes +probalni.
By(t)e
TBS::Antiemes
A konfigra gondoltam. Az UHU frissített kernellel nemtom mi van, de nem javította meg az USB2.0 hardverek támogatását.
gcc up & running :)
nézz meg egy uhu kernel patch setet, ha forrásból felteszel egy kernelt supermount patchcsel+devfssel, akkor valszeg el fog indulni :wink:
hi!
Bagolyban a frissített kernelnek azért ugyanazlett a relase száma, mert az apt-gettel így meg lehetett autómatikusan frissíteni 1-2 sechólt.
szvsz a gyári uhu-s kernel nem nagyon szereti az usb-s cuccokat. nekem sis-es alaplappal, öcsémnél meg egy abit ba6-al képes volt fagyni
a megoldás a saját kernel. erre én a 2.6-os szériát választotam...
... bevált. nem fagy az usb eszköz miatt.
pete:
"A fejlesztők kernel config fájljából szeretnék kiindulni, és kísérletezgetni. Elég ha a headers csomag felpakolása után elérhető configot átmásolom az új source tree megfelelő helyére?A fejlesztők kernel config fájljából szeretnék kiindulni, és kísérletezgetni. Elég ha a headers csomag felpakolása után elérhető configot átmásolom az új source tree megfelelő helyére?"
imho nem tul nyero otlet, se a disztro kernel forrasa, se a .configja;
vanillabol csinalj egy sajatot;
http://fellow.linuxforum.hu/kernel_felkonfig
mivel usb hardwarem nincs nagyon jol jonne, ha irna vki par szot;
gondolom itt mass storage support kell; meg az lspci mindig jo kiindulas;
nos, érdekes fejlemények....
* A 2.4.22 nem fagy, de csak 262 Mb-ot lát a diskből
* A .24 debby alatt ugyanúgy 262 MB-ot látott, de belefagyott.
* A .26 nem birkózik meg vele. Ezt csak a logokból tudom, mert valahogy az új kernelem nem tudott konzolt nyitni.
Ötlet? A virtual "console support" meg a "console on VT" fixre be volt fordítva. :roll:
Nem kapcsoltad be a devfs -t. Azért nincs konzolod.