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.

Schlechte Nachrichten für Pioneer Fans

Mein Morgen war jetzt nicht ganz so super, wie er hätte sein können. Im Updatebericht von Fedora habe ich gesehen, das die neue Version von Pioneer verfügbar gemacht wurde und wollte das natürlich sofort austesten.

Alte Spielstände führen zum Absturz

Weil die Spielstandsdatei angeblich eine falsche Versionsnummer hat, konnte die nicht geladen werden. Der Bugreport bei Pioneer wird uns hoffentlich offenbaren, wieso es eine „falsche“ Versionsnummer geben kann.

Wenn Ihr wissen wollt, ob Eurer Fehler beim Start auch daran liegt, müßt Ihr Pioneer in einem Terminal starten:

Game::LoadGame(‚_exit‘)
Loading saved game ‚_exit‘ failed: wrong save file version.
error: [string „[T] @pigui/views/mainmenu.lua“]:138: This saved game cannot be loaded because it contains errors.
stack traceback:
[C]: in function ‚LoadGame‘
[string „[T] @pigui/views/mainmenu.lua“]:138: in function ‚callback‘
[string „[T] @pigui/views/mainmenu.lua“]:92: in function ‚mainTextButton‘
[string „[T] @pigui/views/mainmenu.lua“]:215: in function ‚fun‘
[string „[T] @pigui/pigui.lua“]:97: in function ‚window‘
[string „[T] @pigui/views/mainmenu.lua“]:214: in function ‚fun‘
[string „[T] @pigui/pigui.lua“]:146: in function ‚withStyleColors‘
[string „[T] @pigui/views/mainmenu.lua“]:213: in function ’showMainMenu‘
[string „[T] @pigui/views/mainmenu.lua“]:260: in function ‚mainMenu‘
[string „[T] @pigui/pigui.lua“]:187: in function <[string „[T] @pigui/pigui.lua“]:185>

Denn leider wird das nicht in dem GUI Hinweis zum Absturz angegeben, was die Bugreports bei Pioneer in Github regelmäßig zum „Starts mal in der Konsole“ zwingt.  Macht das am besten immer, wenn Ihr bei Pioneer auf ein Problem stoßt, da spart eine Menge Zeit für alle ein 😉

Fedora 28: Planet Crash

Mit Fedora 28 ist es grade, als wenn man in einen Topf Farbe getreten ist und jetzt die Farbe überall verteilt. Egal wo man hinschaut Bugs, Bugs und noch mehr Bugs.

Heute:  ProjectM-PulseAudio

Für alle die ProjectM nicht kennen, das ist ein Audio-Visualisierungs-Plugin, das langweilige Musikabende optisch aufhübschen soll, idealerweise im Takt der Musik.

Scheinbar ist das bei Fedora auf dem absteigenden Ast gelandet, meint, es ist als verweist markiert. Es gibt also keinen Maintainer und Redhat muß selbst ran, und genau da haperts bei Redhat grade. Das Problem liegt in der Speicherverwaltung, was zu einem „Double Free“ Fehler führt. Für Nichtentwickler, daß bedeutet, daß ein Speicherbereich zwei(++)mal freigegeben werden soll. Das ist ein schwerwiegender Programmierfehler und wird besonders oft von C-Entwicklern gemacht, weil das Speichermanagement von C schlicht nicht vorhanden ist. Einem Java-Programm kann das nicht passieren, da die JVM das Speichermanagement komplett übernimmt.

Ich wette Fefe, wüßte jetzt, auf welchem Platz der häufigsten Programmierfehler in C der DoubleFree steht, aber ich kann nur raten. Gefühlt in den Top 3, direkt nach Buffer-Overflow und „Zeiger auf Zeiger verdengelt“ 🙂

Also falls Ihr mit ProjectM rechnet, seid nicht enttäuscht, wenn es nach 5 Sekunden crasht.

Update:

Nachdem ich mit auf Github einen BugReport erstellt habe, stellt sich raus, daß Fedora eine uralte Version zur Verfügung gestellt hat. Es wird dringend dazu geraten, ProjectM selbst zu kompilieren, nur ist das, wie sich zeigt, nicht so einfach. Das Configure Script vermeidet bewußt zu sagen, was ihm zum Ausführen am QT Libs genau fehlt, ohne QT unterdrückt das make einfach mal die Fehler beim Bau von projectM-pulseaudio und sagt am Ende, daß alles fehlerfrei geklappt hat. Natürlich ohne irgendwas brauchbares erstellt zu haben.

