Fedora: Phosh crasht wegen glib2 Patch

Liebe Linuxphone-Fans,

Ihr dürft mal wieder das Pinephone nicht Updaten, sonst knallts 🙁

Fedora: Phosh crasht wegen glib2 Patch

Dieser Stacktrace vom System zeigt exemplarisch das Problem:

Feb 10 21:31:02 fedorapine systemd-coredump[3835]: [🡕] Process 3144 (phosh) of user 1000 dumped core.
                                                   
                                                   Stack trace of thread 3144:
                                                   #0  0x0000007fa728b908 g_type_check_instance (libgobject-2.0.so.0 + 0x39908)
                                                   #1  0x0000007fa728026c g_signal_handlers_disconnect_matched (libgobject-2.0.so.0 + 0x2e26c)
                                                   #2  0x0000005587058218 mixer_control_output_update_cb (phosh + 0x58218)
                                                   #3  0x0000007fa7265948 g_closure_invoke (libgobject-2.0.so.0 + 0x13948)
                                                   #4  0x0000007fa729399c signal_emit_unlocked_R.isra.0 (libgobject-2.0.so.0 + 0x4199c)
                                                   #5  0x0000007fa7285e30 g_signal_emit_valist (libgobject-2.0.so.0 + 0x33e30)
                                                   #6  0x0000007fa72860e0 g_signal_emit (libgobject-2.0.so.0 + 0x340e0)
                                                   #7  0x0000005587084290 _pa_context_get_server_info_cb (phosh + 0x84290)
                                                   #8  0x0000007fa703fe58 context_get_server_info_callback (libpulse.so.0 + 0x12e58)
                                                   #9  0x0000007fa5a91bd0 run_action (libpulsecommon-14.2.so + 0x42bd0)
                                                   #10 0x0000007fa5a92564 pa_pdispatch_run (libpulsecommon-14.2.so + 0x43564)
                                                   #11 0x0000007fa7040170 pstream_packet_callback (libpulse.so.0 + 0x13170)
                                                   #12 0x0000007fa5a971e4 do_read (libpulsecommon-14.2.so + 0x481e4)
                                                   #13 0x0000007fa5a98b78 do_pstream_read_write (libpulsecommon-14.2.so + 0x49b78)
                                                   #14 0x0000007fa700e618 dispatch_func (libpulse-mainloop-glib.so.0 + 0x2618)
                                                   #15 0x0000007fa7157430 g_main_context_dispatch (libglib-2.0.so.0 + 0x57430)
                                                   #16 0x0000007fa71ae570 g_main_context_iterate.constprop.0 (libglib-2.0.so.0 + 0xae570)
                                                   #17 0x0000007fa7156af0 g_main_loop_run (libglib-2.0.so.0 + 0x56af0)
                                                   #18 0x0000007fa7a2b604 gtk_main (libgtk-3.so.0 + 0x26d604)
                                                   #19 0x000000558701f7c4 main (phosh + 0x1f7c4)
                                                   #20 0x0000007fa6981a9c __libc_start_main (libc.so.6 + 0x24a9c)
                                                   #21 0x000000558701fa78 _start (phosh + 0x1fa78)
                                                   
                                                   Stack trace of thread 3145:
                                                   #0  0x0000007fa6a2dfb0 __poll (libc.so.6 + 0xd0fb0)
                                                   #1  0x0000007fa71ae50c g_main_context_iterate.constprop.0 (libglib-2.0.so.0 + 0xae50c)
                                                   #2  0x0000007fa71548ec g_main_context_iteration (libglib-2.0.so.0 + 0x548ec)
                                                   #3  0x0000007fa7154954 glib_worker_main (libglib-2.0.so.0 + 0x54954)
                                                   #4  0x0000007fa7187a78 g_thread_proxy (libglib-2.0.so.0 + 0x87a78)
                                                   #5  0x0000007fa68defd8 start_thread (libpthread.so.0 + 0x7fd8)
                                                   #6  0x0000007fa6a3835c thread_start (libc.so.6 + 0xdb35c)
                                                   
                                                   Stack trace of thread 3147:
                                                   #0  0x0000007fa6a2dfb0 __poll (libc.so.6 + 0xd0fb0)
                                                   #1  0x0000007fa71ae50c g_main_context_iterate.constprop.0 (libglib-2.0.so.0 + 0xae50c)
                                                   #2  0x0000007fa7156af0 g_main_loop_run (libglib-2.0.so.0 + 0x56af0)
                                                   #3  0x0000007fa73eb7b8 gdbus_shared_thread_func.lto_priv.0 (libgio-2.0.so.0 + 0x1277b8)
                                                   #4  0x0000007fa7187a78 g_thread_proxy (libglib-2.0.so.0 + 0x87a78)
                                                   #5  0x0000007fa68defd8 start_thread (libpthread.so.0 + 0x7fd8)
                                                   #6  0x0000007fa6a3835c thread_start (libc.so.6 + 0xdb35c)
                                                   
                                                   Stack trace of thread 3148:
                                                   #0  0x0000007fa6a2dfb0 __poll (libc.so.6 + 0xd0fb0)
                                                   #1  0x0000007fa71ae50c g_main_context_iterate.constprop.0 (libglib-2.0.so.0 + 0xae50c)
                                                   #2  0x0000007fa71548ec g_main_context_iteration (libglib-2.0.so.0 + 0x548ec)
                                                   #3  0x0000007fa40fdd4c dconf_gdbus_worker_thread (libdconfsettings.so + 0x5d4c)
                                                   #4  0x0000007fa7187a78 g_thread_proxy (libglib-2.0.so.0 + 0x87a78)
                                                   #5  0x0000007fa68defd8 start_thread (libpthread.so.0 + 0x7fd8)
                                                   #6  0x0000007fa6a3835c thread_start (libc.so.6 + 0xdb35c)

