=== TheSphinX_ is now known as TheSphinX^
[07:36] <andre144k> hallo zusammen. kann man eventuell folgende crontab-regeln besser zusammenfassen?  https://paste.debian.net/1100999/
[07:36] <le_bot> Title: debian Pastezone (at paste.debian.net)
[07:40] <k1l_> */10 ist alle 10 minuten
[07:41] <k1l_> oder du schreibst alle minuten mit komma hintereinander
[07:46] <andre144k> oki...
[08:32] <tojoko> Guten morgen allerseits.
[08:33] <tojoko> Ich habe ein Problem. Bei mir ist anscheinend ein update fehlgeschlagen. ich kann den alten Kernel booten, aber nicht den aktuellen. Und nu? Kann ich den wieder entfernen?
[08:34] <drc> Kannst du, aber das ist wahrscheinlich eher keine saubere Lösung
[08:34] <drc> Was passiert denn, wenn du den neuen Kernel bootest?
[08:35] <tojoko> nix. schwarzer bildschirm. ich dachte ev. mit sudo purge-old-kernels - angeblich entfernt er ja niemals den laufenden.
[08:39] <tojoko> na, ich probiere es ev. einf. nochmal.
[08:45] <k1l_> besser wäre im log zu gucken wo es genau hakt bei dem kernel, der nicht booten will.
[08:45] <drc> wäre es, aber ist schon weg
[08:45] <k1l_> tjo
[09:48] <doev> 258 Software-Pakete können aktualisiert werden.  <- apt-get dist-upgrade findet aber nicht ein Paket. ??
[09:52] <Frickelpit> doev: Was sagt denn ein apt list --upgradable
[09:52] <doev> https://wiki.ubuntuusers.de/Archiv/apt/Problembehebung/#Anzahl-zu-aktualisierender-Pakete-beim-Konsolenlogin-falsch
[09:52] <le_bot> Title: Problembehebung › apt › Archiv › Wiki › ubuntuusers.de (at wiki.ubuntuusers.de)
[09:52] <doev> hat geholfen.
[09:52] <doev> Frickelpit, da kommt eine leere Liste.
[09:52] <Frickelpit> i see
[10:13] <tojoko> re
[10:31] <drc> tojoko: hast du mal  im Log geguckt, was beim neuen Kernel schiefläuft?
[10:32] <drc> Wenn nicht, versuch den mal zu booten, start dann neu (mit dem alten) und pack die Ausgabe von `sudo journalctl --boot=-1` in einen Pastebin
[10:56] <tojoko> journalctl not found :(
[11:03] <tojoko> ach, ich habe noch eine idee.
[11:28] <tojoko> re
[11:31] <tojoko> Das letzte, was mir beim Bootup angezeigt wird, ist [    0.119377] Measured 2574506330 cycles TSC warp between CPUs, turning off TSC clock.
[11:31] <tojoko> [    0.119385] tsc: Marking TSC unstable due to check_tsc_sync_source failed
[11:39] <drc> tojoko: wasn das für ein ubuntu?
[11:42] <tojoko> drc, 14.04.06 ;)
[11:48] <tomreyn> tojoko: das ist seit april nicht mehr supported, es sei denn du nutzt canonicals' ESM.
[11:51] <tomreyn> i weiß nicht genau wofür "TSC" steht aber es bezieht sich auf die Zeitmessung, die für jedes Betriebssystem extrem wichtig, und bei deinem System leider derzeit gestört ist.
[11:51] <tomreyn> "time stamp counter"
[11:52] <tojoko> tomreyn, danke, aber weder sagt mir canonicals etwas, weiter wurde mir empfohlen, auf die long term supports zu setzen und last but not least funktioniert ja genau dieses System - nur eben nicht mit diesem Kernel.
[11:52] <tomreyn> tojoko: Canonical(.com) ist die Firma hinter Ubuntu.
[11:53] <tomreyn> auf long term support zu setzen ist häufig ne gute entscheidung. aber auch lange supportzeiträume endedn halt irgendwann, und bevor das passiert muss man upgraden.
[11:54] <tomreyn> du kannst aber auch jetzt noch upgraden, vermutlich sogar problemlos über den 'normalen' weg, mit do-release-upgrade
[11:56] <tojoko> tomreyn, nee, danke, danke. Upgraden will ich nicht. Das system fass ich nicht mehr an. Es wird ersetzt. Ich dachte halt, ich könnte es noch ein paar Tage nutzen. und die eigentliche frage war, kann ich mich darauf verlassen, dass sudo purge-old-kernels --keep 1 -qy nicht den aktuell laufenden entfernt. :)
[11:56] <tomreyn> ich kenne keine software namens "purge-old-kernels"
[11:58] <tomreyn> ah, das ist teil von byobu, interessant (und etwas komisch). Unter Ubuntu 18.04 sagt die man page dazu "This utility is now deprecated.  The functionality it used to provide should be integrated into apt(8)."
[11:59] <tomreyn> und die man page wurde am 30 Apr 2012 zuletzt aktualisiert, vermutlich sieht sie dann bei dir genauso aus.
[11:59] <tojoko> tomreyn, oh, sorry. Wurde mal als die option empfohlen, alte, unnötige Kernel sauber zu entfernen.
[12:00] <tojoko> tomreyn, blöd ist halt, dass ich noch nicht einmal im recovery modus in die shell starten kann, sonst würde ich das system unter dem neuen kernel einfach nochmal updaten - das hat mir schon zumindest einmal den A... gerettet.
[12:00] <tojoko> so, muss mal kurz zu ner behörde.
[12:01] <tomreyn> aber mit dem alten kernel startet das system ja noch, dann ist ja erst mal alles gut, ne?
[12:02] <tojoko> tomreyn, ja - nur updaten auf den nächsten kann ich nicht, weil kein platz. deshalb würde ich den kaputten gerne entfernen. :)
[12:11] <tomreyn> ah kein platz, das ist dann wahrscheinlich auch warum der kernel kaputt ist.
[12:12] <tomreyn> dpkg -l | grep ^linux-    zeigt dir installierte kernelpakete und andere an der kernelversion orientierte pakete, die du ebenfalls entfernen kannst, wenn sie älter sind.
[12:14] <tomreyn> korrektur: dpkg -l | grep '^ii  linux-'
[12:14] <tomreyn> entfernen kannst du diese mittels   dpkg --purge PAKETNAME   (also dem was in der zweiten spalte der ausgabe steht)
[12:26] <tojoko> tomreyn, danke, wow - da kommt doch einiges zusammen.
[13:30] <doev> ich habe in der fstab eine Zeile die ungefähr so aussieht: //fs/share /mnt cifs credentials=/root/share.smb,auto 0 0 .... Wird das booten pausiert, wenn das Share nicht zur Verfügung steht, oder womit muss ich rechnen?
[14:01] <tojoko> viel los ist hier zur Zeit ja anscheinend nicht.
[14:04] <doev> tojoko -> #ubuntu-de-offtopic  das ist ein besserer Ort zum rumhängen.
[14:04] <tojoko> doev, ah, ok danke
[14:11] <drc> doev: ja, das sollte beim booten hängen
[14:12] <doev> drc, dann ist es schlecht.
[14:12] <drc> du solltest nofail und eventuell x-systemd.device-timeout setzen
[14:12] <drc> x-systemd.device-timeout braucht einen parameter, x-systemd.device-timeout=5 oder so
[14:13] <doev> besser wäre, wenn mein Backup-Script versucht zu mounten und falls dieses dann funktioniert das Backup macht. Andernfalls abbricht.
[14:13] <doev> aber, ob ich das hinbekomme?
[14:14] <drc> dann willst du eher https://wiki.ubuntuusers.de/Autofs/
[14:14] <le_bot> Title: Autofs › Wiki › ubuntuusers.de (at wiki.ubuntuusers.de)
[14:14] <drc> das benutze ich für genau diesen zweck
[14:14] <drc> bisschen gefummel, aber wenn es erstmal läuft, ziemlich cool
[14:16] <doev> drc, danke ich schaue mir das mal an.
[14:19] <drc> Alternativ kann systemd sowas auch, mit mount- und automount-Units
[14:19] <drc> Das hab ich aber noch nicht benutzt, weiß nicht, wie gut das funktioniert
[14:20] <doev> wichtig wäre halt, dass das Backup nur läuft, wenn das Share gemountet ist.
[14:20] <drc> Sieht spontan einfacher aus, aber er weiß
[14:24] <drc> Wie machst du denn dein Backup?
[14:39] <doev> drc, Ich denke da an einen Cronjob direkt für den Benutzer postgres.
[14:39] <doev> pg_dump oder pg_dumpall
[14:39] <drc> na, dann kannst du ja einfach vorher testen, ob der mounpoint da ist
[14:40] <doev> ja, muss mich halt mal wieder ins bash-Scripting reinlesen. Wird ja mit einem einfach IF und dem entsprechenden Befehl getan sein.
[14:41] <drc> jo
[14:41] <drc> oder du nimmst systemd-mount, machst das backup zu einem systemd-timer mit abhängigkeit auf den mount
[14:42] <doev> Hauptsache, der Datendump ist sicher, dann kann ich mir ein weiteres Backup für die Kiste sparen.
[15:29] <doev> hätte jetzt nicht gedacht, dass autofs so umfangreich ist. Ich glaube das wird heute nichts mehr.