Áll még a nagylelkű ajánlat? Kíváncsi vagyok egyfelől, másrészt nyakamon egy gép, amit mindenképpen meg kell csinálnom a héten. Nagyon nem aggódom, mert látom, scripttel megoldható a dolog, de izgatja a fantáziámat, mit írtál, s mi az, ami egy esetleges saját verziómban elkerülné a figyelmem.
Számos különböző ponton hívja meg a hotplug-ot, a $1, $ACTION, $DEVICE és társai mondják meg, hogy éppen miről is van szó. Konkrétan a mi esetünkben elég arra reagálni, hogy $1=scsi_device és $ACTION=add. A bővebb leírás valahol a /usr/src/linux/Documentation/usb/hotplug.txt-ben lakik.
Elkezdtem barkácsolni, s rögtön meglepetésben volt részem. Mivel Fedora nem használja, legalább is nem volt kitöltve a /proc/sys/kernel/hotplug így az alábbit tettem:
ezen felül írtam egy /usr/local/sbin/hotplug scriptet:
#!/bin/bash
date >>/tmp/hotplug.$$ exit 0
Ezután bedugtam a pendrive-ot - hald le van állítva -, s az
ls -1 /tmp/hotplug* | wc -l
parancs 21-et adott vissza, a pendrive kihúzása után pedig 40-et. Megnéztem, tényleg ott voltak a file-ok a nevükben az éppen aktuális PID-del, tartalmuk tényleg a dátum. A kísérletet megismételtem, mert arra gondoltam, túl gyorsan reagálja le a kernel a változást, s a csatlakozó pergéséből jön a sok hívás. A második kísérlet eredménye ugyanez volt. Tehát bedugáskor 21, kihúzáskor 40-21=19 alkalommal hívódott a script. A file-ok hossza ugyanakkora volt, tehát ugyanaz a PID nem került újra kiosztásra, de ez ilyen rövid időn belül nem is várható.
Mi okozza a hotplug handler ilyen sok alkalommal történő hívását? Vagy mit rontottam el?
De gondolom, lehetne script is, nem? Abban segíthetnél néhány jó szóval, hogy a kernel hogyan hív külső programot eseményvezérelten, például azért, mert bedugta valaki valamijét :) a gépbe, és történik-e valamilyen paraméterátadás. Mondjuk ez nem annyira kritikus, mert kivadászható a /dev-ből is sokminden, szóba jöhet még a /proc illetve /sys szerintem.
Remélem GPL, vagy valami hasonló licensszel teszed közzé. Őszintén szólva érdekel, de ami még ennél is jobban, az a működési mechanizmus. Mert én nem szégyellek shell script-et írni a feladatra.
Igen, igen, látom már, köszönöm. Ha az érintett gép közelében leszek éjszaka, nekiesek. Vagy akár ezen is leállítom a hald-t, s nézegethetem a megoldás mikéntjét az ötleteid alapján, de addig még el kell végeznem a munkámat.
Én még csak olyat láttam, hogy egy pendrive-on egy partíció van (vagy egy sem, hanem a komplett device van formattálva)... nyilván lehet több partícióval is sportolni, ha van rá igény...
Érdekes dolog még az extended partícióbejegyzés. Azt hiszem, azt csinálnám, hogy megpróbálnám felcsatolni, s ha nem sikerül, törölném a hozzá létrehozott üres alkönyvtárat. (Nyilván olyan script-et szeretnék, amely több pendrive-ot is kezel egyszerre, melyek akárhogyan is lehetnek partícionálva.)
Néhány szót írnál arról, hogy ez a hotplug interface mi az izé, és hogyan érhető el, hogy saját script induljon eseményvezérelten? Most felületesen futottam át amit írtál, mert dolgom van. Azt sem tudom, hogy azon disztribúciókban, amelyek hald-t használnak, van-e hotplug, vagy ez a kernel elidegeníthetetlen része, vagy hogyan van ez. Ha lennél olyan jó, hogy néhány szót írnál erről, megköszönném.
Attól nem félek, hogy nem tudnék script-et írni rá, csak az eseményvezérlés mikéntje az igazán érdekes itt.
Ha a haldaemon-t leállítom, akkor működik a net is, a mass-storage eszközök is, de természetesen nem ismeri magától fel az új eszközt. :-/ Azt mégsem mondhatom a felhasználónak, hogy keresse meg a /dev-ben a bedugott eszközének device file-ját, aztán csatolja fel. Én még csak-csak megteszem, de ez már nekem sem túl felhasználóbarát metódus mindennapi használatra.
Ha az ember tudja, mit keressen, talál egyet, s mást. Érdekes ez a rész:
The problem stems from the fact that both option and usb-storage can bind to the modem when in storage mode: the former binds because of the storage class, the latter binds because of VID/PID match. The modprobe loads both, it's random which wins. If usb-storage wins, everything is fine. If option wins, it binds to modem still in storage mode and does not work.
Mesélnék egy nagyjából két hete tartó szívásról, s egyben segítséget is kérnék.
E220 HSDPA GSM USB modem bedug, létrejön a /dev/ttyUSB0, /dev/ttyUSB1. Ezután ifup Pannon, elkezdi felküzdeni magát, majd az említett két device file megszűnik. Ezt egy script-tel folyamatosan ellenőrzöm:
while sleep 1; do ls /dev/ttyU*; done
Ezután a kernel újra felismeri az eszközt, a device file-ok megint ott vannak, majd megint eldobja. Akkor is, ha nem csinálok ifup-ot. Már vettem PCI-os USB host interface-t a gépbe, mert arra gyanakodtam, az alaplapi USB interface kezelése bugos. A problémát ez sem oldotta meg. Természetesen legfrissebb, 2.6.24.1-es vanilla kernel, ettől sem hatódott meg. Úgy két hét log olvasgatás és internet böngészés után találtam egy érdekes infót, ami úgy néz ki, valóban a probléma gyökere: ha bennvan az usb-storage modul, az ütközik az usbserial vagy option modullal. Nosza, próbáljuk ki:
modprobe -r usb-storage
Ellenőriztem, hogy valóban eltávolításra került, s lám-lám, nem szűnik meg a két device file, s az ifup létre tudja hozni a kapcsolatot, van a gépen mobil internet. Igen ám, de van egy apró probléma: az usb-storage modul kellene, mert az nincs rendjén, hogy bedugom a pendrive-ot, betöltődik a modul, minek hatására elmúlik az internet.
A kérdés tehát az, hogy hol - HAL, udev? - és mit kell barkácsolni annak érdekében, hogy az usb-storage modul amilyen messzire csak lehet, kerülje el a /dev/ttyUSB* eszközöket.
Ha valami ötlete van valakinek, ne fogja magát vissza senki, mert már a múlt héten jöttek volna a gépért, tudniillik nem az enyém.
Az már csak hab a tortán, hogy momentán az ethernet interface aludt el, de legfeljebb az interneten keresztül ssh-zok a tőlem fél méterre lévő gépre...
Most jó kedvem van. Egy ismerősöm gépére kellene egy Huawei E220 HSDPA USB modemet feléleszteni Linux alá. Nosza, előbb nézzük a saját gépemen, mielőtt nála Linuxot telepítenék mindhiába. Modem bedug, egyből ott a /dev-ben a ttyUSB0, ttyUSB1, ttyUSB2 eszközök. Ez jó jel. Ezek után Fedora standard GUI-jával felvettem az eszközök közé a modemet /dev/ttyUSB0 hivatkozással, telefonszámnak *99#, login név, jelszó megadva, a profile-nak is adtam nevet, utána mentettem az egészet, a működő wlan kapcsolatomat leállítottam, az új, GSM modemen keresztülit aktiváltam, és azonnal volt netem. Természetesen ifconfig-gal ellenőriztem, tényleg a GSM modemen keresztül ment a net, sőt, forrásból lefordítottam a he220stat-ot, az is egyből megmutatta a modem forgalmát.
Fedora 8-on gyakorlatilag 20 perc alatt feltápászkodott úgy, hogy előtte azt sem tudtam, mi az az USB-s GSM modem. Persze nem fogalmilag nem tudtam, hanem életemben most láttam először ilyet.
Magamat mindig be szoktam tenni az uucp csoportba, így az xhe220stat-nak volt hozzáférési joga az eszközhöz, tehát sima felhasználóként indítva is le tudta kérdezni a modem statisztikáját.
A kernelem 2.6.23.14 vanilla, de szerintem a Fedora saját kernelével is menne, mert a vanilla kernelem alapjául a fedorás .config szolgált.
Én egy motorola telefonnal használom a netet. Laptopon is, asztali gépen is. Egyszerű modemként használom, a telefon a #99***1-et vagy mit tárcsázza. Pesten hsdpa-van, vidéken ami épp akad, semmi gondom vele. Emlékeim szerint bruttó 10 perc volt felrakni, igaz usb-n keresztül megy, mert minek szívjak a bt vicceivel ha nem muszáj?
