[00:05] okay das geht leider nicht wie es ausschaut, FAILED Failed to start LSB: start Samba SMB/CIFS daemon (smbd)... [00:06] wieso Samba? Du brauchst nur "dhclient eth0" bei einer Kabelverbindung eingeben [00:07] ja, hab ich eingegeben [00:08] ok, dann gib mal "ping -c 3 8.8.8.8 | grep "packet loss"" ein und schaue, ob Paketverluste auftreten [00:11] habe ein weiteres mal dhclient eth0 eingetragen da steht nun /etc/lib/ntpdate/default.dhcp: read-only file system [00:12] und beim ping kommt nichts [00:13] es dauert ein wenig, bis was angezeigt wird [00:15] ansonsten mit einem USB-Stick und cp https://wiki.ubuntuusers.de/cp/ mit https://wiki.ubuntuusers.de/mount/ muss afaik erstmal der USB-Stick eingehangen werden [00:16] Title: cp › Wiki › ubuntuusers.de (at wiki.ubuntuusers.de) [00:16] habe eben mount -o remount,rw / eingetragen und bekam folgedes raus: invoke-rc.d: could not determine current runlevel smb.service is not active, cannot reload. invoke-rc.d: initscript smbd, action "reload" failed. [00:18] bitte erstmal die syslog [00:19] ja okay ich bin leider nicht so schnell, tut mir leid :-( [00:19] jo, kein Ding [00:21] fyi: ubuntu-server-live-installer 18.04.1 mit lvm-partitionierung: https://launchpad.net/bugs/1785321 [00:21] Title: Bug #1785321 “LVM Entire Disk option does not use entire disk” : Bugs : subiquity (at bugs.launchpad.net) [00:24] die auflösung ist so niedrig dass ich nicht alle einträge sehen kann bei "mount -l" [00:25] kann man hier auch irgendwie nach oben scrollen? [00:26] Du kannst mit den Tasten Bild auf und Bild ab scrollen [00:29] das funktioniert nicht mit dem scrollen [00:30] Dann mit der Shift-Taste [00:30] beim drücken der bild taste bekomme ich die tilde ~ eingegeben [00:30] okay das geht [00:35] ich sehe leider nur einen datenträger und das ist /dev/sda1 muss der usb stick auf eine bestimmte partition formatiert werden? [00:38] entschuldige bitte aber ich glaub ich mach da was falsch [00:40] ja, Du musst erstmal den Datenträger mit "mount [Parameter] " einhängen. Welches Gerät das ist, kannst Du mit blkid herausfinden https://wiki.ubuntuusers.de/blkid/ [00:40] Title: blkid › Wiki › ubuntuusers.de (at wiki.ubuntuusers.de) [00:43] als Einhängepunkt kannst Du das Verzeichnis /media nehmen [00:46] ich vermute mal, Dein USB-Stick wird unter /dev/sdb geführt [00:46] kann es sein dass der usb stick gar nicht angezeigt wird, habe mehrere festplatten dran hängen aber mir wird nur dev/sda1 angezeigt der rest sieht nach systemverzeichnissen aus [00:49] sudo blkid -t TYPE=ntfs hab ihn gefunden [00:49] :-D [00:49] komme voran :-P [00:54] ist der USB-Stick mit NTFS formatiert? [00:54] ja muss ihn nur nich mounten [00:54] es ist sdf1 [00:59] hilf mir mal bitte beim parameter [00:59] sudo mount -t ntfs -o umask=007,gid=046,uid=0,nls=utf8 /dev/sda1 /media/winxp [01:01] was gebe ich bei umask ein git uid die nummer nehme ich mal an nls so lassen bei /dev/sdf1 und bei nls weiss ich auch nicht [01:04] uid und gid ist die Gruppen und User-ID, die angeben wird, wenn auf dem Dateisystem die zu schreibenden Daten nicht als root bzw. admin gehören sollen [01:05] bei nls nimmst Du utf8 [01:06] diese ändere ich also nicht [01:06] ganz schön kompliziert [01:10] wobei, mach einfach mal nur "mount -t ntfs-3g /dev/sdf1 /media" oder "mount -t ntfs /dev/sdf1 /media". Müsste ausreichen [01:11] okay [01:12] und dann kannst Du mittels "cp /var/log/syslog /media/syslog" kopieren [01:13] bzw. "cp /var/log/syslog /media/" kopieren [01:14] vielen dank ich habs auf dem stick [01:14] und nun hochladen ja? [01:17] jo, bitte bspw. nach paste.ubuntu.com [01:17] und dann den link hier rein [01:20] cat syslog | pastebinit [01:20] Bad API request, maximum paste file size exceeded [01:20] ist die file nicht etwas zu groß? [01:21] 16 mb [01:21] ui [01:21] jo [01:21] bissl arg groß [01:21] was mach ich nun? [01:22] ein teil nur raus kopieren vielleicht [01:23] ja, am besten den letzten Start des Systems rauskopieren [01:24] also jetzt nicht nur den mit dem recovery-Start [01:24] gibt es da nach einem starteintrag wonach ich suchen soll [01:27] moment, ich muss mal bei mir schauen [01:28] ich kann die file wo auch wo annders hochladen wenn die hier zu groß ist [01:29] oder aufteilen? [01:39] https://paste.ubuntu.com/p/GdTpH3zgv4/ [01:40] Also, die erste Zeile eines Systemstarts beginnt bei meinem Schlepptop mit >rsyslogd: [origin=software"rsyslogd" ..... ] start [01:40] hab hier die aktuellere hälfte genommen [01:40] schau mal rein [01:41] wenn da nichts bei ist was hilfreich wäre, lade ich den ersteh teil hoch [01:47] ich hab den ersten teil nun auch hochgeladen https://paste.ubuntu.com/p/2ht6qr9Pg5/ [01:47] da war was mit dem gewünschten starteintrag dabei [01:49] wie schlimm ist es doktor, wird er es überleben? [01:50] erstmal gucken, ob ich was finde [01:55] was ich auf die Schnelle fand: 01:08:49 Cube /usr/lib/gdm3/gdm-x-session[2214]: (EE) NVIDIA: Failed to initialize the NVIDIA kernel module. [01:57] frag bitte nachher nochmal nach, ob andere was sehen [01:58] S4ndm4nn ^^ [01:58] ja mit den grafikkarten treiber gab es schon öffters probleme nach einem update [01:59] aber bisher hatte ich es immer selbst lösen können [02:02] ja es ist schon sehr spät oder auch sehr früh am morgen, ich hab schon gemerkt dass es ein schlimmeres problem wird. werde mich morgen nochmals melden am besten [02:03] eine sache wollte ich aber noch erwähnen [02:04] dieses ubuntu hab ich ja schon sehr lange auf meinem pc und als immer öfter fehler auftraten, hab ich mich entschlossen das neuste ubuntu 18 lts zu installieren. [02:05] sobald ich es aber starte dauert es es eine ganz schön lange zeit ca 10-15 minuten bis es start es wirkt so als ob es sich aufgehangen hat habe also ein schwarzes bild die ganze zeit über [02:06] also wenn es an dem nvidia-Treiber liegen sollte, sollte eine Reinstallation abhilfe schaffen "apt-get install --reinstall nvidia-384" müsste das von Dir verwendete Paket sein [02:06] bevor es startet sieht man noch eine fehlermeldung aufflackern und dann startet es ganz normal und läuft auch fehlerfrei [02:07] okay versuch das eben nochmal [02:07] ist aber doch kein dauerzustand immer wieder nach allen updates die grafikkarte neu zu installieren [02:08] was das neue ubuntu angeht, ist meine hardware vielleicht zu veraltert oder woran kann das liegen [02:08] was ist denn das für ein System [02:09] also ich gehe davon aus, dass Du eine relativ neue NVidia-Karte hast, da bei Dir der 384er installiert ist [02:10] mainboard ist von gigabyte 970a-ud3 [02:10] jo, so alt ist der Rechner nun auch nicht :) [02:11] ja die karte ist nicht so alt aber das board und die cpu ist ein amd fx8 8120 [02:14] woran könnte es liegen dass alle mint, ubuntu und debian nicht anständig booten im internet hab ich nichts dazu gefunden [02:14] daher ging ich von der hardware aus [02:15] also Du sagst, dass Du 18.04 installiert hast? [02:15] ja ist auf einer anderen platte drauf [02:16] wollte meine daten migrieren [02:16] ach, paralell? [02:16] ja [02:16] weil ich sehe hier den Kernel 4.4, das ist der Standard-Kernel von 16.04 [02:17] ja das ist mein problem system [02:17] naja das neue läuft zwar auch aber benötigt beim booten über 10 minuten lang [02:17] achso, und Du willst nur noch die Daten migrieren? [02:18] ja weil das immer wieder probleme macht mit der grafikkarte [02:18] "apt-get install --reinstall nvidia-384" hab ich mal eingegeben leider kann ich in diesem modus keine pakete laden [02:18] ok, dann wäre es doch besser, wenn wir uns dem 18.04 zuwenden und schauen, warum der Start dort so lange dauert [02:19] internet verbindung geht leider nicht [02:19] jo [02:19] nur wenn es für dich nicht all zu spät ist [02:21] also von dort auch die /var/log/syslog aber lass dir ruhig Zeit [02:22] mal sehen ob da im recovery modus die internet verbindung geht [02:24] also selbst um den recovery modus zu booten dauert lange [02:24] sonst boote einfach in die normale Umgebung [02:25] dauert genauso lange XD [02:25] :) [02:25] normal ist es doch nicht [02:26] soll ich da auch mal dieses quiet splash entfernen? [02:30] hmm bekomme aber nichts angezeigt mit oder ohne diesen eintrag, nur ein standbild und nun heißt es warten [02:30] S4ndm4nn: also ich hatte letztens mit einem anderen Laptop auch ein Problem mit dem nvidia-Treiber. Kernel müsste afaik 4.4 sein. Ich musste den Treiber (Treiberversion weiß ich jetzt nicht mehr) komplett deinstallieren und den nouveau-Treiber nutzen, weil ich mich sonst nicht einloggen konnte. Auf meinem Desktop mit 16.04, Kernel 4.4 und nvidia-352 habe ich allerdings diesbezüglich keine Probleme [02:32] scheint so als ob nvidia nicht nur bei mir probleme verursacht [02:33] aber ohne diesen treiber läuft das system etwas sperriger [02:34] gerade, wenn man es zum Daddeln nutzen möchte [02:34] vor allem dann :-D [02:34] aber auch so [02:41] also jetzt sehe ich was [02:41] steht alles auf OK [02:42] aber weiter gehts nicht mehr :-( [02:42] normaler weise ging es weiter [02:42] das ist doch zum verzweifeln [02:44] ach es ging eben weiter [02:44] bild flimmerte kurz [02:44] OK started nvidia persistence daemon [02:44] und nun hängt es wieder [02:46] alternativ kann man auch mit einem Live-System nachgucken und ggfls. mit chroot ins installierte System eingreifen https://wiki.ubuntuusers.de/chroot/Live-CD/ [02:46] Title: Live-CD › chroot › Wiki › ubuntuusers.de (at wiki.ubuntuusers.de) [02:50] okay geschafft [02:50] es ist nun hochgefahren [02:50] XD [02:53] jetzt ist aber was seltsames passiert...hab ich eingeloggt und pastebinit installiert [02:53] dann wurde alles dunkel und bin bin ich wieder in diesen status lade bild [02:54] XD [02:54] hm? Bootsplash? [02:54] schaut so aus nur mit dem status inhalt [02:55] steht alles auf grün [02:55] hm [02:55] also ich hab gesehen dass Ubuntu 18.04.1 LTS released ist [02:56] soll ich das nicht einfach nochmals aufspielen, vielleicht wird das ja laufen [02:56] weil so kommen wir einfach nicht voran [02:57] mir sind nur die daten wichtig auf dem alten ubuntu system [02:59] es ist letztlich Deine Entscheidung, ob Du das neu installierst. [03:00] auf der der 18.er version war nichts drauf [03:00] bist du morgen auch wieder hier? [03:01] jo [03:02] aber ich würde schon vorschlagen, dass wir erstmal beim 18.04 schauen, was da kaputt sein könnte, bevor Du es neu installierst. [03:04] okay, bevor ich das neu aufspiele würde ich das mit der live version mal machen um an die syslog zu kommen [03:06] so ich starte das noch ein letztes mal mit einem älteren kernel und sollte es klappen lade ich gleich die syslog auf pastebinit hoch [03:07] falls nicht, komme ich morgen abend wieder vorbei [03:07] jo [03:07] bin mal so lange das system hochfahrt afk [03:07] ich gucke grade über das vorhin gepostete syslog von einem 16.04-system mit kernel 4.4 [03:07] wenn das ein nvidia-system ist würd ich mal nomodeset probieren, falls nicht schon getan [03:08] das bios ist sehr in die tage gekommen, da würd ich mal ein neues probieren, hat damit jetzt allerdings nix zu tun [03:09] ja schon versucht, aber da gibts für mein board nichts neus [03:09] hab das mal irgendwo mal gelesen das ein biosupdate helfen könnte [03:10] ich werde vermutlich nicht drum herum kommen mir neue hardware zu kaufen [03:10] normal ist das auf keinen fall [03:10] tomreyn: was macht denn das nomodeset? [03:11] trage ich das vor dem quiet splash ein oder ersetze ich es damit? [03:12] !nomodeset [03:12] durch Änderungen am Xserver benötigen einige Grafikkarten den Bootparameter nomodeset oder einen prop. Treiber: http://wiki.ubuntuusers.de/Bootoptionen [03:13] da stehts https://wiki.ubuntuusers.de/Bootoptionen/#Haeufig-genutzte-Bootoptionen [03:13] Title: Bootoptionen › Wiki › ubuntuusers.de (at wiki.ubuntuusers.de) [03:13] ahja [03:13] Rochvellon: quiet und splash würde ich mal rausnehmen testweise [03:14] okay ein moment [03:14] aber an der gleichen stelle dann das nomodeset rein [03:14] verstanden [03:14] also bei der 16-er version? [03:14] ich seh grade dass es da 5 verschiedene hardwarerevisionen für dein board gibt. das syslog verrät leide rnicht welchjes du hast [03:15] S4ndm4nn: egal ob 16.04 oder 18.04 [03:15] https://www.gigabyte.com/us/Search?kw=GA-970A-UD3 [03:15] Title: Search Results - GIGABYTE U.S.A. (at www.gigabyte.com) [03:16] rev.1.2 [03:17] hmm tja, schon recht in die jahre gekommen [03:17] ja leider [03:18] also ubuntu 16 mit nomodeset passiert das gleiche wie davor auch - bootschleife [03:19] aber schon mies, selnbst für das rec 3.0 board rückt gigabyte keine biosupdates mehr raus, trotz meltdown [03:19] hmm bootschleife is doof ;) [03:19] ich hab jetzt auch nicht den chatverlauf hier durchgelesen, war mir bisschen zu viel [03:20] bei ubuntu 18 heißt es wieder ewig warten [03:21] sehe auch lage zeit nichts bis auf die hintergrundfarbe vom grub [03:21] tomreyn: in Kürze: 16.04 macht dauernd Probleme, vermutlich wieder der nvidia-Treiber, daher will S4ndm4nn auf 18.04 und das braucht ewig zum Starten [03:22] für eine ssd viel zu lange [03:22] ~20min nach heutige messung [03:22] Selbst für eine mit rotierenden Scheiben, sofern das nicht ein Server mit einem fetten Programm ist [03:23] 18.04.0 oder .1? [03:23] 17.04.0 [03:23] hab shcon die neuste geladen [03:24] wäre aber schon interessant den grund zu finden bevor ich das neue aufspiele [03:24] die 18.04.0 macht mit älteren intel-gpus dieses problem dass es ewig dauert zu booten mit dem, ich glaube patchlevel 29 des kernels [03:25] also liegt es an der grafikkarte? [03:25] das ist eine regression die durch ein security-patch eingeführt wurde. das gab es änderungen den random number generator betreffend [03:26] nee, das wovon ich spreche ist ein bug. [03:26] ob das bei dir wirklich der auslöser ist kann ich natürlich nur raten, aber das betraf viele [03:26] also ist es ein bekannter fehler [03:26] ja, da gibts nen bugreport zu [03:26] bin ich kein sonderfall [03:27] bin kurz afk, wenn das system hochfährt meld ich michzurück [03:29] hm, tomreyn, könnte das auch an iommu liegen? Weil ich im 16.04er-Log auch noch las, dass das offenbar im BIOS nicht aktiviert ist [03:30] den hier meinte ich https://bugs.launchpad.net/ubuntu/+bug/1779827 [03:30] Title: Bug #1779827 “failure to boot with linux-image-4.15.0-24-generic...” : Bugs : Ubuntu (at bugs.launchpad.net) [03:31] betrifft aber nur diese kernelversion +/-1 [03:32] Rochvellon: denke nicht, wobei nvidia da recht fiese dinge mit dem ram macht, aber wenn das zu problemen führt gibts dazu fehlermeldungen im log. [03:33] iommu an schadet aber in der regel nicht, würd ich ruhig mal machen [03:33] zumal weil ja virtualbox installiert ist [03:38] re [03:39] beim nächsten rechner einfach mal amd graka kaufen, die haben nen open source treiber, da geht alles gleich viel einfacher, kein gefrickel mehr bei jedem upgrade [03:39] und trotzdem performance [03:39] jo, der Treiber soll gut sein [03:40] also nomodeset bei ubuntu 18 hat ebenfalls zu keinem fehler geführt [03:40] ähhh hat zu keiner lösung geführt [03:40] kein fehler, also läuft jett alles? ;) [03:41] sorry das kommt davon wenn die finger schneller sind als das hirn [03:42] was passiert denn bei nem normalen 18.04.1 boot? [03:43] ohne angepasste kernelparameter [03:43] absolut keine änderung [03:43] anders gefragt: was genau ist das problem? [03:43] wie stellt es sich dar? [03:45] das problem ist dass es eine halbe ewigkeit dauert bis das system hochfährt und seit heute schmeißt mich ubuntu nach dem login gleich wieder raus zum statusbild wo beim booten erschien [03:45] update: system ist hochgefahen ich logge mich eben ein [03:45] soll ich gleich ein update machen? [03:46] auf jeden [03:46] oder die syslog hochladen [03:46] weiss nicht wie lange es dauert bis ich rausgeworfen werde [03:47] alle ausstehenden updates installieren, rebooten, syslog + dmesg hochladen [03:47] S4ndm4nn: drück ctrl-alt-f3 und arbeite da [03:48] dann bist du nicht von X abhängig [03:48] http://paste.ubuntu.com/p/ckdQCCCXWx/ [03:48] Title: Ubuntu Pastebin (at paste.ubuntu.com) [03:49] jetzt zum update [03:55] tomreyn: zumindest schaut es für mich danach aus, dass diesmal der nvidia-Treiber korrekt geladen wird [03:56] Rochvellon: wirkt auf mich auch so, ja [03:56] ja das gibbts auch ein OK während dem botvorgang [03:57] ich tippe auf PRIME-probleme. würde mal die logs beschriebbar machen über die er sich da beschwert: sudo touch /var/log/prime-supported.log /var/log/prime-offload.log; sudo chown gdm /var/log/prime-supported.log /var/log/prime-offload.log [03:57] (das ist zeile 5294 f.) [04:00] tomreyn: schau Dir mal bitte die Zeiten in den Zeilen 3389 und 3390 an [04:01] oder war das ein Neustart? [04:01] das sit ein neustart, ja [04:02] bzw vielleicht auch shutdown + boot [04:02] aber es gibt da doch nvidia-fehlermeldungen [04:02] im aktuellen log [04:03] hatte diesen ewigen bootvorgang aber auch bevor ich die nvidia treiber installiert hatte [04:03] zumindest die prime-Logs sollten aber diesbezüglich keine Probleme sein [04:04] oh das sind ja alles immer noch linux 4.4er logs [04:04] ein aktuelles haben wir noch nicht, ne? [04:04] hihi [04:04] ah doch, sorry [04:04] verguckt [04:05] currnet operating system != build operating system [04:05] aber die updates laufen noch, ne S4ndm4nn ? [04:06] hmm neee die waren so schnell durch gelaufen war kaum was zu installieren [04:07] also ich wieder ins xwindow system zurück wollte war das bild schwarz und ist eingefroren [04:07] ah, gut zu wissen [04:08] also es ist nun version 18.04.1 drauf [04:09] okay, boote nochmal ohne quiet und ohne splash, aber auch ohne nomodeset. und guck ob du dabei spannende fehelrmeldungen bekommst [04:09] also bin jetzt gleich wieder im system habe nur mir nomodeset gebootet [04:10] soll ich nochmals neustarten? [04:12] ich guck immernoch aufs log, also wenn du nix wichtigeres zu tun hast, ja [04:12] du hast da diverse acpi exceptions, könntest mal das hier ausprobieren, hat aber wohl mit dem aktuellen problem nix zu tun: http://iam.tj/prototype/enhancements/Windows-acpi_osi.html [04:13] Title: Linux: ACPI: Fix problems with Suspend, Resume, and Missing devices using acpi_osi= (at iam.tj) [04:16] tomreyn: ich boote eben ohne den erwähnten optionen [04:17] ok [04:18] also bis jetzt tritt keine besserung oder änderung ein [04:20] Aug 4 05:12:01 cube kernel: [ 5.875846] gnome-shell[1020]: segfault at 20 ip 00007f813436e81d sp 00007fffb7e26c20 error 4 in libmutter-2.so.0.0.0[7f8134280000+156000] [04:20] den hatte ich vorhin übersehen [04:20] S4ndm4nn: postest du bitte nochmal dmesg wenn du ihn oben hast? [04:21] okay, sobald ich zugriff habe. macht es ein unterschied ob ich das system als UEFI installiere [04:22] ist wohl ein Problem von gnome [04:22] https://gitlab.gnome.org/GNOME/mutter/issues/190 [04:22] Title: Segfault at 20 libmutter-2.so.0.0.0 when executing docker run (#190) · Issues · GNOME / mutter · GitLab (at gitlab.gnome.org) [04:23] ist das jetzt eine gute oder eine schlechte nachticht? [04:24] eine gute nachtschicht [04:24] ja und nein. Ich gehe nicht davon aus, dass das ein Hardware-Problem ist, soweit die gute Nachricht [04:24] die gute ist wahrscheinlich dass der fehler bekannt ist und die schlechte das es nicht behoben ist [04:24] dass lasst aufatmen [04:25] also der da verlinkte bug 1767956 wurde behiben [04:26] das problem habe ich auch mit linux mint [04:26] https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1767956 [04:26] Title: Bug #1767956 “gnome-shell crashed with SIGSEGV in meta_gpu_kms_n...” : Bugs : gnome-shell package : Ubuntu (at bugs.launchpad.net) [04:26] aber na ja, es trat ja zumindest vor den letzten updates noch auf [04:27] !find libmutter-2.so.0.0.0 [04:28] hmm den bot gibts hier wohl nicht [04:28] Du könntest es auch mal mit KDE, XFCE, etc. probieren [04:28] sicher, aber ist eine alternative die ich ungerne wähle [04:29] ich mag gnome [04:29] :-D [04:29] hui, wenn man auf google einfach mal nur nach "libmutter-2.so.0.0.0" sucht, kriegt man ne menge fehlerberichte von nvidia-usern [04:31] sorry, ich hatte den ubuntu-bugreport falsch gelesen, der ist ja nochin bearbeitung [04:33] also ubuntu 18.04 hat libmutter-2-0 (3.28.1-1ubuntu1), im letzten post von https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1767956 steht dass mutter 3.29.90-1 das problem besietigt. und ganz oben steht bionic -> in progress, also ist der backport des patchs da noch nicht fertig. [04:33] Title: Bug #1767956 “gnome-shell crashed with SIGSEGV in meta_gpu_kms_n...” : Bugs : gnome-shell package : Ubuntu (at bugs.launchpad.net) [04:34] S4ndm4nn: bootest du noch oder lädst du noch das dmesg hoch? [04:35] ich wäre noch beim bootvorgang, scheint aber nicht immer hochfahren zu wollen [04:35] krass lange [04:36] von denen hier hast du viele "NVRM: Xid (PCI:0000:01:00): 56, CMDre 00000000 00000080 00006666 00000005 00002004" - und das sind kodierte fehlermeldungen des nvidia-treibers [04:36] ID 56 bedeutet laut https://docs.nvidia.com/deploy/xid-errors/ soviel wie "Display Engine error" [04:36] Title: XID Errors :: GPU Deployment and Management Documentation (at docs.nvidia.com) [04:37] ...was entweder ein hardware- oder treiberfehler sein kann [04:38] ohhhman, nichteinmal hochgefahren und die monitore sind auf standby [04:39] wieviele monitore sind denn da dran? zwi, ne? [04:39] *zwei [04:39] 3 monitore und 1 tv der aber inaktiv ist [04:40] aber alle ports sind belegt von der grafikkarte [04:40] ohhhh er ist hochgefahren [04:40] mach mal beim nächsten boot alle monitore bis auf einen ab, und guck ob das hilft. [04:40] befinde mich im login bereich [04:41] welche logs sollte ich nochmal hochladen [04:41] ich hätte immer noch gern ein "dmesg | pastebinit" bitte [04:41] okay kommt [04:41] S4ndm4nn: bzw besser "dmesg -T | pastebinit" [04:43] http://paste.ubuntu.com/p/T8gNbx8Nn3 [04:43] Title: Ubuntu Pastebin (at paste.ubuntu.com) [04:43] war da noch etwas? [04:45] S4ndm4nn: wo? [04:45] was ich hochladen sollte [04:45] S4ndm4nn: ah, die beiden nvidia-logs. aber nur wenn du die vorher angelegt hattest mit dem befehl den ich vorhin gepostet hatte [04:46] weil nur dann existieren sie [04:46] konnte ich leider nicht da das system seit dem letzten mal nicht hochgefahren war [04:48] S4ndm4nn: alles klar. du kannst also auf jeden fall mal zusätzlich ein anderes desktopenvironment installieren damit du (hoffentlich) erst mal arbeiten kannst. [04:48] ab wann wir denn der boot eigentlich so lahm? [04:49] äh kannste ignorieren, geht aus dme log hervor [04:49] da haben wir ihn wieder: [04:50] [Sa Aug 4 06:25:00 2018] gnome-shell[1065]: segfault at 20 ip 00007fe3eedde81d sp 00007ffe10458390 error 4 in libmutter-2.so.0.0.0[7fe3eecf0000+156000] [04:50] was heißt lahm, ich sehe im grunde nichts außer die hintergrundfarbe vom grub nach dem ich das system auswähle, dann dauert es sehr lange bis ich was auf dem schirm habe [04:51] [Sa Aug 4 06:24:59 2018] NVRM: Your system is not currently configured to drive a VGA console on the primary VGA device. The NVIDIA Linux graphics driver requires the use of a text-mode VGA console. Use of other console drivers including, but not limited to, vesafb, may result in corruption and stability problems, and is not supported. [04:53] S4ndm4nn: nomodeset mit ubuntu 18.04.1 hattest du probiert und es gab keine verbesserung, ne? [04:54] naja es ändert sich im grunde nichts außer das ich mal ein status check sehe aber sonnst bleibt alles wie bisher [04:55] so lange ich noch im system bin, braucht ihr noch welche files? ich würde sonnst neustarten und mal den tv abklemmen, hab mal gelesen dass ubuntu probleme mit 4 monitoren haben soll [04:56] aber das war allerdings bei eine alten version [04:56] S4ndm4nn: schalte mal wieder zum tty3 [04:56] bin drin [04:57] S4ndm4nn: dpkg -l gdm3 lightdm | tail -n2 [04:57] gibt was aus? [04:57] kannste direkt hier posten [04:58] ja [04:59] also am anfang steht kein paket gefunden, das auf lightdm passt [04:59] II gdm3 3.28.2-ubuntu1.2 amd46 GNOME Disply Manager [05:00] mehr nichts [05:01] S4ndm4nn: dann prbieren wir mal lightdm statt gdm, vielleicht hilfts ja: sudo apt install lightdm [05:02] das sollte ne abfrage zeigen wo du zwischen lightdm und gdm3 wählen kannst. da dann lightdm nehmen. [05:03] okay jetzt lightdm auswählen [05:03] was ist denn der unterschied [05:03] fertig...neustarten? [05:04] das sind die beiden verfügbaren grafischen logins [05:04] hast du die logdateien erstellt? [05:04] nein wie mach ich das? [05:05] ich tippe auf PRIME-probleme. würde mal die logs beschriebbar machen über die er sich da beschwert: sudo touch /var/log/prime-supported.log /var/log/prime-offload.log; sudo chown gdm /var/log/prime-supported.log /var/log/prime-offload.log [05:08] sin erstellt [05:08] na dann [05:08] ich könnt eigentlich mal schlafen gehen [05:09] soll ich neustarten? [05:09] yo. [05:09] mit allen monitoren? [05:09] deine entscheidung. ich würd's mal mit nur einem oder sogar komplett ohne probieren (aber das macht nur sinn wenn du nen ssh-server hast)+ [05:10] nee der ist hier nicht vorhanden [05:10] ich starte mal neu [05:10] mal sehen was passiert :-D [05:11] boote ich normal ohne was im grub zu ändern? [05:12] ja, mach das mal [05:12] wird aber wohl wieder das gleiche ergebnis haben [05:12] vielleicht schreibvt er ja was in die logs rein, da kannste nachher mal gucken [05:13] dazu muss ich ihn aber wieder hochfahren lassen dass was in die logs geschrieben werden kann [05:13] oder geschieht das bereits während dem langen bootvorgeng? [05:13] nee, eher am ende [05:14] du bist ja morgen auch wieder hier oder? [05:14] bzw heute abend [05:14] ich, und viele andere mehr ;) [05:14] aber kannst dich gern nochmal melden wenn du mir nochmal ne auffrischung vorbereitest um was es ging [05:14] verstehe aber ihr wisst ja schon was dem patienten fehlt [05:15] dann mal 'gute 'nacht'! [05:15] okay, gute nacht und vielen dank [05:15] bitte [05:17] Rochvellon: falls du noch da bist, die danke ich ebenfalls und wünsche dir auch eine gute nacht oder einen guten morgen [05:22] yw === nils_2_ is now known as nils_2 [08:22] moin [08:23] sagtmal, unter gnome3 geht keepassx "irgendwo auf dem Screen" auf, aber nicht im sichtbaren Bereich. Wahrscheinlich war es vorher auf dem grossen Bildschirm offen. Wie kann ich das zurück setzen? [08:40] keepassxc macht "gar nix" nachdem ich die DB, das keyfile und das pw angegeben hab? === nils_2_ is now known as nils_2 [14:06] ohh danke [14:06] ah, hat geklappt :) gut [14:06] habe ein kleines problem mit der virtualBox, habe Ubuntu normal installiert 16.04 auf der virtualBox win10. nach dem Update von win10 sind die gemeinsammen ordner weg :-( [14:07] kann da auch keine gasterweiterung installieren ist nur Hilfe oben angezeigt in der leiste [14:09] Herbert-51, ubuntu als host und windows als gast, verstehe ich das richtig? [14:10] ja [14:11] vor dem Update von win10 hat das alles geklappt :-( [14:11] Herbert-51, sieht man das freigegebene verzeichnis noch in den vm-einstellungen? schau da mal rein [14:12] hab ich schon. ist noch alles so drin [14:12] Herbert-51, dann musst du in windows viellleicht das "netzlaufwerk" neu hinzufügen [14:12] glaube so heißt das da [14:12] \\vboxsrv\ im explorer [14:13] da sollte dann deine freigabe auftauchen [14:13] was bei windows jetzt anders ist das oben in der leiste von der VM box nur noch Hilfe drinne steht [14:14] ??? [14:14] mach doch mal einen screenshot [14:14] upload bspw. auf imgur.com [14:20] also win findet kein netzwerk [14:21] screenshot ist garnicht so einfach :-( wo schmeißt er mir die hin wenn in auf windows bin :-( [14:22] unter windows landen die nur in der zwischenablage. muss man dann in paint o.ä. einfügen und abspeichern [14:22] aber ich meinte auch eher einen screenshot unter ubuntu [14:23] von der vm-leiste, die du meinst [14:25] ich meine die Menueleiste die von der VM noch geöffnet ist wenn windows gestartet ist. ganz oben stand immer noch Geräte (oder so ähnlich) da konnte man denn die Gasterweiterungen installieren [14:26] jo, genau. "gasterweiterungen einlegen" [14:27] https://imgur.com/a/Wkssv1g [14:27] Title: Imgur: The magic of the Internet (at imgur.com) [14:27] ja und da ist nix mehr :-( steht nur noch hilfe [14:28] die ordner sind noch angelegt und drin [14:29] Herbert-51, wenn du im vm-fenster bist, drück mal hosttaste+C (host-taste ist standardmäßig strg rechts) [14:29] Herbert-51, dann sollte das menü wieder auftauchen [14:40] ppq ja er zeigt mir ja das menue aber es steht nur Hilfe drin alles andere ist raus === jokrebel_ is now known as jokrebel [20:11] nabend. hatte ja hier berichtet, dass ich probleme mit meinen panels auf dem desktop habe. manchmal sind diese eine zeit lang nicht sichtbar nach dem booten, danach erscheinen sie. habe jetzt festgestellt, dass ich in der zeit, wo die panel nicht sichtbar sind, keinen zugriff auf meine windows-partition habe. in htop läuft dann immer ein prozess "/sbin/fstrim -av". inwiefern kann dieser trim-befehl denn damit [20:11] zusammenhängen, dass meine panel eine weile nicht sichtbar sind? wird die ssd evtl. nicht richtig davon unterstützt? könnte ich in diesem fall das "trimmen" einfach deaktivieren oder was könnte ich in dem fall machen? [20:12] auf der (einen) ssd in meinem system liegen: windows und / (root) des ubuntu [20:12] zitat aus dem wiki: "Ein gesondertes Setzen der Option für einen TRIM-Befehl ist ab Ubuntu 14.04 nicht mehr erforderlich. Dies wird über die Datei /etc/cron.weekly/fstrim erledigt." - das komische nur: bei mir gibt es keine datei "/etc/cron.weekly/fstrim". scheinbar wird die ssd aber dennoch per "online discard" - also automatisch - getrimmt? [20:16] es gab doch diesen befehl "systemctl. ..." mit dem man das nachvollziehen konnte (schade, dass dies im wiki komplett verschwiegen wird) [20:21] p01nt3r: welche ubuntu-verison hast du denn da? [20:22] 18.04 (mate) [20:22] und was für ne ssd? [20:23] adata sp 900 [20:24] 128 gb [20:25] hmm okay das scheint ein älteres modell zu sein [20:25] jap [20:26] ich suche grade die spezifikationen raus [20:27] habe gerade (wieder) festgestellt, dass mir "systemctl status fstrim.timer" die geplante trim-aufgabe anzeigt [20:27] und "journalctl -u fstrim.service" das Ergebnis. [20:28] ah sehr gut, das suchte ich auch grade [20:32] als die spezifikationen dafür sind nicht mehr online. aber laut geuzhals ist es 2D-NAND MLC • MTBF: 1 Mio. hours [20:32] über fstrim steht da aber nix [20:34] "journalctl -u fstrim.service" sagt mir jedenfalls, dass soundso viele GiB auf / sowie /windows getrimmt wurden - bleibt die frage, was man gegen die unbenutzbarkeit des systems während des trim-jobs tun kann - da dieser manchmal doch recht lange dauert und es nervt. [20:34] auf der libata-Blacklist sind sie nicht drauf, sollten also TRIM können, sowohl per native command queing als auch seriell https://github.com/torvalds/linux/blob/HEAD/drivers/ata/libata-core.c#L4556 [20:34] Title: linux/libata-core.c at 0b5b1f9a78b5e1bb3c3972fcd27dc013367550f8 · torvalds/linux · GitHub (at github.com) [20:35] ja, das ist grade bei älteren ssds ein bekanntes 'problem' [20:35] du könnest halt die zeit des jobs ändern schätze ich [20:35] so dass er dich nicht nervt. [20:35] aber das klappt auch nur dann wenn der rechner dann an ist [20:35] (nicht aus / im standby) [20:36] hmmm [20:36] was, wenn ich das ganz deaktiviere, was wäre die konsequenz? [20:36] p01nt3r: die ssd wird irgendwann kriechend lahm [20:37] wie wurde das denn vorher geregelt? [20:37] wovor? [20:37] bevor trim mir solche probleme bereitete, z.b. in 14.04? [20:37] bzw. 16.04 [20:38] ich tippe mal 14.04 hat ggf. noch gar nicht trim gemacht [20:38] 16.04 macht's über den cronjob den du in der doku gefunden hast [20:38] der sieht wie folgt aus: [20:38] und wieso gabs da nie probleme? [20:39] #!/bin/sh [20:39] # trim all mounted file systems which support it [20:39] /sbin/fstrim --all || true [20:43] p01nt3r: kannst ja mal in der servicedefinition gucken auf dem 18.04 wie da das fstrim gemacht wird [20:45] tomreyn, wie genau mache ich das? [20:48] p01nt3r: "systemctl status fstrim.timer" sagt dir wo der timer definiert ist. den kannst du dir angucken oder auch posten [20:49] "/lib/systemd/system/fstrim.timer" [20:49] p01nt3r: ich hab mal ne 18.04 VM gestartet. da sehe ich /lib/systemd/system/fstrim.timer und entsprechend dazu /lib/systemd/system/fstrim.service [20:50] letzteres enthält ExecStart=/sbin/fstrim -av [20:50] macht also exakt das gleiche, nur noch verbose dazu [20:51] insofern sollte sich da keine veränderung zwischen dem fstrim per cronjob uznd dem fstrim per systemd-service ergeben [20:52] komisch. [20:52] aber vielleicht ist deine ssd inzwischen insgesamt etwas behäbiger [20:52] kannst ja mal gucken was SMART dazu sagt [20:52] !smart [20:52] smart is https://wiki.ubuntuusers.de/Festplattenstatus/ [20:54] lol muss ich das etwa per root ausführen? [20:55] welche zeilen sind relevant? [20:57] tomreyn, wo sehe ich die infos, welches modell trim inwieweit unterstützt? [20:57] z.b. für eine kingston sv300 120 gb [20:59] p01nt3r: also trim unterstützen eiegentlich sämtliche ssd-modelle seit spätestens der zweiten generation. grundsätzlich sollte das in den hersteller-spezifikationen drin stehen. außerdem sollte es mit hdparm abrufbar sein [20:59] mit der hab ich in meinem 2. system keine probleme (beim gleichen os) [21:00] werde mal schauen, ob dort das trim auch aktiviert ist [21:00] und evtl. nochmal auf so eine ssd zugreifen [21:01] "hdparm -I /dev/X" ausführen und dabei X durch die entsprechende device node der SSD ersetzen [21:01] also z.b. /dev/sda [21:02] das zeigt dann entweder was mit "discard" oder mit "Data set Management TRIM" an [21:03] $ sudo hdparm -I /dev/sda | grep -Ei '(TRIM|discard)' [21:03] * Data Set Management TRIM supported (limit 8 blocks) [21:03] ^ beispiel von meiner samsung 850 evo [21:04] bei mir kommt da; [21:04] Data Set Management TRIM supported (limit 1 block) [21:04] Deterministic read data after TRIM [21:04] ja, also gehts, nur halt langsam [21:05] ansonsten poste doch mal "sudo smartctl -a /dev/X" mit X ersetzt durch die device node. [21:05] würde evtl. ein firmware-upgrade was bringen (falls es eines gibt)? [21:07] https://paste.debian.net/1036739/ [21:07] Title: debian Pastezone (at paste.debian.net) [21:07] vielleicht, vielleicht auch nicht, wie das halt bei firmware updates immer so ist. [21:07] und es wäre die frage, woher ich das bekomme ^^ [21:08] hersteller, wenn überhaupt. [21:08] ganz schön viele power cycles [21:09] 357 < unexpected power loss. machst du deinen rechner öfter einfahc mal aus? [21:10] also powerknopf gedrückt halten oder strom ziehen oder stromzufuhr kappen? [21:11] hmm scheint schon die neueste drauf zu sein, ist von 2014, wird wohl auch nicht mehr unterstützt. [21:11] ansonsten sieht das ok aus.kannst ja mal nen langen smart self test machen: sudo smartctl -t long /dev/X [21:12] tomreyn, eine zeitlang ja, da gabs probleme mit dem home nachdem ich was zerschossen hatte, habe es dann iwann sauber neu aufgesetzt (betraf konfig-dateien in der /home, machten das system unbenutzbar) [21:15] ist es normal, dass dann gleich wieder ein prompt da ist nach dem langen selbsttest? die ssd scheint nichts zu machen [21:15] also 260 mal ist ja schon recht viel. an sich sollte man das vermeiden. zum glück ist das bei ssd's nicht so schlimm wie bei festplatten. [21:16] ja, ist normal. der selbsttest wird nur angesto0en und dann nach ca. ner stunde ist er fertig [21:16] müsste die hdd-led jetzt nicht glühen? [21:16] du kannst dich mit "sudo smartctl -a /dev/sdX" nach dem status erkundigen. und wenn er irgendwann durch ist zeigt das auch unten ind er tabelle das ergebnis an [21:17] nee, der selbsttest der läuft relativ langsam so nebenbei, damit du noch arbeiten kannst. [21:18] und das die firmware den selbst veranstaltet kriegt der controller das auch gar nicht mit [21:18] -das [21:18] achso, es dringt also nicht nach aussen und somit leuchtet auch keine led [21:23] yo, die led ist ja ans mainboard verkabelt, da gibts so zwei pins wo die led bei bedarf strom her kriegt und dann leuchtet. [21:24] und ob sie strom kriegt entscheidet der sata-controller, der auf dem mainboard mit drauf sitzt. [21:24] die led wird also nicht von der ssd selbst gesteuert. [21:25] ist oft auch so bei internen hdd-bays, da leuchtet dann auch nix [21:25] grundsätzlich führen inzwischen viele 'bauteile' im computer ein eigenleben, sind z.t. eigene mini-computer mit eigenr cpu und eigenem arbeitsspeicher. das gilt auch für SSDs und festplatten. [21:26] die machen dann gerne mal irgendwas irgendwie und verraten dem recht des computers darüer ggf. gar nix [21:27] das das meist alles proprietärer code ist der da läuft (firmware blobs) weiß man dann in der regel auch nicht was die da machen [21:27] die sache wird scheinbar immer undurchdringlicher ... [21:28] "60% of test remaining." [21:31] diese werte sind nicht sehr verlässlich. einfahc immer mal wieder gucken. nach 1-2 stunden sollte es vorbei sein [21:32] wollen wir das morgen mal zusammen auswerten? [21:34] oh ich sehe grade dass ich verpielt hab dass die firmware wohl nicht in der lage ist die ergebnisse des tests dazustellen [21:34] XD [21:34] zeile 83 sagt das aus https://paste.debian.net/1036739/ [21:34] Title: debian Pastezone (at paste.debian.net) [21:34] aber es kann auch sein dass das ne fehlinformation ist und da nach abschluss des tests dann ne weitere tabelle angezeigt wird [21:34] einfahc malabwarten [21:34] jo k [21:35] kannst ja morgen nochmal die ergebnisse posten hier [21:35] ok mach ich, danke! [21:37] büdde. und ich bin mal ne weile wech.