Beiträge von Eldrad Ulthran

Hab einen Bug-Report erstellt und prompt eine Lösung erhalten:

amixer -c0 set Beep mute

Diesen Kanal hat nicht jeder PC, mein Heimrechner beispielsweise nicht – daher wird wohl auch nicht jeder Nutzer davon betroffen sein.

Zitat von Alero

Sind die anderen auch Lenovos?

Nein, das eine ist mein Arbeitsplatzrechner der Marke Dell, das andere mein selbst zusammengebauter Heimrechner.

Zitat von Alero

Dann ist mir das schleierhaft. Das Problem kenne ich überhaupt nicht. Kann dann höchstens noch eine Lenovo-Macke sein. Oder du legst mal auf doof einen neuen User an und schaust mal, ob es da auch so ist. Ist es da auch so, ist es eine Lenovo-Geschichte. Ist es da weg, hast du was verstellt. Probier es aus.

Ein neuer Nutzer hat's leider auch nicht gebracht…

Das Piepen kam mit irgendeinem TW-Update auf: Ich hab insgesamt 3 PCs mit Tumbleweed, und alle drei haben in etwa zeitgleich angefangen zu piepen. Bei den beiden Stand-PCs hat das blacklisten von pcspkr die Erlösung gebracht, aber hier beim Laptop wird kurioserweise auf die Lautsprecher umgeleitet…

Die Benachrichtigungsklänge sind bereits auf 0 und stummgeschaltet. :-/

Guten Morgen,

mein Laptop gibt jedes Mal, wenn ich auf "Herunterfahren" klicke, einen Piepton von sich, der mich ziemlich nervt und den ich gerne ausschalten würde. Zum Thema "disable poweroff beep" gibt es zahlreiche Treffer auf google, die aber alle darauf hinauslaufen, blacklist pcspkr in /etc/modprobe.d/50-blacklist.conf einzufügen. Genau das habe ich gemacht, aber jetzt kommt der Piepton aus den Stereo-Lautsprechern des Laptops.
D.h. wenn ich die Soundausgabe in pulseaudio stummschalte, verstummt auch das Piepen. Ich muss daher jedes Mal vorm Runterfahren daran denken, alles zu muten, und wunder mich entsprechend beim nächsten Mal, warum ein abgespieltes Video keinen Ton hat... Wie kann ich das Piepen aber nachhaltig ausschalten?

Zum System: Es ist ein Lenovo ThinkPad 20H2-S00700, mit Tumbleweed/Plasma drauf.

uname -a
Linux maxim-lt 6.0.2-1-default #1 SMP PREEMPT_DYNAMIC Sun Oct 16 07:53:17 UTC 2022 (7fb6561) x86_64 x86_64 x86_64 GNU/Linux

Zitat von Alero

Scheint komplizierter zu sein als vorher angenommen. Da hilft wohl nur, die Datei zu sichern und nach jedem Update wieder zurück zu kopieren. Aber das Sperr-Bit wirkt.

In der Hoffnung, dass sich am Rest der Datei nichts ändert, ja, ansonsten müsste ich mir ein bash-Skript überlegen, das meinen Textblock an der richtigen Stelle einfügt…

Ich weiß zwar nicht genau, was während des Updates passiert, aber könnte es sein, dass das Verzeichnis komplett gelöscht wird, und danach die neuen Dateien dort reingepackt werden? In ../symbols sind ja eig. mehr als 100 Dateien drin, nach dem misslungenen Update war aber nur noch die gesperrte Datei ru vorhanden. Vor dem Entpacken wird getestet, ob das Verzeichnis wirklich leer ist, und weil es das nicht war, wurde abgebrochen (so interpretiere ich zumindest die Fehlermeldung beim Update?).

Kann man in Yast einzelne Dateien sperren? Ich dachte, das könnte man nur auf Pakete anwenden? Man könnte zwar xkeyboard-config sperren, aber ich glaube, das würde einen fiesen Rattenschwanz nach sich ziehen:

zypper se --requires xkeyboard-config
Loading repository data...
Reading installed packages...

S | Name                       | Summary                                             | Type
--+----------------------------+-----------------------------------------------------+--------
  | libgnome-desktop-3-devel   | Development files for the GNOME Desktop API library | package