Das kann man zwar nicht direkt als Bug bezeichnen, zeigt aber auf, wo da wohl das Problem seitens Redhat liegt, eine aktuelle Version zusammen zu häkeln.

Bitcoin auf Talfahrt

Der Bitcoin jetzt seine Talfahrt in die richtige Richtung fort, nach unten 🙂

Der Niedergang

Der seit einer Woche anhaltende Trend bestätigt sich auch heute, dem Bitcoin geht es schlecht. Von 9.000 € auf 4.800 € in nur einer Woche bedeutet, was jeder ahnen konnte: Die Blase ist geplatzt. 40% Wertverlust ist schon eine Marke. Die Verlustkurven reisen tiefe Lücken in den Graphen, trotzdem scheint sich der wertlose Digitaltiger immer wieder dagegen stemmen zu wollen.

Der Kurs der letzten 10 Stunden (Stand 10:30 Uhr)  ist das auch von Extremen geprägt. Gegen 2 Uhr waren es noch Spitzen von 5.700 €, die dann binnen 4 Stunden auf das erste Tagestief von 4.850 € zusammenbrachen, nur um von noch steilere Kursanstiege auf 5.300 € gefolgt zu werden.

Aber alles kämpfen nutzte nichts, um 9 Uhr brach der Kurs auf 4.800 € ein. Die derzeitige Kurserholung auf 5.000 € ist auch nur ein Zwischenschritt, bis die nächste Schneeballebene zum Verkauf schreitet.

Fazit

Wer jetzt nicht verkauft, ist selbst Schuld, wenn er als Kollateralschaden im Schneeballsystem endet.

Kommentar

Man muß den Spekulanten eins lassen, sie haben den Kurs von Nichts in $ ausgedrückt bekommen und sehr vielen Menschen sehr viel Geld abgenommen, ohne dafür einen Gegenwert zu liefern, falls der Gegenwert nicht der Spaß am Daytrading war. Der reale Gegenwert eines Bitcoins ist nämlich 0, genau wie der reale Wert eines 500 € Scheins*. Da aber mehr als 300 Millionen Menschen an den € glauben, ist sein Gegenwert realer als es der Bitcoin je sein konnte.Außerdem ist der € an reale Werte gekoppelt, denn ich kann dafür Immobilien und Güter kaufen und verkaufen.

Nicht einmal die Bitcoinkonferenzen haben am Ende den Bitcoin als Zahlungsmittel akzeptiert. Natürlich nur wegen der hohen Transaktionsgebühren, die als einzige verlässliche Zahl steigen müssen. Das haben selbst die Schöpfer des Bitcoins so vorhergesehen.

Von den noch vor wenigen Wochen erhofften Gewinnen durch den Handel mit Derivaten an den „echten“ Börsen, ist jetzt natürlich nichts mehr zu erwarten. Das waren nur die Versuche der abgehängten Spekulanten an dem Schneeballsystem mitzuverdienen. Bei den Verlusten des Bitcoins, dürfte der Keks gegessen sein.

*) Der Schein hat tatsächlich durch seine Produktionskosten und Materialien einen Wert > 0, aber nicht viel drüber 😉

Update 16:30 Uhr:

Die Talfahrt blieb ein Strohfeuer im Zuge des Grauen-Montags an den Amerikanischen Börsen. Mit Stand 16:30 würde der Bitcoin mit einem Plus von 7% gegenüber dem Stand von 0.00 Uhr dastehen. Am Trend zum totalen Wertverlust ändert sich damit aber nicht. Bin mal gespannt, wie es bei den Zockern weitergeht. Als Soap-Opera ist das ja kaum zu überbieten 🙂

Wenn Cinnamon ständig crashed

Warum immer in der Weihnachtszeit ? Die sollte doch so friedlich sein. Mein Laptop war anderer Meinung. Vor zwei Wochen erst auf Fedora 26 aktualisiert und seit Mittwoch crasht Cinnamon in Endlosschleife in seinen Rückfallmodus, ohne irgendeine brauchbare Spur zu hinterlassen. Na gut, Challenge Accepted!

