[15:52] <nicole> hi
[17:47] <DaVu> N'
[17:47] <nicole> hi DaVu :D
[17:47] <DaVu> N'abend auch dir nicole o/
[17:48] <DaVu> Jetzt habe ich tatsächlich ein komisches Problem.... Wollte gerade meinen Laptop starten (Ubuntu 18.04) und es stockt bei der Displaymeldung "Started Disk Manager. Manager. Dispatcher Service .....ten chenges.pp link was shut down"
[17:48] <DaVu> und da passiert jetzt gar nichts mehr
[17:49] <DaVu> jemand eine Idee?
[17:49] <k1l> in grub alten kernel probiert?
[17:49] <DaVu> ICh komme an Grub nicht ran. Lange Shift halten bringt mir das Menu nicht, k1l
[17:50] <k1l> manchmal ist timing wichtig. einfach mal oft shift drücken
[17:50] <k1l> oder bei manchen ist es auch esc
[17:50] <jokrebel> war das nicht esc?
[17:50] <DaVu> Das letzte, was ich heute Morgen gemacht habe, war Nemo installiert und deinstalliert
[17:50] <nils_2> war das nicht ESC und nicht shift?
[17:50] <DaVu> ok, ich probiere es 
[17:51] <DaVu> ok, bei Escape bekomme ich einen grub-prompt
[17:51] <DaVu> da kenne ich mich nicht aus
[17:52] <k1l> also entweder ganz oft shift drücken bis "loading grub" kommt und dann gedrückt halten.  oder halt esc oder leertaste
[17:53] <nicole> sagt mal wo stehen die Informationen wenn ein Eintrag im /etc/fstab nicht lädt?
[17:54] <DaVu> k1l: ok, ich habe grub
[17:54] <k1l> dmesg oder syslog
[17:54] <DaVu> probiere jetzt mal den Kernel 4.15.0-23-generic
[17:54] <k1l> nicole: oder eben mount -a eingeben (was die fstab noch mal lädt) und dann gucken was er da sschreibt
[17:55] <DaVu> k1l: endet an gleicher Stelle
[17:55] <DaVu> auch mit älterem Kernel. Ich könnte höchstens noch die Recovery-einträge versuchen
[17:56] <k1l> ja, recovery versuchen. ansonsten mal in die recovery gehen und auf der konsole dann die logs angucken was da genau hakt
[17:57] <DaVu> k1l: nachdem ich recovery ausgewählt habe, kommt ein weiteres Menu mit "resume", "clean" usw... was sollte man da nehmen. "resume" ja höchstwahrscheinlich nicht
[18:03] <k1l> mach mal resume und guck ob er dann im einfachen vgs modus läuft
[18:04] <k1l> ansonsten root auswählen und dann eben in die logs gucken was da genau das problem ist.
[18:05] <DaVu> ok, letzteres werde ich wohl mal versuchen. Hoffe, ich finde da was. Hast du eine Idee, welches Log ich mir anschauen sollte?
[18:05] <k1l> /var/log/syslog z.b.
[18:05] <DaVu> danke dir
[18:06] <k1l> oder eben das log von dem dm, den du da nutzt
[18:06] <DaVu> standard dm
[18:06] <DaVu> also das, was Ubuntu 18.04 unter GNOME mit sich bringt
[18:06] <k1l> gdm
[18:06] <k1l> wenn nemo da nicht was anderes mitgezogen hat
[18:07] <DaVu> Ja, das nervt mich am meisten. Ich habe das heute für einen User versucht, da bei dem irgendwas nicht ging und jetzt dieser Rotz
[18:09] <DaVu> ok, das wird länger dauern. Erstmal Abendessen und ggf. auf morgen verschieben. Sonst tritt mich die Frau ;)
[18:09] <DaVu> Ich danke dir für deine Hilfe, werde bestimmt nochmal drauf zurück kommen müssen
[18:09] <nicole> :)
[18:13] <nicole> komisch nun klappt mein cifs mount, trage ich ihn aber in die fstab ein erhalte ich https://paste.ubuntu.com/p/8wYfpYywyY/
[18:13] <le_bot> Title: Ubuntu Pastebin (at paste.ubuntu.com)
[18:14] <k1l> ist dein netzwerk vlt noch nicht fertig oben zu der zeit?
[18:15] <nicole> das mag sein?! kann ich das Zeitverzögern?
[18:19] <k1l> ich glaube man nutzt jetzt "x-systemd.automount" als option in der fstab dafür
[18:20] <k1l> https://wiki.ubuntuusers.de/fstab/#Automount-mit-systemd
[18:20] <le_bot> Title: fstab › Wiki › ubuntuusers.de (at wiki.ubuntuusers.de)
[20:20] <nicole> jetzt habe ich alles hin bekommen soweit
[20:21] <nicole> ein weiterer Baustein, kann ich die Up und down Stream Geschwindigkeiten von sftp regeln?
[20:28] <tomreyn> moin. was den mount  in der fstab angeht, würde ich nicht beim ersten zugriff darauf mounten (das bringt nur eine weitere race condition mit sich) sondern nach start des netzwerks wie hie rbeschrieben: https://unix.stackexchange.com/questions/349264/fstab-mount-wait-for-network
[20:28] <le_bot> Title: networking - fstab mount wait for network - Unix & Linux Stack Exchange (at unix.stackexchange.com)
[20:30] <nicole> ja dadrüber bin ich auch schon gestolpert aber scheint dann doch für mich obsolet zu sein :)
[20:31] <tomreyn> bandbreitenbegrenzungen macht man am besten auf netzwerkgeräteseite oder auf dem client. der openssh-server unterstützt selbst keine. der sftp-*client* kann mit der option -l begrenzt werden.
[20:32] <tomreyn> je nachdem welchen router ihr da habt kann der das ggf. auch begrenzen.
[20:32] <tomreyn> es ginge auch noch auf dem linux-system mittels traffic shaping zu machen, aber das ist eigentlich der falsche ort dafür. und es ist einigermaßen frickelig.
[20:33] <nicole> QoS steht im Router auch noch gaaanz hinten auf der Liste 
[20:33] <nicole> weil das ist auch nix was man "mal eben" so reinwirft 
[20:33] <tomreyn> na immerhin steht's da
[20:33] <nicole> :)
[20:34] <nicole> ich hab dem sftp chroot jetzt auch noch einen pub key auth gegeben, ich glaube maximalere Zugangsberechtigung kann ich damit nicht vergeben ;)
[20:59] <hErMeS_0815> Hallo, ich hatte mich gestern hier gemeldet wegen einem Kernel-crash bei Nutzung IPv6 mit haproxy
[21:00] <nicole> ich mag mich erinnern 
[21:02] <hErMeS_0815> ich habe zum Test die Testmaschine frisch installiert. Ubuntu Server amd64. zwei lxc Container (nginx und haproxy) eingerichtet mit ubuntu 18.04 und nur das nötigste im haproxy eingestellt (nur ipv6)
[21:03] <hErMeS_0815> Der Kernel crasht definitiv. Eventuell ein verbasteltes Ubuntu sollte demnach ausgeschlossen seien. Die Abfolge der Konfiguration kann ich notfalls bereit stellen.
[21:04] <tomreyn> moin hErMeS_0815, wir hatten dazu gesprochen. ich muss leider jetzt erst mal weg für ne stunde oder so, aner wäre sehr am ergebnis interessiert. hoffe dass du meinen empfehlungen nachgekommen bist ein anderes kernel image zu probieren, und auch ne serielle oder netconsole dran zu dängeln damit zu die gesamte kernel panic abfangen kannst.
[21:05] <tomreyn> wenn du einen reduzierten testcase beschreiben kannst mit dem man das nachstellen kann, probiere ich das auch gerne.
[21:05] <tomreyn> bbl
[21:06] <hErMeS_0815> ein modprobe netconsole wirft folgendes heraus: https://paste.ubuntu.com/p/Cf6xjzvNGC/
[21:06] <le_bot> Title: Ubuntu Pastebin (at paste.ubuntu.com)
[22:03] <hErMeS_0815> in folgender Reihenfolge ist die Test Maschine bei mir eingerichtet:
[22:04] <hErMeS_0815> Schritte nach Host Installation: https://paste.ubuntu.com/p/Yr4fqJJgb2/
[22:04] <le_bot> Title: Ubuntu Pastebin (at paste.ubuntu.com)
[22:04] <hErMeS_0815> Schritte zur Erstellung haproxy container: https://paste.ubuntu.com/p/tTTwdWxR53/
[22:04] <le_bot> Title: Ubuntu Pastebin (at paste.ubuntu.com)
[22:04] <hErMeS_0815> Schritte zur Erstellung nginx container: https://paste.ubuntu.com/p/WVg2RPTsgS/
[22:04] <le_bot> Title: Ubuntu Pastebin (at paste.ubuntu.com)
[22:04] <hErMeS_0815> Scripte und config Vorlagen: https://paste.ubuntu.com/p/yRkVmtsyz6/
[22:04] <le_bot> Title: Ubuntu Pastebin (at paste.ubuntu.com)
[22:22] <hErMeS_0815> ich bin jetzt auf Linux testing 4.15.0-26-generic #28-Ubuntu SMP Wed Jul 4 16:24:29 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux. Kernel crasht ebenfalls. Firefox kann das Zertifikat abrufen. Dieses ungültige Zertifikat genehmige ich und danach ist crash bei weiterem HTTPS Zugriff.
[22:23] <tomreyn> hErMeS_0815: bei dem netconsole-parameter fehlt der abschließende slash: sudo modprobe netconsole netconsole=6666@192.168.178.200/ens5,6666@192.168.178.31/ -vvv
[22:23] <k1l> was sagt das syslog der kiste, die crasht, dazu was da passiert?
[22:26] <hErMeS_0815> beim netconsole hatte ich vorher das Ende mit <empfängerip>/<empfängermac> angegeben. da kam ebenfalls operation not permitted
[22:27] <hErMeS_0815> das Log besagte da auch dass gewisse Pfade/Dateien nicht gefunden wurden
[22:33] <hErMeS_0815> Syslog besagt nichts.  Jul 10 22:29:05 testing kernel: [  329.718534] netconsole: network logging started Jul 10 22:31:43 testing kernel: [    0.000000] microcode: microcode updated early to revision 0xe, date = 2013-06-26
[22:35] <hErMeS_0815> bin dann auch erstmal raus. wäre schön wenn es nicht nur bei mir auftritt. Eine Serielle Konsole habe ich an dem Rechner nicht.
[22:36] <hErMeS_0815> Die komplette Einrichtung habe ich zumindest bekannt gegeben so dass man es nachstellen kann.
[22:37] <tomreyn> wow, uralter microcode.
[22:37] <tomreyn> aber das wirds wohl kaum sein.
[22:37] <hErMeS_0815> betagterer Rechner ~2010
[22:38] <tomreyn> ah, ok, stimmt sah man auf dem screenshot ein wenig
[22:38] <tomreyn> 'screen shot'
[22:38] <tomreyn> ich komm heute nicht mehr zum nachstellen, vielleicht morgen
[22:38] <tomreyn> hast du noch ne kontaktadresse außer irc?
[22:39] <hErMeS_0815> tomreyn: bin gespannt was bei dir geschieht
[22:39] <hErMeS_0815> kann ich dir das hier irgendwie zukommen lassen?
[22:39] <tomreyn> schick mir ne mail an tomreyn bei megaglest punkt org
[22:40] <tomreyn> kurz und formlos ;)
[22:42] <tomreyn> ein volles dmesg wäre auch noch gut zu sehen. wenn dir das nicht zu viel preis gibt. kann auch später.
[22:42] <k1l> wenn das mit dem microcode das letzte vor dem crash ist, dann kann das auch ein problem sein.
[22:43] <tomreyn> das early microcode update findet während des boots statt. der crash findet viel später statt, wird manuell getriggert nachdem das system oben ist.
[22:44] <hErMeS_0815> https://paste.ubuntu.com/p/2y5wsb93dr/
[22:44] <le_bot> Title: Ubuntu Pastebin (at paste.ubuntu.com)
[22:45] <tomreyn> prima, dann mal gute nacht!
[22:45] <hErMeS_0815> der crash erfolgt sobald man auf haproxy mit einer ipv6 zugreift und der das per pass through zum webserver weiter gibt.
[22:46] <hErMeS_0815> Ich danke dann schonmal. Macht mir jedenfalls Kopfzerbrechen. Alles soll möglichs sicher werden und möglichst weitestegehendst isoliert und dann sowas.
[22:48] <hErMeS_0815> Das microcode ist nach dem crash und das netconsole vor dem crash
[22:48] <hErMeS_0815> und jetzt gute nacht.
[22:54] <tomreyn> puh, die hardware ist so alt...