[gelöst] beep abstellen? Neue Variante!

[mullers]

[skip intro]
Mmh, die meisten Menschen wissen doch, dass wir im
21. Jahrhundert leben - das ist schon mal gut.
Allerdings wissen es die Programmierer nicht, die denken,
dass ein Beep standardmässig nerven sollte - das ist nicht
so gut...
[/skip intro]

Was bis jetzt *immer*, als ultima ratio gewissermassen ge-
holfen hat, war das Modul `pcspkr` zu löschen, und in dem
Verzeichnis ein `depmod -a` zu machen. Dann war Ruhe.

Habe jetzt testweise 2.6.38-2-686-bigmem installiert, dann die
erwähnte Prozedur veranstaltet.

Code: Alles auswählen

 root@argon:# modinfo -F filename pcspkr
ERROR: modinfo: could not find module pcspkr

Wie man sieht, das Modul ist weg: Leider *nicht* der
beep. (nach Neustart versteht sich)

henry

[TRex]

Naja, aber so wirklich dauerhaft ist das nicht. Das Modul blacklisten ist da viel sicherer.

[mullers]

Naja, aber so wirklich dauerhaft ist das nicht. Das Modul blacklisten ist da viel sicherer.

Nein, dauerhaft ist es nicht, jedenfalls nur bis zum nächsten
Kernel. Aber blacklisten hat eben auch nicht immer zuverlässig
funktioniert...
In diesem Fall hilft es natürlich auch nichts, ein Modul, das
gar nicht mehr da ist, auf die blacklst zu setzen.

[TRex]

Wenn es nicht funktioniert, dann liegt das in der Regel daran, dass das Modul in der initrd geladen wird. Es sollte helfen, die initrd neuzubauen.

[mullers]

Wenn es nicht funktioniert, dann liegt das in der Regel daran, dass das Modul in der initrd geladen wird. Es sollte helfen, die initrd neuzubauen.

Mmh, so eine Arbeit nur um einen beep loszuwerden, der
anfänglich überhaupt nicht da sein sollte (als Standard)?

[TRex]

Code: Alles auswählen

 sudo update-initramfs -u -k all

halte ich nicht für einen riesigen Aufwand

[mullers]

Code: Alles auswählen

 sudo update-initramfs -u -k all

halte ich nicht für einen riesigen Aufwand

Na, wenn Du es so siehst, wer will Dir da widersprechen
Ich dachte, ich müsste den Kernel neu bauen...

[mullers]

Jetzt ist dieser beep wieder da...

Was bisher geschah:
In den jeweiligen Verzeichnissen:

Code: Alles auswählen

rm pcspkr.ko
rm snd_pcsp.ko
depmod -a

Dann:

Code: Alles auswählen

sudo update-initramfs -u -k all

Und trotzdem ist dieser dämliche beep wieder da. Allerdings
war er eine zetilang verschwunden...

Mmh, gibt es eigentlich auch ein Verzweiflungssmiley?

[mullers]

Ich habe einen bug report geschrieben. Stand der Dinge
ist, dass diese zwei Zeilen (ich habe sie in /etc/rc.local gesetzt)
helfen:

Code: Alles auswählen

modprobe -r snd_hda_intel
modprobe snd_hda_intel beep_mode=0

[CH777]

Ich benutze da eine etwas radikalere Methode, die allerdings 100% zuverlässig ist: Einfach die Kabel vom Speaker abziehen bzw. durch knipsen und Ruhe ist

[Brancaleone]

Code: Alles auswählen

echo "blacklist pcspkr" >> /etc/modprobe.d/blacklist.conf

als root, hat bei mir immer Wunder gewirkt. Schon war Ruhe im Kasten ....

[Teddybear]

Mhhhh... warum eigentlich soo umständlich??

Für die reine Konsole:

Code: Alles auswählen

setterm -blength 0 

in die bashrc und gut is, egal wer da das nervige etwas ausspuckt.
Fürs X sollte es ein

Code: Alles auswählen

xset b off

tun.

[mullers]

Wie schon eingangs erwähnt, funktioniert blacklist oder
`setterm`, bzw. `xterm`, eben nicht - in Worten:
NICHT - immer zuverlässig.

Was mich anbelangt ist die Sache gelöst, via bug report
(#620652), konnte diese Variante geklärt werden. Und was
irgendwie verlockend klingt, ist, dass der maintainer es
erwägt, den beep standardmäßig zu deaktivieren.

[Teddybear]

Wie schon eingangs erwähnt, funktioniert blacklist oder
`setterm`, bzw. `xterm`, eben nicht - in Worten:
NICHT - immer zuverlässig.

Was mich anbelangt ist die Sache gelöst, via bug report
(#620652), konnte diese Variante geklärt werden. Und was
irgendwie verlockend klingt, ist, dass der maintainer es
erwägt, den beep standardmäßig zu deaktivieren.

Naja.. also ich lese in dem Thread nirgendwo etwas von Versuchen dieser Art...
War ja auch nur mal so ein Einwurf.

[Brancaleone]

xterm & setterm haben mir nicht geholfen, weil mein altes Sarge & Etch penetrant beim Start von gdm gebeept hat - egal was da stand. Seit der blacklist hats Ruhe - und aus Gründen der Nostalgie BLACKLISTE ich dieses Modul bis heute. Außerdem brauch man den Speaker eh nicht - also bevor ihm wieder einfällt, die Klappe aufzumachen gibts eine drauf
[fieses Grinsen] huaaaaaahaaahaaahaaaaaaaaa [/fieses Grinsen]

[mullers]

Das Problem beim Eintrag in die blacklist ist halt, dass man
genau wissen muss, was man das eintragen muss.
Ich hatte das mal irgendwann gemacht und das Modul
`pcspkr` eingetragen. Dann kam irgendwann das Modul
``snd_pcsp` dazu. Das alles hätte bei dem neuen Kernel
auch nicht geholfen, denn jetzt kommt noch das Modul
`snd_hda_intel` dazu. Und das konnte ich nur durch den
Bug Report herausfinden. Man weiss, was man sich da
noch alles einfallen lässt...