Phosh semmelt hier brutal weg, wenn man an den Audioeinstellungen rumspielt. Verursacht wird dies mutmaßlich durch einen Patch der Glib2:

* Tue Feb 09 2021 Benjamin Berg <bberg@redhat.com> – 2.67.3-2
  – Add patches to move applications into systemd scopes

Ich sage mutmaßlich, weil ein Downgrade des Glib2 Paketes auf 2.67.1-4 das Problem sofort behebt. Es kann aber natürlich auch sein, daß einfach alle anderen Anwendungen und Libs noch nichts von dem Patch gehört haben und noch Code verwenden, der dann nicht mehr geht.

Das blöde an der Situation ist, daß sich die Pulseaudio-Einstellungen beim Einstecken von Kopfhörern und Telefonieren ändern, weswegen Phosh während eines Anrufs crasht und das Gespräch weiterläuft. Kein Desktop bedeutet aber auch, keine Kontrolle mehr über den Anruf.

Wäre ich zynisch drauf, würde ich eine CVE beantragen, weil man durch Anrufen einen DOS auslösen kann 🙂

Workaround:

Für normale Endanwender:

dnf downgrade https://kojipkgs.fedoraproject.org//packages/glib2/2.67.1/4.fc34/aarch64/glib2-2.67.1-4.fc34.aarch64.rpm

Für normale Entwickler, die auch das Devel Paket installiert haben, weil sie Software auf dem System kompilieren:

dnf downgrade https://kojipkgs.fedoraproject.org//packages/glib2/2.67.1/4.fc34/aarch64/glib2-2.67.1-4.fc34.aarch64.rpm https://kojipkgs.fedoraproject.org//packages/glib2/2.67.1/4.fc34/aarch64/glib2-devel-2.67.1-4.fc34.aarch64.rpm

Danach „systemctl restart phosh“ durchführen und Ihr seid wieder crashsicher.

Update:

Der Bug wird untersucht. Jede Menge Debugging und 1.2GB Debugpakete später, steht nur eins fest: Der Bug ist mehr als bescheiden zu debuggen!

Kernel 5.7.8+ Problem entdeckt

Es ist mal wieder soweit, ein fieses Kernelproblem wurde entdeckt. Ja ok, passiert dauernd, aber meisten sind nicht alle davon betroffen, hier schon, da es ein Speicherzugriffsfehler ist.

Kernel 5.7.8+ Problem entdeckt

In den letzten zwei Tagen sind zwei verschiedene Computer mit dem gleichen Fehlerbild stehen geblieben:

Aug 2 18:01:17 shortname kernel: BUG: unable to handle page fault for address: ffff8881e2e48630
Aug 2 18:01:17 shortname kernel: #PF: supervisor write access in kernel mode
Aug 2 18:01:18 shortname kernel: #PF: error_code(0x0003) – permissions violation

Der PC bleibt dabei nicht gleich stehen, sondern der Zugriff auf Strukturen im /proc Filesystem ( procfs ) friert einfach ein. Als Resultat bleiben Programme wie „top“ oder „pidof“ stecken. Das ist besonders blöd, weil „pidof“ beim Startprozess eines Terminals für die Bash mitmischt und man so keins mehr starten kann.

Ich hatte erst gedacht, daß wäre ein VM Problem, weil es zunächst im Servercluster aufgetreten ist, aber da es jetzt auch bare-metal auf einem Desktop-PC passiert ist, was es Zeit Alarm zu schlagen.

Wer Kernel 5.7.8 einsetzt kann sich derzeit nicht sicher sein, daß der PC durchläuft. Bei mit lag der Ausfallzeitpunkt bei knappen 15 Stunden Betriebszeit für bare-metal und ~2 Wochen für eine VM in der heute das gleiche passiert ist. Da das Problem frisch entdeckt wurde, gibt es noch keine Reaktion vom Kernel Team. Ich kann aber nur dazu raten einen anderen Kernel lauf zu lassen.

Wenn Ihr das Problem rechtzeitig bemerkt, könnt Ihr noch über die Desktop-Systemüberwachung in die Prozessliste und die „pidof“ Prozesse abbrechen, die das Starten eines Terminals verhindern. Danach kommt die Bash i.d.r. sauber hoch und Ihr könnt Reboot eingeben. Ein „systemctl reboot -i“ wird nötig sein, da der normale Reboot, zumindest bei mir, verweigert wurde.

Hier für Euch die ganze Kernelmeldung für Vergleichszwecke:

Aug 2 18:01:17 shortname kernel: BUG: unable to handle page fault for address: ffff8881e2e48630
Aug 2 18:01:17 shortname kernel: #PF: supervisor write access in kernel mode
Aug 2 18:01:18 shortname kernel: #PF: error_code(0x0003) – permissions violation
Aug 2 18:01:18 shortname kernel: PGD 2a0c067 P4D 2a0c067 PUD 3800067 PMD 1ffff2067 PTE 100001e2e48065
Aug 2 18:01:19 shortname kernel: Oops: 0003 [#3] SMP NOPTI
Aug 2 18:01:19 shortname kernel: CPU: 0 PID: 96 Comm: kswapd0 Tainted: G D W 5.7.8-100.fc31.x86_64 #1
Aug 2 18:01:19 shortname kernel: RIP: e030:ptep_clear_flush_young+0x1d/0x30
Aug 2 18:01:19 shortname kernel: Code: 48 0f ba 32 05 0f 92 c0 0f b6 c0 c3 90 0f 1f 44 00 00 48 8b 05 ec 74 40 01 48 25 00 f0 ff ff 48 f7 d0 48 23 02 83 e0 20 74 0c <f0> 48 0f ba 32 05 0f 92 c0 0f b6 c0 c3 66 0f 1f 44 00 00 0f 1f 44
Aug 2 18:01:19 shortname kernel: RSP: e02b:ffffc90001127a48 EFLAGS: 00010202
Aug 2 18:01:19 shortname kernel: RAX: 0000000000000020 RBX: ffff888101c64ed8 RCX: 0000000000000000
Aug 2 18:01:19 shortname kernel: RDX: ffff8881e2e48630 RSI: 00007fe123ac6000 RDI: ffff888101c64ed8
Aug 2 18:01:19 shortname kernel: RBP: ffffea00049c2e80 R08: 0000000000000101 R09: 0000000000000125
Aug 2 18:01:19 shortname kernel: R10: ffff8881f483e8d0 R11: ffffea0005ddc2a0 R12: ffffc90001127b08
Aug 2 18:01:19 shortname kernel: R13: 0000000000000000 R14: 00007fe123ac6000 R15: 0000000000000186
Aug 2 18:01:19 shortname kernel: FS: 00007f37db3a7700(0000) GS:ffff8881f5c00000(0000) knlGS:0000000000000000
Aug 2 18:01:19 shortname kernel: CS: e030 DS: 0000 ES: 0000 CR0: 0000000080050033
Aug 2 18:01:19 shortname kernel: CR2: ffff8881e2e48630 CR3: 0000000002a0a000 CR4: 0000000000040660
Aug 2 18:01:19 shortname kernel: Call Trace:
Aug 2 18:01:19 shortname kernel: page_referenced_one+0x59/0x150
Aug 2 18:01:19 shortname kernel: rmap_walk_file+0x157/0x2f0
Aug 2 18:01:19 shortname kernel: page_referenced+0xdb/0x150
Aug 2 18:01:19 shortname kernel: ? rmap_walk_file+0x2f0/0x2f0
Aug 2 18:01:19 shortname kernel: ? page_get_anon_vma+0x80/0x80
Aug 2 18:01:19 shortname kernel: shrink_active_list+0x2e5/0x560
Aug 2 18:01:19 shortname kernel: shrink_lruvec+0x3b9/0x6b0
Aug 2 18:01:19 shortname kernel: ? do_shrink_slab+0x52/0x2c0
Aug 2 18:01:19 shortname kernel: shrink_node+0x169/0x680
Aug 2 18:01:19 shortname kernel: balance_pgdat+0x2d9/0x5c0
Aug 2 18:01:19 shortname kernel: kswapd+0x1ed/0x3a0
Aug 2 18:01:19 shortname kernel: ? __schedule+0x2c2/0x730
Aug 2 18:01:19 shortname kernel: ? finish_wait+0x80/0x80
Aug 2 18:01:19 shortname kernel: kthread+0xf9/0x130
Aug 2 18:01:19 shortname kernel: ? balance_pgdat+0x5c0/0x5c0
Aug 2 18:01:19 shortname kernel: ? kthread_park+0x90/0x90
Aug 2 18:01:19 shortname kernel: ret_from_fork+0x35/0x40
Aug 2 18:01:19 shortname kernel: Modules linked in: fuse btrfs blake2b_generic xor raid6_pq hfsplus hfs minix vfat msdos fat jfs xfs nfsv3 nfs_acl nfs lockd grace fscache xt_owner ipt_REJECT nf_reject_ipv4 xt_connlimit nf_conncount nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c xt_multiport ip6table_filter ip6_tables cls_u32 sch_htb iptable_filter intel_rapl_msr intel_rapl_common cfg80211 sb_edac x86_pkg_temp_thermal coretemp crct10dif_pclmul rfkill crc32_pclmul ghash_clmulni_intel intel_rapl_perf sunrpc ip_tables xen_netfront xen_blkfront crc32c_intel
Aug 2 18:01:19 shortname kernel: CR2: ffff8881e2e48630
Aug 2 18:01:19 shortname kernel: —[ end trace 7fb962ee698fa150 ]—
Aug 2 18:01:19 shortname kernel: RIP: e030:unmap_page_range+0x631/0xec0
Aug 2 18:01:19 shortname kernel: Code: fe e8 03 f8 ff ff 48 83 7c 24 18 00 48 89 c3 74 09 48 85 c0 0f 85 c0 05 00 00 41 f6 44 24 20 01 0f 84 25 03 00 00 4c 8b 6d 00 <48> c7 45 00 00 00 00 00 4d 39 7c 24 10 4c 89 f8 49 0f 46 44 24 10
Aug 2 18:01:19 shortname kernel: RSP: e02b:ffffc90002a2bb38 EFLAGS: 00010202
Aug 2 18:01:19 shortname kernel: RAX: ffffea0001b72500 RBX: ffffea0001b72500 RCX: 0000000000000125
Aug 2 18:01:19 shortname kernel: RDX: 0000000000000000 RSI: 00005589f49e7000 RDI: 000000083aa94125
Aug 2 18:01:19 shortname kernel: RBP: ffff8881e3d90f38 R08: ffff88810011e320 R09: 0000000000000000
Aug 2 18:01:19 shortname kernel: R10: 0000000000007ff0 R11: 0000000000000000 R12: ffffc90002a2bc80
Aug 2 18:01:19 shortname kernel: R13: 000000083aa94125 R14: 00005589f49e8000 R15: 00005589f49e7000
Aug 2 18:01:19 shortname kernel: FS: 00007f37db3a7700(0000) GS:ffff8881f5c00000(0000) knlGS:0000000000000000
Aug 2 18:01:19 shortname kernel: CS: e030 DS: 0000 ES: 0000 CR0: 0000000080050033
Aug 2 18:01:19 shortname kernel: CR2: ffff8881e2e48630 CR3: 0000000002a0a000 CR4: 0000000000040660

 

Nvidia, Fedora, RPMFusion und der Bug, der nicht sein soll.

Diese Geschichte fängt an mit: „Es war einmal eine Grafikkarte“.

„Nvidia, Fedora, RPMFusion und der Bug, der nicht sein soll“

Wie Ihr wisst, gibt es von Nvidiatreibern verschiedene Versionsnummern, z.b. 340,390,440. 440 ist der aktuelle Treiber für GTX1050 Karten.

Jetzt wirft dieser Treiber beim Systemboot eine Fehlermeldung wie folgt:

[ 222.363327] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[ 222.363328] [drm] No driver support for vblank timestamp query.
[ 222.397236] [drm] Initialized nvidia-drm 0.0.0 20160202 for 0000:05:00.0 on minor 0
[ 222.406533] ————[ cut here ]————
[ 222.406534] refcount_t: underflow; use-after-free.
[ 222.406550] WARNING: CPU: 1 PID: 513 at lib/refcount.c:28 refcount_warn_saturate+0xa6/0xf0
[ 222.406551] Modules linked in: nvidia_drm(POE) nvidia_modeset(POE) nvidia_uvm(OE) snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio snd_hda_intel nvidia(POE) snd_intel_dspcfg snd_hda_codec snd_hda_core snd_hwdep joydev snd_seq snd_seq_device edac_mce_amd drm_kms_helper snd_pcm kvm_amd snd_timer drm snd kvm ipmi_devintf sp5100_tco irqbypass wmi_bmof ipmi_msghandler k10temp i2c_piix4 soundcore pcspkr gpio_amdpt gpio_generic acpi_cpufreq nfsd binfmt_misc auth_rpcgss nfs_acl lockd grace sunrpc ip_tables dm_crypt hid_logitech_hidpp crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel ccp r8169 aacraid hid_logitech_dj wmi pinctrl_amd fuse
[ 222.406576] CPU: 1 PID: 513 Comm: plymouthd Tainted: P OE 5.5.10-200.fc31.x86_64 #1
[ 222.406577] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./B450M Pro4, BIOS P3.90 12/09/2019
[ 222.406579] RIP: 0010:refcount_warn_saturate+0xa6/0xf0
[ 222.406581] Code: 05 2e 03 2e 01 01 e8 7b 8e bc ff 0f 0b c3 80 3d 1c 03 2e 01 00 75 95 48 c7 c7 18 99 3c 9d c6 05 0c 03 2e 01 01 e8 5c 8e bc ff <0f> 0b c3 80 3d fb 02 2e 01 00 0f 85 72 ff ff ff 48 c7 c7 70 99 3c
[ 222.406582] RSP: 0018:ffffb573c103fcb8 EFLAGS: 00010286
[ 222.406583] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000007
[ 222.406584] RDX: 0000000000000007 RSI: 0000000000000086 RDI: ffff9416ce859cc0
[ 222.406585] RBP: ffff9416bacbfce8 R08: 0000000000000413 R09: 0000000000000003
[ 222.406585] R10: 0000000000000000 R11: 0000000000000001 R12: ffff9416c70502e8
[ 222.406586] R13: ffff9416c7050000 R14: 0000000000000008 R15: 0000000000000000
[ 222.406588] FS: 00007f07558f3f00(0000) GS:ffff9416ce840000(0000) knlGS:0000000000000000
[ 222.406588] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 222.406589] CR2: 00007f0755072052 CR3: 00000004035c6000 CR4: 0000000000340ee0
[ 222.406590] Call Trace:
[ 222.406597] nv_drm_atomic_helper_disable_all+0xec/0x290 [nvidia_drm]
[ 222.406603] nv_drm_master_drop+0x22/0x60 [nvidia_drm]
[ 222.406616] drm_drop_master+0x1e/0x30 [drm]
[ 222.406628] drm_dropmaster_ioctl+0x4c/0x90 [drm]
[ 222.406639] ? drm_setmaster_ioctl+0xb0/0xb0 [drm]
[ 222.406651] drm_ioctl_kernel+0xaa/0xf0 [drm]
[ 222.406663] drm_ioctl+0x208/0x390 [drm]
[ 222.406675] ? drm_setmaster_ioctl+0xb0/0xb0 [drm]
[ 222.406678] ? do_filp_open+0xa5/0x100
[ 222.406681] ? selinux_file_ioctl+0x174/0x220
[ 222.406683] do_vfs_ioctl+0x461/0x6d0
[ 222.406685] ksys_ioctl+0x5e/0x90
[ 222.406686] __x64_sys_ioctl+0x16/0x20
[ 222.406690] do_syscall_64+0x5b/0x1c0
[ 222.406693] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 222.406695] RIP: 0033:0x7f0755bb138b
[ 222.406697] Code: 0f 1e fa 48 8b 05 fd 9a 0c 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d cd 9a 0c 00 f7 d8 64 89 01 48
[ 222.406697] RSP: 002b:00007ffced5fe798 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
[ 222.406699] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f0755bb138b
[ 222.406699] RDX: 0000000000000000 RSI: 000000000000641f RDI: 0000000000000009
[ 222.406700] RBP: 000000000000641f R08: 000055b6a6ff1df0 R09: 000055b6a6fa5010
[ 222.406701] R10: 0000000000000000 R11: 0000000000000246 R12: 000055b6a6ff2970
[ 222.406701] R13: 0000000000000009 R14: 0000000000000000 R15: 0000000000000000
[ 222.406703] —[ end trace fa45bb73ed0780f4 ]—
[ 222.411358] kauditd_printk_skb: 45 callbacks suppressed