i | libxkbcommon0              | Library for handling xkb descriptions               | package
i | libxkbfile1                | X11 keyboard file manipulation library              | package
i | patterns-base-x11_enhanced | X Window System                                     | package
  | weston                     | Wayland Reference Compositor                        | package
i | xf86-input-keyboard        | Keyboard input driver for the Xorg X server         | package
i | xkeyboard-config-lang      | Translations for package xkeyboard-config           | package
i | xorg-x11-Xvnc              | TigerVNC implementation of Xvnc                     | package
i | xorg-x11-server            | X                                                   | package
i | xorg-x11-server-Xvfb       | Virtual Xserver Xvfb                                | package
i | xorg-x11-server-extra      | Additional Xservers Xephyr, Xnest)                  | package

Würde ich das sperren, würde ich vermutlich auch keine Updates mehr für den X-Server installieren können, was auch nicht sinnvoll sein kann…

Leider hat das Ignorieren dazu geführt, dass der X-Server nachm Reboot nicht mehr starten kann, hier ein Auszug aus Xorg.0.log:

[    46.780] (EE) Error compiling keymap (server-0) executing '"/usr/bin/xkbcomp" -w 1 "-R/usr/share/X11/xkb" -xkm "-" -em1 "The XKEYBOARD keymap compiler (xkbcomp) reports:" -emp "> " -eml "Errors from xkbcomp are not fatal to the X server" "/var/lib/xkb/compiled/server-0.xkm"'
[    46.780] (EE) XKB: Couldn't compile keymap
[    46.780] (EE) XKB: Failed to load keymap. Loading default keymap instead.
[    46.785] (EE) Error compiling keymap (server-0) executing '"/usr/bin/xkbcomp" -w 1 "-R/usr/share/X11/xkb" -xkm "-" -em1 "The XKEYBOARD keymap compiler (xkbcomp) reports:" -emp "> " -eml "Errors from xkbcomp are not fatal to the X server" "/var/lib/xkb/compiled/server-0.xkm"'
[    46.785] (EE) XKB: Couldn't compile keymap
[    46.785] XKB: Failed to compile keymap
[    46.785] Keyboard initialization failed. This could be a missing or incorrect setup of xkeyboard-config.
[    46.785] (EE) 
Fatal server error:
[    46.785] (EE) Failed to activate virtual core keyboard: 2(EE) 
[    46.785] (EE) 
Please consult the The X.Org Foundation support 
         at http://wiki.x.org
 for help. 
[    46.785] (EE) Please also check the log file at "/var/log/Xorg.0.log" for additional information.
[    46.785] (EE) 
[    46.786] (II) AIGLX: Suspending AIGLX clients for VT switch
[    46.827] (EE) Server terminated with error (1). Closing log file.

Ich hatte gesehen, dass im Ordner /usr/share/X11/xkb/symbols/ einzig die Datei ru und in .../rules nur die Dateien base*, evdev und README übrig geblieben waren, sonst nichts. War wohl doch nicht so gesund, das Update zu ignorieren… Habe jetzt erstmal das i von beiden Dateien entfernt und das Update normal installieren lassen, um eine funktionierende Oberfläche zu haben.

Irgendeine Idee, was ich stattdessen tun kann?

Nachtrag: Wie nicht ganz unerwartet, hat das nächste Update sich beschwert:

error: unpacking of archive failed on file /usr/share/X11/xkb/rules/base.xml;6218c741: cpio: rename failed - Directory not empty
error: xkeyboard-config-2.34-2.1.noarch: install failed
error: xkeyboard-config-2.34-1.2.noarch: erase skipped
( 4539/10589) Installieren: xkeyboard-config-2.34-2.1.noarch ...............................................................[Fehler]
Installation von xkeyboard-config-2.34-2.1.noarch fehlgeschlagen:
Fehler: Subprocess failed. Error: RPM fehlgeschlagen: Kommando mit Status 1 beendet.                                                 
Abbrechen, wiederholen, ignorieren? [a/w/i] (a): i

Ich habe das erstmal ignoriert, damit der Rest des Updates durchläuft. Was ist eure Einschätzung, soll ich mir Sorgen machen, etwas am Schutz der Datei ändern, oder kann ich auch in Zukunft dieses Paketupdate ignorieren?

Wieder was neues gelernt, dankeschön!

(weil evdev.xml ein Link auf base.xml ist, musste ich entsprechend chattr +i /usr/share/X11/xkb/rules/base.xml setzen)