Die Versuchsreihe

Zunächst mal sollte man checken, ob man vielleicht ein neues Update bekommen hat und dies das Problem löst. Tat es nicht, weil keines kam.

Ok, jetzt müßte man doch mal nachsehen, was da unter der Haube los ist. Also „journalctl -xe | grep -i cinnamon“ eingegeben und … nichts.

Ok, versuchen wir es ohne den Filter : „journalctl -xe“ und siehe da, jede Menge rote Crashmeldungen in diversen Libs, aber leider kein Hinweis, was da der Auslöser sein könnte. Auch 1 Stunde später, und diverse andere Logs und Webseiten später, senkte sich vom Baum der Erkenntnis die rote Kartenfrucht herab.

Der Reinstall

Ein klares Signal, einen Reinstall durchzuführen, also als Root eingegeben:

dnf reinstall „cinnamon*“

Und wieder in Cinnamon einloggen… args.. gleiches Ergebnis. Hmm.. da hat es wohl noch mehr zerlegt… uff. Also, ‚ dnf reinstall „*“ ‚ eingegeben, also die ersten 80 Pakete bereits runter geladen waren, wollte ich aber doch noch mal etwas anderes austesten.

adduser -s /bin/bash testuser
passwd testuser

Und dann mal als Testuser einloggen. Oh… Das geht ja … Da ist dann wohl doch nur die Session defekt. Dann hauen wir die halt weg:

rm -rf ./.config/cinnamon-session ./.local/share/cinnamon ./.cinnamon

Danach ist der Account so jungfräulich, daß Cinnamon alles wieder sauber anlegt und oh Wunder, dann geht es auch wieder mit dem Login 😀

Man muß natürlich alles neu einstellen,aber das ist ein kleiner Preis. Was meine Session/Einstellungsdaten genau getroffen hatte, wird man wohl nie erfahren 😉

 

Der GAU – Festplattenausfall und wie man Ihn behebt

„Wenn die Hardware versagt,und das Filesystem mit in den Abgrund zieht.“

Es war ein lauer Sonntagmittag, der Stream des Chaosradios ergoß sich von Radio Fritz, der Frachter in EVE flog seine Route, als plötzlich …  „can’t create tempfile in /tmp/gluster-x34234.tmp“ auf der Konsole  erschien. Das Ende vom Lied, die Festplatte hatte versagt:

 

 

 

 

 

 

Beim Rebooten startete das System nicht mehr mit dem Hinweis, daß die Superblöcke der Partionen/Filesysteme beschädigt wären.

/var/log/messages-20170402:Apr  2 15:05:32 eve kernel: EXT4-fs (sdc1): filesystem has both journal and inode journals!
/var/log/messages-20170402:Apr  2 15:08:10 eve kernel: EXT4-fs (sdc1): filesystem has both journal and inode journals!
/var/log/messages-20170402:Apr  2 15:08:29 eve kernel: EXT4-fs (sdc1): filesystem has both journal and inode journals!
/var/log/messages-20170402:Apr  2 15:08:30 eve kernel: EXT4-fs (sdc1): filesystem has both journal and inode journals!
/var/log/messages-20170402:Apr  2 15:08:34 eve kernel: EXT4-fs (sdc1): filesystem has both journal and inode journals!
/var/log/messages-20170402:Apr  2 15:08:44 eve kernel: EXT4-fs (sdc1): filesystem has both journal and inode journals!
/var/log/messages-20170402:Apr  2 15:08:47 eve kernel: EXT4-fs (sdc1): filesystem has both journal and inode journals!
/var/log/messages-20170402:Apr  2 15:08:49 eve kernel: EXT4-fs (sdc1): filesystem has both journal and inode journals!
/var/log/messages-20170402:Apr  2 15:08:49 eve kernel: EXT4-fs (sdc1): filesystem has both journal and inode journals!
/var/log/messages-20170402:Apr  2 15:09:46 eve kernel: EXT4-fs (sdc1): filesystem has both journal and inode journals!
/var/log/messages-20170402:Apr  2 15:09:58 eve kernel: EXT4-fs (sdc1): filesystem has both journal and inode journals!
/var/log/messages-20170402:Apr  2 15:11:34 eve kernel: EXT4-fs (sdc1): filesystem has both journal and inode journals!
/var/log/messages-20170402:Apr  2 15:21:39 eve kernel: EXT4-fs (sdc1): filesystem has both journal and inode journals!
/var/log/messages-20170402:Apr  2 15:25:56 eve kernel: EXT4-fs (sdc1): filesystem has both journal and inode journals!

