Linux eszközkezelés 2011

Napokban történt némi fejreállás a fejlesztésre használt számítógépemben, minek hatására portalanítottam és kicsit karbantartottam.
Mivel sokat foglalkozok képkezeléses dolgokkal van a gépben egy BT878-as chippel szerelt Leadtek Tunerkártya. Ez a kártya igen remek fagyásokat, kernel pánikokat tud okozni linux alatt, ha régebbi PCI kártyákkal kerülnek egy fedél alá. Az ok a linux IRQ sharingben keresendő és elég esélytelen, hogy valaha is megoldják.
Jelen esetben a gép összerakást követően egy PCI kártyával lett indítva, mire dobott egy finom kernel pánikot az alaplapra integrált AC97 Alsa modullal. A gép olyan lett mint a ragasztós csiga, ezért egy idő után tiltottam az integrált hangkártyát és visszatettem a jó öreg SB Live 32 kártyát. Újabb újraindítás és ismét csak kernel pánik az Alsa modulban. Nem foglalkoztam vele, ritkán kell valamilyen hangkeltő eszköz.
Ami érdekesebb volt, hogy a fejreállt Alsa miatt miképp reagáltak a különféle programok. Gyakorlatilag minden KDE alapú alkalmazás valahol letérdelt. A Kate példának okáért a file mentéskor, a k3b a kilépéskor, a kdm sessionváltáskor. Az utóbbi olyan szinten merevre fagyasztja a rendszert, hogy csak reset gombbal lehet bármit is kezdeni vele. Az audacious szintén merevre fagyott csak kill-el lehetett kiirtani. Az mplayer megpróbált valamit kezdeni a lejátszandó anyaggal aztán diszkréten kilépett. A flash plugin 0.2-0. fps-el volt képes visszajátszani a youtube videókat.
Ma aztán, az akut megfázásomnak köszönhetően nem volt kedvem forró fémgőzt szívni, inkább elkezdtem utánaásni a problémának. Kicsit nézegettem a kernel logot, amiben a kernel pánikot egy a /dev/char-ban lévő sysfs file létrehozási hiba előzött meg. Kiderült, hogy a gyökér épp fullon van, ezért nem képes eszközt létrehozni. Ez megmagyarázza a hangeszközt kezelő programok kihalását, de nem magyarázat a kdm hibájára. Ezt ugyanis okozhatja, hogy nem tud PID filet létrehozni az X, de nem magyarázza, hogy bootnál, miért tud mégis elindulni.
Kíváncsiságból töröltem pár byteot az egyik log fileból és úrjaindítottam a rendszert. Ettől eltűnt a kernel pánik és a sessionváltáskor is üzemelt a KDM.

Pár gondolat ennek kapcsán:
Miért kell mindenáron a /dev-nek egy fizikai partíción lennie? Egy átlag gépben a /dev mérete maximum pár száz kilobyte. Nem hinném, hogy olyan nagy veszteséget jelentene, ha ramdisk jellegűen tárolnák ezt.
Miért kell a /dev-ben majd 400 symlinknek lennie és miért mutat ennek majd a fele egy /dev-en belül lévő bejegyzésre mutatnia?
Miért nem képesek az alkalmazások egy ilyen hibát lekezelni? Annó azt verték a fejünkbe, hogy egy alkalmazást a megírásakor fel kell készíteni azt az előrelátható összes hibalehetőségre. Egy hangeszközt használó alkalmazásnál szerintem elég előrelátható, hogy adott esetben olyan eszközön próbálják elindítani, ahol nincs mód a visszajátszásra, tehát erre fel kellene az alkalmazást készíteni.

Egy kis csűrdöngölő lazításnak...

( pinyo_villany | 2011. 02. 12., szo – 18:01 )

es akkor a kovetkezo agyrem, amit a linux fele szokas:

Miert kell a /etc/mtab file es foleg miert ugy van az oda copyzva? Ha RO a / akkor meg meghal a mount... Miert, miert es miert?
___
info


       -n, --no-mtab
              Mount without writing in /etc/mtab.  This is necessary for exam‐
              ple when /etc is on a read-only filesystem.

http://linux.die.net/man/3/setmntent -vel hasznaljak irasra.
LSB deprecates the functions endhostent(), sethostent() and setmntent().

Elvileg elobb-utobb el lehet dobni. Ezt a featuret.
/proc/mounts is mutatja amit kell. De miota vannak mount context -ek ez is egy symlink :)

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

( sz | 2011. 02. 12., szo – 18:44 )

