Schon vor einigen Versionen konnte man die Spins von Fedora auf getfedora.org nicht mehr so leicht finden. Falls Ihr die mal sucht, und da sind einige interessante dabei, dann probiert es doch mal hier:
Category Archives: Fedora
Fedora 30 Firefoxupdate 74.0.1 verfügbar
Mit dem Security-Update von Firefox auf 74.0.1 gab es eine Probleme beim Bau des Paketes, die konnten heute endlich ausgeräumt werden.
Fedora 30 Firefoxupdate 74.0.1 verfügbar
Wer sich gleich das Update saugen möchte, weil er/sie/es zu recht nicht mehr warten kann, der kann dies hier tun:
Die FC31/32/33 Version davon ist bereits im Stable gepusht worden, so daß Ihr diese bereits habt. Was da das Problem war, wurde leider nicht mitgeteilt.
Installiert bekommt man das Update so :
sudo dnf update ./firefox-74.0.1-3.fc30.x86_64.rpm
wenn Ihr im gleichen Verzeichnis wie Eure Downloaddatei seid 😉
Linux: 190GB RAM erwünscht ..
Da heißt es immer, Linux wäre so Ressourcenschonend .. mu har har har..auf dem Papier, ok 🙂
190 GB RAM erwünscht
Vorhin glitschte bei mir kurz die TOP Anzeige durch, da fielen mir folgende Angaben auf:
3294 marius 20 0 9,9g 1,0g 53144 S 0,7 6,7 2:18.47 java
2767 marius 20 0 3658568 703720 157848 S 1,3 4,3 8:02.93 thunderbird
4718 marius 20 0 3611796 622464 245956 R 2,7 3,8 41:28.36 firefox
3061 marius 20 0 5029712 561352 140764 S 0,3 3,4 36:38.85 skypeforlinux
2636 marius 20 0 1404048 516784 55476 S 0,0 3,2 0:48.15 gnome-software
2577 marius 20 0 3878152 293020 103852 S 0,0 1,8 8:53.58 cinnamon
6285 marius 20 0 2848784 275648 178572 S 0,0 1,7 1:06.03 Web Content
1713 gdm 20 0 2882496 222756 105604 S 0,0 1,4 0:11.92 gnome-shell
4961 marius 20 0 2721516 222324 147568 S 0,3 1,4 1:35.18 Web Content
2601 marius 20 0 98,4g 201364 73168 S 0,0 1,2 0:22.12 liferea
9771 marius 20 0 2612880 192700 127616 S 0,0 1,2 0:23.12 Web Content
10910 marius 20 0 2607960 187556 129964 S 3,3 1,1 0:19.45 Web Content
4900 marius 20 0 2627124 185064 106852 S 0,0 1,1 1:11.14 WebExtensions
2998 marius 20 0 935120 177228 90376 S 0,0 1,1 1:38.35 skypeforlinux
11932 marius 20 0 2581276 174744 129216 S 0,0 1,1 0:13.21 Web Content
4833 marius 20 0 2688600 172948 117520 S 0,0 1,1 1:31.50 Web Content
2603 marius 20 0 2899340 167280 99908 S 0,3 1,0 1:18.97 skypeforlinux
2090 root 20 0 431540 157632 127032 S 0,3 1,0 10:22.48 Xorg
2418 marius 9 -11 2493616 104560 16004 S 1,3 0,6 25:37.16 pulseaudio
3151 marius 20 0 82,4g 98896 77908 S 2,7 0,6 8:23.59 WebKitWebProces
rechnet man das zusammen, gehen alleine diese drei Prozesse davon aus, daß sie zusammen 190GB brauchen werden. Tun sie natürlich nicht 🙂 Zum Glück, weil das Mainboard nur maximal 32 GB könnte 😉
Wieder „Zum Glück“ sind dies nur die virtuelle Speicherblöcke. Denkbar wäre allerdings, daß ein manipulierter RSS Server, Liferea erkennt und einfach GBweise RSS Daten an den Prozess schickt, bis das System zu Tode geswappt wurde.
Für Liferea schauen wir mal in die pmem Tabelle rein:
15655: /usr/bin/liferea –gapplication-service
000055cbe8e92000 112K r—- liferea
000055cbe8eae000 284K r-x– liferea
000055cbe8ef5000 144K r—- liferea
000055cbe8f1a000 16K r—- liferea
000055cbe8f1e000 4K rw— liferea
000055cbe8f1f000 4K rw— [ anon ]
000055cbe99bf000 110760K rw— [ anon ]
00007f8800000000 33554432K rw— [ anon ]
00007f9000000000 33554432K —– [ anon ]
00007f9800000000 16777216K rw— [ anon ]
00007fa23c000000 132K rw— [ anon ]
… 2 Kilometer mehr an Speicherblöcken entfernt..
33G+33G+16G = 82G
Die rechtlichen 16 GB möchte er dann doch für den „Rest“ verbraucht wissen .. naja.. Ich geh mal davon aus, daß der Entwickler K mit M verwechselt hat und eigentlich 100 MB Ram haben wollte, was für LifeRea auch 99M zuviel gewesen wären 😉 Ich erwähne das eigentlich nur, weil das nicht erst seit gestern so ist: I wish
Wieso allerdings der WebKit Prozess da auch 82.4GB Ram haben wollte, entzieht sich mir jetzt. Die anderen WebKitProzesse waren mit viel weniger zufrieden.
Linux-Games: Ortho Robot
Was man so alles beim Durchsehen von Updatemeldungen findet:
OrthoRobot
Nicht mehr das jüngste Game, aber mal was völlig anderes als nur Ballergames. Das Spiel schliesst die Lücke zwischen 2D und 3D, in dem man buchstäblich die 3D Welt auf 2D falten muß um durchzukommen.
Schnell muß man nicht sein, da es kein Zeitlimit gibt. Ihr könnt also im Prinzip stressfrei spielen und knobeln. Hier ein paar Impressionen:
Viel Spaß dabei.
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:
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.