Ein Mounten der Bootpartition war nicht mehr möglich, weil der Superblock defekt war. Im Endergebnis waren zwei Filesysteme der SSD defekt.

Wie konnte das passieren ?

Wenn man Google nach den im Screenshot gezeigten Fehlern befragt, zeichnet sich sehr schnell ab, daß die meisten auf ein Versagen der Stromzufuhr tippen. Das kann man aber wohl ausschliessen, da dabei als erstes die Grafikkarte ausgegangen wäre.

Da ich einige Tage vorher von Fedora 24 auf Fedora 25 umgestiegen bin, und damit auch ein neuer 4.10er Kernel zum Einsatz kam, ist es viel wahrscheinlicher, daß eine Treiber-HW-Kernel-Inkompatibilität vorlag. Das gabs bei Kernel 3.11 und 3.18 schon einmal.

Wie komme ich jetzt darauf ?

Das kommt daher, daß ich an dem besagten 2. April  das Stromversagen akzeptiert habe und daher die Stromverbindungen erneuert hatte. Einige Tage später, knallte die gleiche Platte wieder weg, ohne das jemand auch nur in  die Nähe der Stecker gekommen wäre. Seit Kernel 4.10.8-200 tritt das Problem nicht mehr auf. Es lag also vermutlich nicht am Strom, sondern an der Kernel-Treiber-HW Kombination.

Filesystem läßt sich nicht mounten

Es waren also zwei Filesysteme defekt. Dummerweise System-Root und die Bootpartition, wobei es die Bootpartition besonders schwer getroffen hatte:

kernel: EXT4-fs (sdc1): filesystem has both journal and inode journals!

Der den Fehler sieht, spart sich am besten gleich den Reperaturversuch und mountet die Platte mit der NOCHECK Option im Readonlymodus und kopiert die noch vorhandenen Files auf ein Backupmedium. Danach dann die Platte frisch formatieren und Daten wieder drauf spielen. Alles andere dürfte Zeitverschwendung sein. (siehe PDF)

Die Systempartition ließ sich im Gegensatz zur Bootplatte recht einfach mit fsck.ext4 reparieren. Daher liegt das Augenmerk des Beitrags auch auf dem Thema: Wie man eine neue Bootpartition aufbaut.

Da ich aus dem Problem und seiner Lösung gleich einen Vortrag für unsere LUG gemacht habe, könnt Ihr Euch jetzt alle nötigen Schritte in einem PDF herunterladen. Ich werde daher auch nur grob auf die einzelnen Lösungswege eingehen. Im PDF sind auch Reparaturanweisungen mit fsck, dumpefs, mke2fs  enthalten. Ich empfehle dringend das PDF an einem zugänglichen Ort aufzubewahren, ggf. auch als Offlinekopie 😉

Wie man eine Bootpartition neu aufbaut

Wir nehmen einfach mal an, daß die Bootpartition komplett hinüber ist, was bei dem oben aufgeführten Bug wohl auch der Fall ist. Mein Rettungsversuch mit fsck führte zum totalen Datenverlust, weil einige Inodes doppelt und dreifach belegt waren( vermute ich mal).

Deswegen ist oftmals nur eine neue Partition bzw. ein Reformatieren der Partition der letzte Ausweg.

Da das Formatieren die UUIDs einer Partition ändert, stimmen die Daten auf der Systemplatte nicht mehr.

Um der Sache jetzt folgen zu können, müßt Ihr zwei Dinge wissen:

  1. Was UUIDs und BLKIDs  sind
  2. Wie die im System benutzt werden um Partition zu referenzieren.

zu 1)

UUIDs werden von LUKS verschlüsselten Festplatten benutzt und sind ziemlich lange, aber eindeutige IDs.