Nálam a mount már tavaly is azt mondta, hogy "none on /dev type devtmpfs (rw,mode=0755)"

( hrgy84 | 2011. 02. 12., szo – 21:03 )

Udev-vel a /dev tmpfs -re kerul asszem.
Symlinkek: Az idiota programok miatt. Van ami a CD-t csak a /dev/cdrom eszkozon, a hangot a /dev/dsp eszkozon talalja meg pl., meg hasonlo hardkodolt kedvessegek.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Huh, ez mondjuk az egyik kedvencem. Bármilyen eszközt használ az ember, akkor kénytelen egy read-el végigszaladni az összes lehetséges bejegyzésen. Én teljesen ellennék ha mondjuk a hangeszközt csak /dev/dspX-el lehetne megnyitni és nem még mondjuk a /dev/audio/kutyafule/rokagomba/xyz-vel.
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

Nem használok ALSA-t. A /dev/dsp csak egy példa volt, lehetett volna bármilyen más eszköz. Továbbá semmi nem kötelez arra, hogy valamilyen bugos keretrendszert használjak, ha tudom azt, hogy mit és hogyan akarok csinálni az adott eszközzel.
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

Nem feltetlen orola van szo, hanem azokrol a programokrol, amiket nem o irt, de direktben maceraljak az illeto eszkozt. Ennek van is nemi alapja sokszor, van amikor nincs, de egy fix: nem mindenki tartja be ezt a szabalyt.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

( turul16 v | 2011. 02. 13., v – 10:11 )

Az alkalmazas fel van keszitve, mint ahogy lattad nem alltak meg vegleg. Ha nem lattak volna valami eszkozrol infot ami nincs is ott, akkor meg sem probaljak.

Most akkor volt -e IRQ share problema vagy nem ?
Mellesleg kb. miota udev van, azota ramdisken van a /dev, nem tudom neked hogy kerult mashova.

Mellesleg az IRQ share nem egy ordongos valami, hogy a kernelben ugy altalanossagban el lehessen baszni.

APIC van -e gepedben vagy valami kokori dologgal probalkozol ? Tenyleg nem lenne eleg IRQ ahhoz, hogy ne kelljen share ?

ui.: Kernel Panik tunete vagy a reboot, vagy a szarazra fagyas. Ha ez nem volt, akkor esetleg egy szep BUG() hivas utan egy kis stacktrace(mini dump) kerult a dmesg be.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

De mind az audacious, mind a k3b, mind a kate olyan szinten merevre fagyott, hogy csak kill-el lehetett kilőni.
IRQ sharing hiba esetén a kártya benne van a gépben, a modul be van töltve, csak épp nincs elérhető eszköz.
Sajna a gép igencsak ki van tömve integrált perifériákkal, és elég öreg, hogy sharelni kelljen az IRQ-kat.
Valószínűsítem, hogy BUG() volt és nem kernel pánik ez esetben.
APIC vanik, viszont kőkori a gép és feltételezem valami BIOS bug is van mögötte. Érdekes módon, XP alatt nem jelentkezik a hiba. Annyira meg nem érdekelt, hogy nekiálljak debugolni...
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

( colos | 2011. 02. 13., v – 10:16 )

"a gyökér épp fullon van"

erdemes legalabb 5 fele szetszedni a filerendszert, hogy ilyen amator hibak ne forduljanak elo...

udv Zoli

Nem, erdemes idonkent torolni dolgokat, hogy a / ne telhessen meg.

A halalom, amikor a /var, a /usr, a /etc meg ilyenek kulon particion vannak, es ha barmiert hackelos modban (init=/bin/sh) kell bootolni, akkor ugy kell osszevadaszni a dolgokat, hogy mukodjon is a rendszer. Nem mondom, hogy surun van ilyen, de ha megis kell, akkor irto nagy a baj, es nem szeretek meg kulon ilyenekkel is szopni. Legyen a /var/log, a /var/lib/mysql, meg ezek legyenek kulon parton, de maga a /var ne. Ugyanigy a /usr/local senkit nem erdekel, de a /usr annal inkabb.

Tudom, hogy van ilyen biztonsagi policy, hogy a /usr/ legyen RO, de szerintem ez is hulyeseg. Ha minden user modban fut, akkor by default nincs joga irni, ha meg root joghoz jut, akkor meg mar annyira mindegy, hogy leut elotte egy mount -oremount,rw -t, vagy sem. Ketto percig akasztja meg az ilyen az ertelmesebb hackerjet.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal