minimalista kínok - fölösleges modulok

Debian GNU/Linux

Lassan egy hónapja (kihagyásokkal) kínlódom azzal hogy kiszedjek bizonyos modulokat:
RAID:
dm_mod, dm_snapshot és dm_mirror (persze velük együtt a kmirrord)
ACPI:
thermal, processor és fan (persze velük együtt a kacpid)
a "modprobe -r parancs segítségével minden gond nélkül eltávolíthatóak, viszont sem a blacklist (a nevezett modulokra) sem a modconf nem segít.
Eddig a leghatásosabb az volt ha teljesen elrejtem a rendszer elől a nevezett modulokat (eldugtam egy külön könyvtárba). A dmesg illetve a syslog sem hiányolja őket - én sem!
Mivel lehet ezeket korrektül "kikonfigurálni"?

  • 8158 megtekintés

( pinyo_villany | 2008. 01. 27., v – 14:15 )

/etc/rcS.d/S25libdevmapper1.02

ebbe nézzél körbe ;)

linux v2.6.22.15 + madwifi v0.9.3.3-mal itt
debian gnu/linux @ linux-2.6.22.17-rc2-szami2

Ez egy jó kis szoft link az /etc/init.d/module-init-tools nevezetű scriptre.
Ha jól értem(?) ez betölti az /etc/modules fájlban található modulokat (ez mind összesen a "loop" bejegyzést tartalmazza) majd bekukkant a /lib/modules/boot fájlba - ilyenem nincs!

Még a leg gyanusabb, az /etc/modprobe.d/aliases -ban az
"alias block-major-58-* lvm_mod"
de ez csak egy buta tipp - azért kipróbálom :)

igen, ez egy softlink ami erre mutat:/etc/init.d/libdevmapper1.02 ... és ami nekem így néz ki: 


#! /bin/sh

PATH=/sbin:/bin:/usr/sbin:/usr/bin
NAME=libdevmapper1.02

set -e

case "$1" in
  start)
        echo -n "Loading device-mapper support"
        modprobe dm-mod 2> /dev/null || true
        modprobe dm-mirror 2> /dev/null || true
        modprobe dm-snapshot 2> /dev/null || true
        echo "."
        ;;
  stop|restart|force-reload)
        ;;
  *)
        N=/etc/init.d/$NAME
        echo "Usage: $N {start|stop|restart|force-reload}" >&2
        exit 1
        ;;
esac

én Etch-et használok

szerk.:

és még ebbe /etc/default/acpid a file-ba nézzél bele

linux v2.6.22.15 + madwifi v0.9.3.3-mal itt
debian gnu/linux @ linux-2.6.22.17-rc2-szami2

Én is Etch -et használok, csak kicsit kockásodtam bele a dologba, és valamit összekevertem. Bocs :)
A hivatkozást "kinyomtam" a /root egy backup könyvtárába és láss csodát, nem kell RAID -et hasnálnom! :)
Most már csak az ACPI -val kell elbánnom!
Köszönöm!

UI: Az /etc/rcS.d könyvtár jelentőségét még mindíg nem értem. A többi runlevel -t már egéyz jól kezelem, de ez?
Mindenesetre az update-rc.d -r libdevmapper1.02 semmit nem törölt!?

ertelmesebben mint a menus szarok, amugy ezt meg az ember nem hasznalja mindig, mivel altalaban egyszer kell beallitani az init scripteket
ha meg nem tetszik a sysv-init akkor le lehet cserelni bsd-szeru initre is, szoval ezen nem mulik

linux v2.6.22.15 + madwifi v0.9.3.3-mal itt
debian gnu/linux @ linux-2.6.22.17-rc2-szami2