$ lsblk
NAME                                          MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sr0                                            11:0    1  1024M  0 rom   
sdc                                             8:32   0 111,8G  0 disk  
├─sdc2                                          8:34   0 103,7G  0 part  
│ └─luks-ffbd61f2-4c1e-4dc8-b12b-c89e9f69c9fa 253:0    0 103,7G  0 crypt /
├─sdc3                                          8:35   0   7,6G  0 part  
│ └─luks-ca1f019d-39ce-4cf8-b522-f6d3e63ebe2a 253:1    0   7,6G  0 crypt [SWAP]
└─sdc1                                          8:33   0 525,5M  0 part  /boot
sda                                             8:0    0   1,8T  0 disk  
├─sda4                                          8:4    0     1K  0 part  
├─sda2                                          8:2    0  78,1G  0 part  
│ └─luks-6d45b281-c56c-40f0-acf7-c3058d4d6913 253:3    0  78,1G  0 crypt 
├─sda5                                          8:5    0   1,8T  0 part  
│ └─luks-7881f602-9462-497d-810a-7d6111ad6085 253:2    0   1,8T  0 crypt /sata_home
├─sda3                                          8:3    0   7,8G  0 part  
│ └─luks-384d6b27-6263-4d53-bfce-e7e5bcd221b9 253:4    0   7,8G  0 crypt 
└─sda1

BLKid sind die IDs der Filesystem selbst, also von / , von /home oder /boot . Ein Ext3/4, BTRS usw. Filesystem erzeugt beim Formatieren eine BLKID für sich dieses Filesystem. Jedesmal, wenn die Partition neu formatiert wird, gibt es eine neue Nummer.

$ blkid
/dev/sda1: UUID="aee1b027-ebd7-4ad9-a0ea-0fc881193708" TYPE="ext4" PARTUUID="000c4469-01"
/dev/sda2: UUID="6d45b281-c56c-40f0-acf7-c3058d4d6913" TYPE="crypto_LUKS" PARTUUID="000c4469-02"
/dev/sda3: UUID="384d6b27-6263-4d53-bfce-e7e5bcd221b9" TYPE="crypto_LUKS" PARTUUID="000c4469-03"
/dev/sda5: UUID="7881f602-9462-497d-810a-7d6111ad6085" TYPE="crypto_LUKS" PARTUUID="000c4469-05"
/dev/sdc1: LABEL="Boot" UUID="221608f2-5914-4619-9ef7-6dfddf233fd4" TYPE="ext4" PARTUUID="0000a3dd-01"
/dev/sdc2: UUID="ffbd61f2-4c1e-4dc8-b12b-c89e9f69c9fa" TYPE="crypto_LUKS" PARTUUID="0000a3dd-02"
/dev/sdc3: UUID="ca1f019d-39ce-4cf8-b522-f6d3e63ebe2a" TYPE="crypto_LUKS" PARTUUID="0000a3dd-03"
/dev/mapper/luks-ffbd61f2-4c1e-4dc8-b12b-c89e9f69c9fa: UUID="e62edbbe-a1ae-4242-bca5-1249d6f2df67" TYPE="ext4"
/dev/mapper/luks-ca1f019d-39ce-4cf8-b522-f6d3e63ebe2a: UUID="46da0d80-21fb-45b7-8567-ba047de66cb6" TYPE="swap"
/dev/mapper/luks-7881f602-9462-497d-810a-7d6111ad6085: UUID="196a4455-7ccb-40e4-bc71-7b2929f29225" TYPE="ext4"
/dev/mapper/luks-6d45b281-c56c-40f0-acf7-c3058d4d6913: UUID="0fd1b33c-5a2e-421a-a872-7bfc784ea2cf" TYPE="ext4"
/dev/mapper/luks-384d6b27-6263-4d53-bfce-e7e5bcd221b9: UUID="0bb5a502-f854-4e40-a3bd-08c3a2e6bf22" TYPE="swap"

zu 2)
Jetzt schauen wir uns mal /etc/fstab und den Bootentry im Grub an :

$ cat /etc/fstab 