Von Euch sieht natürlich jeder sofort, daß hier NVIDIA und PLYMOUTH im Spiel sind und das der Nvidiatreiber einen Fehler bei der DRM Initialisierung verursacht. Der Server bootet danach weiter, also erstmal nicht so wichtig. Es folgen die üblichen Dinge: Bugreport bei Fedora ( wegen Plymouth ) und bei RPMFusion ( wegen Nvidia ) erstellen, und komplett entäuscht werden… !

„Da ist kein Bug, gehen Sie weiter!“

Nun kann Fedora da nicht viel machen, wenn der Nvidiatreiber da Mist baut, außer natürlich, es übergibt dem Treiber schon was falsches, da könnte der Treiber dann nicht mehr soviel für den Bug. Das werden wir aber nie erfahren, denn der Bug wurde sofort beerdigt. Nagut, wir haben ja noch den RPMFusionreport.

Sagte ich, wir haben noch einen anderen offenen Bugreport? So kann man sich irren: „Your Bugreport has been closed with „WONT FIX“.Und dann stehen wir mit einem Fehler da, von dem alle Parteien sagen „Nicht mein Problem“. Doch, Eurer Problem! Wessen denn sonst?

Der Bug wurde in der Devliste von Nvidia zwar besprochen, aber es gibt leider keinen finalen Fix dafür:

Devliste: https://forums.developer.nvidia.com/t/bug-nvidia-440-64-kernel-5-5-6-stable-boot-trace-was-nvidia-440-59-kernel-5-5-1-stable-boot-trace/111643

Der derzeitige Stand ist: Geht halt nicht; und DRM geht dann halt auch nicht. Wobei letzteres sollte man eh abschaffen, falls damit das DigitalRightsManagement gemeint ist.

Was mich aber am meisten stört: „ist nicht unser Problem“. Von RPMFusion hätte ich erwartet, daß das offen bleibt, bis das von den Nvidiadevs gefixt wurde, schon um das Problem zu tracken, aber von Scott kann man halt oft nichts anderes erwarten.