hat biztosithatlak rola, hogy bsd inithez lovesnyi koze sincs annak.
ha megneznel egy netbsd initet (barmelyik bsd-ben megtalalod), egy smf-et (even betta'), vagy akar egy rendes linuxot, akkor rajohetnel arra, hogy a hogy szeretett debianod egy rakas loturo.
de elkepzelheto, hogy a "mindent beallitunk az admin helyett, max szarul de alap dolgokra nincs rendes eszkoz" filozofia neked ugymond "bejon", de hat rossz izlesu embereknek is kell OS-t (bocsanat, distro-t) csinalni

ui.: nem jott at, hogy milyen menus szarakra gondolsz, plz advize

-. . - -... ... -..

pl.: http://packages.debian.org/etch/sysv-rc-conf

amugy az init reszt, azt alapbol install utan kiszedek egy rakat felesleges dolgot es az igaz, hogy nem a legertelmesebb, de ha mar megszoktad, akkor jo...

amugy igen erosen fontolgatom az s/atallast/egyuttes hasznalatot/ freebsd-re es mar elkezdtem teszt szinten nyuzni es azt kell mondanom rendben van a rendszer.

linux v2.6.22.15 + madwifi v0.9.3.3-mal itt
debian gnu/linux @ linux-2.6.22.17-rc2-szami2

amugy a hasznalhatosagnal erre gondoltam:

update-rc.d valami start 99 2 3 4 5 . stop 20 0 1 6 .

es igy kicsit egyszerubb bevagni minden runlevel-be amit kell, amig ezt nem fedeztem fel, addig mindent kezzel csinaltam ( ln -s ) es valamilyen szinten megkonnyiti a rendszer kezeleset

linux v2.6.22.15 + madwifi v0.9.3.3-mal itt
debian gnu/linux @ linux-2.6.22.17-rc2-szami2

na kicsit visszafogom most magam :)

nehogy mar szamozni kelljen az initscripteket, hogy milyen sorrendben induljanak :)

na figyu:

# PROVIDE: lighttpd
# REQUIRE: DAEMON

(..)

DAEMON az egy metafuggoseg / milestone