/dev/mapper/luks-ffbd61f2-4c1e-4dc8-b12b-c89e9f69c9fa /           ext4    defaults,x-systemd.device-timeout=0 1 1
UUID=221608f2-5914-4619-9ef7-6dfddf233fd4 /boot                   ext4    defaults        1 2
/dev/mapper/luks-7881f602-9462-497d-810a-7d6111ad6085 /sata_home  ext4    defaults,x-systemd.device-timeout=0 1 2
/dev/mapper/luks-ca1f019d-39ce-4cf8-b522-f6d3e63ebe2a swap        swap    defaults,x-systemd.device-timeout=0 0 0

Wie man in der FSTAB sehen kann, soll /boot über die BLKID eingebunden werden.

Warum macht man das ?

Ganz einfach, weil die BLKID ( BlockID ) eindeutig ist, egal an welchem Port eines Controllers die Platte angebunden ist. Selbst wenn die per USB ins System eingehängt ist, kann man diese Partition referenzieren. Das alt bekannte Problem von früher, wenn sich die Plattenreihenfolge geändert hat, daß dann eine andere Platte das Bootdevice war, entfällt damit.

Wieso ist /boot über BLK referenziert und / mit einer LUKS ID ?

Weil Boot nicht verschlüsselt ist. Das geht zwar auch, aber dann wird es haarig 😉

Da in der FSTAB die BLKID enthalten ist und sich nach erneuten Anlegen des Filesystems eine neue BLKID ergibt, muß man also vor dem ersten Boot die /etc/fstab anpassen, sonst bootet der Rechner nicht mehr.

Der Grub-Booteintrag:

menuentry 'Fedora (4.10.6-200.fc25.x86_64) 25 (Twenty Five)' --class fedora --class gnu-linux --class gnu --class os --unrestricted $menuentry_id_option 'gnulinux-4.10.6-200.fc25.x86_64-advanced-e62edbbe-a1ae-4242-bca5-1249d6f2df67' {
        load_video
        set gfxpayload=keep
        insmod gzio
        insmod part_msdos
        insmod ext2
        set root='hd2,msdos1'
        if [ x$feature_platform_search_hint = xy ]; then
          search --no-floppy --fs-uuid --set=root --hint-bios=hd2,msdos1 --hint-efi=hd2,msdos1 --hint-baremetal=ahci2,msdos1  221608f2-5914-4619-9ef7-6dfddf233fd4
        else
          search --no-floppy --fs-uuid --set=root 221608f2-5914-4619-9ef7-6dfddf233fd4
        fi
        linux /vmlinuz-4.10.6-200.fc25.x86_64 root=UUID=e62edbbe-a1ae-4242-bca5-1249d6f2df67 ro vconsole.font=latarcyrheb-sun16 rd.luks.uuid=luks-ca1f019d-39ce-4cf8-b522-f6d3e63ebe2a rd.luks.uuid=luks-ffbd61f2-4c1e-4dc8-b12b-c89e9f69c9fa  rhgb quiet splash audit=0 rd.driver.blacklist=nouveau nouveau.modeset=0 
        initrd /initramfs-4.10.6-200.fc25.x86_64.img
}

Wie man hier unschwer erkennen kann, kommt die BLKID auch im Bootentry vom Bootloader vor, was verständlich ist, weil der sonst nicht weiß welche Platte er booten sollte 😉

Zudem sind hier die zum Systemstart zu entschlüsselnden  LUKS Partitionen enthalten. Zudem ist die ROOT Partition mit angegeben, die auch über die BLKID referenziert wird.

Wie stellen wir jetzt aber die Bootpartition wieder her ?

Am einfachsten mit einer LiveCD vom gleichen Distributor . Dann formatieren wir die Bootpartition, so daß diese leer ist und legen uns die BLKID bereit. Folgende Schritte führen dann zum Ziel:

  1. Systempartition mounten
  2. DEV und PROC in die Systempartition mounten
  3. BOOT in die Systemplatte mounten
  4. CHROOT in die Systemplatte machen
  5. Bisherige Kernel finden
  6. Kernel neu installieren

Das sieht dann so aus ( natürlich haben Sie andere Partitionen als ich: SDC2 ist Root, SDC1 ist Boot ). Vorher zum Rootuser werden ( su root ) :

mount /dev/sdc2 /media
mount -t devtempfs devtempfs   /media/dev
mount -t procfs procfs /media/proc
mount -t ext4 /dev/sdc1 /media/boot
chroot /media/

Jetzt befinden wir uns im System des normalen Rechners, so daß wir alles so tun können, als wenn er normal gebootet hätte ( ohne Desktop natürlich ) . Wir bekommen die Kernel raus die drauf waren :

rpm -qa | grep kernel-core

und installieren die neu:

dnf reinstall kernel-core-*

Das sind natürlich Anweisungen für Fedora/RedHat Systeme, hier bitte die passenden für Eure Distribution wählen. Natürlich kann man das Raussuchen der Kernels auch weglassen, da ist ja nur eine Info für Euch, damit Ihr seht, ob es stimmt. Nun noch die GRUB Boot Konfiguration neu erzeugen und der Rechner sollte wieder starten:

grub2-install /dev/sdc
grub2-mkconfig -o /boot/grub2/grub.cfg

Das Anpassen von /etc/fstab sollte man natürlich jetzt auch machen, sonst gehts nicht 😉

Wer unerfindliche Probleme mit seinem GRUB Bootentry hat, dem könnte der Beitrag helfen. Ich mußte auch Linux16 durch Linux ersetzen, damit es wieder funktioniert.

Ich kann allen nur nochmal nahe legen, das PDF unten auf einem USB Stick zu sichern, damit Ihr das im Notfall parat habt. Außerdem sind in dem PDF noch viele andere Infos zum Thema aufgeführt und einige intensiver heraus gearbeitet.

PDF zum Download: LUGBS-Filesystemmeltdown

LibreOffice doch keine Alternative zu OpenOffice ?

Wer von LibreOffice enttäuscht ist und lieber OpenOffice benutzen will, ich kann es verstehen. Man sollte ja annehmen, daß LibreOffice als „das“ gepflegtere Officepaket weniger Probleme hätte, ergo auch „kompatibler“ ist. Leider ist das nicht so. Meine Fedora LibreOfficeversion konnte genau „gar kein“ Dokument öffnen und ist dabei auch noch laufend abgeschmiert. Da das Update von Fedora 23 auf 24 auch noch meine OpenOffice Installation ungefragt durch LibreOffice ersetzt hat, ist es Zeit für einen Neustart.

Erstmal weg mit der Zwangsbeglückung

Zunächst löschen wir mal LibreOffice, weil es sich mit einer RPM basierten Installation von OpenOffice beissen würde:

dnf erase "libreoffice*"

Dann laden wir uns OpenOffice von einem Mirror herunter:

http://ftp-stud.hs-esslingen.de/pub/Mirrors/ftp.apache.org/dist/openoffice/4.1.3/binaries/de/Apache_OpenOffice_4.1.3_Linux_x86-64_install-rpm_de.tar.gz
http://ftp-stud.hs-esslingen.de/pub/Mirrors/ftp.apache.org/dist/openoffice/4.1.3/binaries/de/Apache_OpenOffice_4.1.3_Linux_x86_langpack-rpm_de.tar.gz

In der Version ist der letzte Hotfix auch drin, also kann das ohne weiteres installiert werden.

Dazu legt Ihr am besten einen leeren Ordner an, z.B. Programme/OpenOffice :

tar xzvf Apache_OpenOffice_4.1.3_Linux_x86_langpack-rpm_de.tar.gz
tar xzvf Apache_OpenOffice_4.1.3_Linux_x86-64_install-rpm_de.tar.gz

Dann wechselt hier in das Verzeichnis „de/RPMS“ (cd de/RPMS) und führt den Befehl aus:

sudo dnf install *x86_64.rpm ./desktop-integration/openoffice4.1.3-redhat-menus-4.1.3-9783.noarch.rpm

Das installiert die 64Bit Version von OpenOffice. Wer die 686er Version braucht, muß das etwas anpassen.

Kaum das OpenOffice korrekt installiert ist, kann man auch wieder Excel 2007 Dokumente öffnen, die man leider im Geschäftsleben braucht.

Jetzt die Fragen an Euch:

Welche Probleme habt Ihr mit Eurem Officepaket ?
Funktioniert Libre bei Euch sauber, oder seid Ihr auch auf OpenOffice angewiesen ?Misfällt Euch der Startbildschirm von Libre auch so wie mir ? Der sieht irgendwie „Billig“ aus.

Ich bin gespannt auf Euren Input.