rcorder /etc/rc.d/*

es sok lyen fajlt feldolgozva fuggosegi sorban adja at oket rc inditasra

persze szimlinkeles is mukodik, meg is lehet szokni, de ha lehet, akkor ne szivassa magat az ember

-. . - -... ... -..

igen nθzegettem mar :P
csak itt feleslegesen kell scannelni, hogy mi indult mar el, de itt ennek van egy olyan elonye, ha az egyik ledoglik akkor "nem tesz kart"

amugy mind a ket rendszernek mas a filozofiaja es ez latszik is a ket rendszer kozott

linux v2.6.22.15 + madwifi v0.9.3.3-mal itt
debian gnu/linux @ linux-2.6.22.17-rc2-szami2

Tökéletesen igazad van. Bár BSD-t nem ismerem.
A FBSD feltelepítéssel gyötrődtem, de valamiért nem szereti a vasam.
Vagy én vagyok béna. :)

"... ha lehet, akkor ne szivassa magat az ember"

Mandriva-val ismerkedem és egy szívatós init-be futottam

mysql vs mydns

mindkettő 99 sorszámot kap(szimlink), de az átok abc sorrend a mydns ellen dolgozik! :)
Gyárilag a mydns indul(-na), de nincs socket ezért [SIKERTELEN]
üzenettel elintézve. :)

Ezért módosítanom kellett a scriptjét
ilyen volt:

[ "${NETWORKING}" = "no" ] && exit 0

[ -f /etc/mydns.conf ] || exit 0

[ -f /usr/sbin/mydns ] || exit 0

ilyen lett:

[ "${NETWORKING}" = "no" ] && exit 0

[ -f /etc/mydns.conf ] || exit 0

[ -f /usr/sbin/mydns ] || exit 0
## mysqld miatt
if test " [ ${MYSLD} = "no" ] &&" ; then /etc/init.d/mysqld start
fi

Gyári csomag mindkttő.
Ilyen gentoo alatt nem ferdülhetne elő! :)

( pinyo_villany | 2008. 01. 27., v – 14:50 )

vagy ha annyira zavarnak a modulok akkor forgass egy kernel-t, amiben kikapcsolod a modul támogatást és mindent beleforgatsz, ami kell

linux v2.6.22.15 + madwifi v0.9.3.3-mal itt
debian gnu/linux @ linux-2.6.22.17-rc2-szami2

Persze a kernel forgatás sok mindent megold, viszont kell? Ha kicsit beletanul az ember a konfigurálásba akkor ez kimaradhat, ráadásul ha új hardware van nem kell mindent újra fordítanod, kivéve a gyevi bírót - ha az új kernel (most azt hiszem 2.6.24) tartalmazza a megfelelő driver -t és a kicsit avétos "2.6.18-5-686 #1 SMP" amit a Debian stable -val adnak nem.
Szeretném megtanulni inkább a konfigurálást, kernelt forgattam eleget, abba is nagyon belelehet veszni.

Hát szép dolog, mond csak te ismered, utána néztél mindannak a klf. chipnek ami alaplapodon és a bedugott kártyákon szerepel? Pl. nekem elég sok utánajárást okoz hiszen elég sokféle géppel dolgozom. A modularitást nem véletlenül találták ki, ez volt a válasz a mikro - monolitikus kernel vitára. A windows pl. mikrokernelt alkalmaz, jól definiált driver felületekkel így minden hw gyártó jól tud alkalmazkodni. Így lehetséges az univerzális telepítő rendszer, amivel a gépek 80 - 90% telepíthető a pingvin, úgy hogy nem kell belemélyedned a chipek rejtelmeibe, felcsapod a rendszert és voila működik.
Persze ha valaki telepítésből akar megélni ...
A modern kernelek számos szolgáltatást modulba tesznek/tehetnek. pl. mint programozó rohadtul hiányoltam az aszinkron műveleteket - AIO, hiányoltam a fájl módosításával kapcsolatos eseményeket - FAM. Sorolhatnám ha kell beteszed ha kell kiveszed, és nem forgatsz, így is szép ez.
Aztán itt vannak a profán felhasználók, nem akar kernelt forgatni csak szöbveget szerkeszteni, leveleznichatelni stb. Nem érdekli a chipset - azt sem tudja mi az, és nem is kell neki!

( bastya_elvtars | 2008. 01. 27., v – 14:59 )

Ennek mi az értelme?
It doesn't matter if you like my song as long as you can hear me sing

nézd meg a fent scriptet, ez mindenféleképp behúzza ... + az acpi init scriptje is behúzza, ha nem kommentezed ki a /etc/defaults/acpid file-ba, hogy ne húzza be.
ha meg olyan speciális kernel kell, akkor meg forgasson modul nélkülit, amugy meg én nem szeretem a modulokat így modulok nélküli kernel-t használok, mindenhol, ahol lehet

linux v2.6.22.15 + madwifi v0.9.3.3-mal itt
debian gnu/linux @ linux-2.6.22.17-rc2-szami2

"ha nem kommentezed ki a /etc/defaults/acpid file-ba, hogy ne húzza be"
Kommenteztem, lecseréltem MODULES="none" - kifejezésre ahogy a scriptben javasolják. Továbbra sem tudok megszabadulni a thermal, processor és a fan acpi moduloktól és a kacpid -től! :(
Ki ránthatja ezeket be?

( tovis v | 2008. 01. 28., h – 14:41 )

Az acpi drivereket (thermal, processor, fan) nem sikerült kipiszkálni.
Az /etc/default/acpi fájlban kommenteztem és az ott találtaknak megfelelően szt is kipróbáltam hogy MODULES="none", de semmi eredmény.
Tanulmányozgattam a syslog ot. Természetesen az acpi alapvető szerepet játszik a kernel felépülésekor így a ramfs - initramfs -ben is szerepel. Lehet hogy ott rántja be, majd "elfelejti" kidobni?!

Egyéb modulok, a hangkártya rengeteg erőforrást használ, pl. (asszem) MP401UART - még interruptot is visz - sosem használtam, az egész midi látszólag nem kell!? Kieleht azokat venni szerintetek, úgy hogy a többi szokványos hang funkció működjön?

Sokat "okosodtam". Belekukkantottam az initrd.img- által tartalmazott ram disk -be. Itt a /scripts/init-premount/thermal nevű scriptben, rántja be a fan és a thermal modulokat a kernel (i386|amd64|ia64 esetén). Ennél fogva, gondolom hiába fogom én "kikapcsolni" ezeket az /etc/default/acpid scriptben, ezek már benn vannak! Vagy megbékülök velük, vagy, esetleg "valahova" beszűrok a boot végére egy kis scriptumot ami kitörli a nrem kívánatos modulokat - amolyan post/post boot script -ként!?
Már csak arra kellene rájönnöm, hova is tudom ezt szépen, beilleszteni valahova a login script elé?

( tovis v | 2008. 01. 28., h – 16:37 )

No, hát a snd_mpu401_uart és snd_mpu401 szépen kiszedhető a blacklist segítségével :) - egy jó kis hw interrupt felszabadul! Mint amolyan plussz szolgáltatás eltöntek a sequencer cuccosok is :) - egy gondal kevesebb.
Sajna az ACPI thermal/procesor/fan cuccokat még nem tudtam eltüntetni, de ezek már tényleg csak a memóriát foglalják(?) Mindenestere ha van valakinek valami ötlete (amit még nem próbáltam) annak örülnék!

Mindenképpen köszönöm az eddigieket!

A thermal / processor tól függ(het) - nálam függ - pl. egy cpufreq is. tehát ha van cpufreq, akkor emiatt tölt(het)i be. vagy powersaved daemon szól közbe, és az tölti be pl. fan-t (?).a powersaved átvesz némi funkciót az acpidtól alapjáraton. (ill. acpid nál a powerbtn.sh kilép ha érzékeli a powersave daemont.

de az igazsághoz hozzátartozik, hogy nálam működik a 

/etc/default/acpi

-ban a modules= féle módzser.
ha beírom hogy modules="button", akkor a /etc/init.d/acpid restart csak a button-t tölti be, ha beírom hogy modules="thermal button", akkor ezt a kettőt, ha "all", akkor mind a 4-et amit modulba beforgattam a kernelgyártáskor.

----------

Nem a zsömle kicsi, a pofátok nagy...

A thermal és a processor modul összefüg. Az lsmod is így adja ki:
...
thermal 13608 0
processor 28840 1 thermal
fan 4804 0
...
Ráadásul, a folyamatok közt ott csücsül a kacpid, sajna nem tudom hogy lehet kikapcsolni - akár csak egy kis próba erejére. A processor/thermal/fan modulokat viszont simán kilehet titltani a #modprobe -r parancsal, a kacpid -ot ez nem befolyásolja. Ráadásul, nem tudom hogy a kacpid mennyire befolyásol olyan dolgokat mint a reboot és a poweroff.

A thermal+processzor az olyan online órajelállítgató cuccoknak kell mint a cpufreq. A fan az elvben noteszen jó ha bent van, ha tudja akkor ventit kapcsolgajta pl. a powersave daemon hajóltom. kacpid ezek hiányától még menni fog.

ha nem akarsz acpit, akkor talán acpi=off kernelparaméter, acpi-t nem lehet modulba csak kernelbe fordítani ; rebootot ez sehogyan nem befolyásolja sz'tem, poweroffot igen, elvben ha se acpi, se apm, akkor nem fog kikapcsolni a gép leálláskor, hanem a shutdown / power off. utolsó sort látod majd kikapcsolásnál, és a gépet neked kell kikapcsolni a gombbal. :-)

--------------

Nem a zsömle kicsi, a pofátok nagy...

Bocs, igen azt mondjuk mondhattam volna hogy desktop gépről van szó.
CPUI frekit nem szoktam piszkálni! - melegszenek ezek a vasak anélkül is.
Nem tudom, de mintha az acpi -nak az egyéb hardware konfigurációhoz is van köze - tény hogy sokszor félreolvasom az ioapic és az acpi -s dolgokat (syslog, dmesg elég tömör, itt bukik ki hogy dislexiás is vagyok).
Viszont úgy tűnik, tényleg nincs más mint vagy a kernel boot -ban kikapcsolni vagy utólag rc.local -ból lebontani ezeket. Kössz.

Nekem ellenkező a problémám, nem akar befordulni a kernelbe a hőmérsékleti cucc. Mellesleg a .config-ban nem is találom, nem tudom, melyik az a menuconfigban a kernelfordításkor.
Azt mondod, 2 dolog (thermal és a processor modul) összefügg, ezek szerint ha az egyiket megtalálom (esetleg öntudatlanul), de a másik nincs, akkor nem mennek?

A probléma röviden:
acpitool ezt adja:

root[etc]# acpitool
Battery #1 : charging, 90.00%
AC adapter : on-line
Thermal info :
root[etc]#

/proc:

root[proc]# ls -shR /proc/acpi
/proc/acpi:
total 0
0 ac_adapter 0 battery 0 button 0 event 0 processor 0 wakeup

---------
kínlódás:

root[proc]# modprobe thermal
root[proc]# acpitool
Battery #1 : charged, 100.0%
AC adapter : on-line
Thermal info :
root[proc]#
...semmi.

...thermal sehol, pedig tényleg jó lenne az a hőmérő. Mit baltázhatok el?

---
--- A gond akkor van, ha látszólag minden működik. ---
---

I2c:

│ │ <*> Intel 82801 (ICH/PCH) │ │
│ │ < > Intel SCH SMBus 1.0 │ │
│ │ < > Intel PIIX4 and compatible (ATI/AMD/Serverworks/Broadcom/SMSC)

bejelölgetem ezt a kettőt is, hátha...

-*- Hardware Monitoring support --->
...itt ezeket jelöltem be:

<*> Asus ASB100 Bach
<*> Intel Core/Core2/Atom temperature sensor

..előbb az asus kimaradt, most vettem észre, hogy van.

make...
Majd jövök...
Kellemes Ünnepeket Neked :)

---
--- A gond akkor van, ha látszólag minden működik. ---
---

Ezzel megállapítottam valamit!

Do you want to probe the I2C/SMBus adapters now? (YES/no): y
Using driver `i2c-i801' for device 0000:00:1f.3: Intel 82801FB ICH6
Module i2c-i801 loaded successfully.

Minden másra nemmel válaszolgatott..

Végül nem vártam reggelig, elindítottam ezt, ami a fentivel pakolódhatott fel:

root[a]# sensors
acpitz-virtual-0
Adapter: Virtual device
temp1: +49.0°C (crit = +90.0°C)

eeepc-isa-0000
Adapter: ISA adapter
fan1: 0 RPM

root[a]#

Felraktam a radiátorra a laptopot, mire elkezdett sülni:

root[a]# sensors
acpitz-virtual-0
Adapter: Virtual device
temp1: +52.0°C (crit = +90.0°C)

eeepc-isa-0000
Adapter: ISA adapter
fan1: 1320 RPM

root[a]#

...szóval fut, ergo ez valóban egy program, ami KELL.

Eddig azt sem tudtam, hogy van ilyen.

Kösz a segítséget!

:)

---
--- A gond akkor van, ha látszólag minden működik. ---
---

( padawan | 2008. 01. 29., k – 15:14 )

Hamar szobakerult a hangkartya: miert kell egy ens1371-es hangkartyanak az ac97 felet hasznalni? :)

Bocs! - ezt nem értem. Most éppen egy GigaByte 8IPE1000 -el küzdök, ICH5 valami Intel 82801EB/ER AC'97 -el. Hol jön be a képbe az ens1371?
Egyébként már régen piszkálja a csőrömet ez az mpu401 -es dolog, speciális baudrate -kel midi kommunikációt valósit meg, midi zenei eszközökkel. Nem vagyok zeneszerző, és nem is készülök ilyesmire ...
Viszont az mpu401 UART megeszik (egyesegyedül) egy jó kis hw interruptot! Szerintem ez a luxus.