Hallo zusammen,
bei einer meiner siduction Installation zeigt die Ausgabe des Journal via journalctl ein nicht nachvollziehbares Verhalten.
Zum Beispiel möchte ich mir alle Logmeldungen eines Zeitraumes anzeigen lassen (hier den kompletten April)
# journalctl -a --since="2015-04-01 00:00:00" --until="2015-04-30 23:59:59" --no-pager
[...]
Apr 05 22:27:11 shira systemd[6508]: Stopping Default.
Apr 05 22:27:11 shira systemd[6508]: Stopped target Default.
Apr 05 22:27:11 shira systemd[6508]: Stopping Basic System.
-- Reboot --
Eigenartiger Weise werden nur die Logmeldungen bis zum 5. April angezeigt. Wenn ich aber gezielt nach den heutigen Meldungen suche, sind die sehr wohl auffindbar.
# journalctl -a --since=today --no-pager
[...]
Apr 30 08:25:01 shira CRON[8700]: pam_unix(cron:session): session opened for user root by (uid=0)
Apr 30 08:25:01 shira CRON[8701]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1)
Apr 30 08:25:01 shira CRON[8700]: pam_unix(cron:session): session closed for user root
Wieso funktioniert das nicht mit dem ersten Kommando? Ist die Ausgabe auf eine max. Zeilenanzahl begrenzt?
Folgendes Problem konnte ich noch feststellen, das evtl. mit dem Journal zu tun haben könnte. Bis zum 5. April hatte ich im Journal eine Meldungen zu einen Kernel-Bug.
Apr 05 22:26:01 shira kernel: kernel BUG at /tmp/buildd/linux-siduction-3.19/drivers/gpu/drm/drm_crtc.c:536!
Ab dem 6. April hatte towo das im Kernel 3.19.3-towo.3 gefixtund ab diesen Datum wird auch das Journal korrekt angezeigt, egal welchen Zeitraum man wählt. Könnte als gut sein das der Kernelbug ein unzulässiges Zeichen im JOurnal hinterlassen hat und somit keine korrekte Anzeige mehr möglich ist.
Schau mal ob Dir irgendwelche Korruptheiten angezeigt werden mit journalctl --verify
Falls ja wäre das (so wie ich das bisher verstehe) kein Beinbruch, das kommt vor durch z.B Hardresets oder andere Störungen, das journal wird an der Stelle des korrupten Index rotiert, und man kann separat alles bis dorthin oder ab dort ansehen. Die genaue Stelle könnte man evtl am Ende des angegebene Files finden mit journalctl --file /var/log/journal/PfadZumFile.log
Oha, jede Menge "File corruption detected".
# journalctl --verify
PASS: /var/log/journal/39bbec808c774f5999d13c2d726b5095/system@00050ead9d6b3cdf-c5d51ab2a04fc061.journal~
PASS: /var/log/journal/39bbec808c774f5999d13c2d726b5095/user-1000@3b57de060a20401fad6ddfe19bee29e0-00000000000291e9-00051221c7a57942.journal
PASS: /var/log/journal/39bbec808c774f5999d13c2d726b5095/user-3000@2aff64e680ed4dc49c06d7181465ee89-000000000000f5c8-00050c5d3f494527.journal
PASS: /var/log/journal/39bbec808c774f5999d13c2d726b5095/user-2000.journal
PASS: /var/log/journal/39bbec808c774f5999d13c2d726b5095/system@e8b94c8111794efca6134cddc1e87d38-0000000000019360-00050ee9c4bd9762.journal
PASS: /var/log/journal/39bbec808c774f5999d13c2d726b5095/user-4000.journal
PASS: /var/log/journal/39bbec808c774f5999d13c2d726b5095/user-1000@3b57de060a20401fad6ddfe19bee29e0-0000000000019354-00050ee9c3e80242.journal
PASS: /var/log/journal/39bbec808c774f5999d13c2d726b5095/user-1000@000513008a7dae7d-2822a51896f30c41.journal~
PASS: /var/log/journal/39bbec808c774f5999d13c2d726b5095/system@e8b94c8111794efca6134cddc1e87d38-0000000000026975-00051158693a9d41.journal
PASS: /var/log/journal/39bbec808c774f5999d13c2d726b5095/system@7fe067debac14915ac884294763d115f-000000000000f03b-00050c4a76ac5bb6.journal
Invalid tail monotonic timestamp░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ 0%
File corruption detected at /var/log/journal/39bbec808c774f5999d13c2d726b5095/user-4000@900d051454494c5ca155d0ce3d628cd4-0000000000003e17-000509e1e2e88fff.journal:000000 (of 8388608 bytes, 0%).
FAIL: /var/log/journal/39bbec808c774f5999d13c2d726b5095/user-4000@900d051454494c5ca155d0ce3d628cd4-0000000000003e17-000509e1e2e88fff.journal (Ungültige Nachricht)
PASS: /var/log/journal/39bbec808c774f5999d13c2d726b5095/user-3000.journal
PASS: /var/log/journal/39bbec808c774f5999d13c2d726b5095/user-2000@0deeb51d57b441548862e40bf66671b5-0000000000026974-00051158693a8173.journal
PASS: /var/log/journal/39bbec808c774f5999d13c2d726b5095/user-2000@0deeb51d57b441548862e40bf66671b5-00000000000109ea-00050c9fe63c9a92.journal
PASS: /var/log/journal/39bbec808c774f5999d13c2d726b5095/system@6067aa1764c944c7a31dbb646fa8878b-0000000000000001-00051300591d8397.journal
PASS: /var/log/journal/39bbec808c774f5999d13c2d726b5095/system@7fe067debac14915ac884294763d115f-000000000000f0cf-00050c4d09e62944.journal
PASS: /var/log/journal/39bbec808c774f5999d13c2d726b5095/user-1000@c1e3bb764cab4089b456f5a2c38e2e4a-0000000000000a20-000513008a7eb214.journal
PASS: /var/log/journal/39bbec808c774f5999d13c2d726b5095/system@e8b94c8111794efca6134cddc1e87d38-000000000001de0d-00050fb06f34977d.journal
PASS: /var/log/journal/39bbec808c774f5999d13c2d726b5095/system@0005130024e20919-1ca1923a2245921e.journal~
1cdfe0: invalid entry item (0/26 offset: 000000███████████████████████████████░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ 49%
Invalid object contents at 1cdfe0: Ungültige Nachricht
File corruption detected at /var/log/journal/39bbec808c774f5999d13c2d726b5095/user-2000@000513000651cf13-03f0df2d38984007.journal~:1cdfe0 (of 8388608 bytes, 22%).
FAIL: /var/log/journal/39bbec808c774f5999d13c2d726b5095/user-2000@000513000651cf13-03f0df2d38984007.journal~ (Ungültige Nachricht)
Invalid tail monotonic timestamp░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ 0%
File corruption detected at /var/log/journal/39bbec808c774f5999d13c2d726b5095/user-4000@900d051454494c5ca155d0ce3d628cd4-000000000001ddfe-00050fb06e9eac3a.journal:000000 (of 8388608 bytes, 0%).
FAIL: /var/log/journal/39bbec808c774f5999d13c2d726b5095/user-4000@900d051454494c5ca155d0ce3d628cd4-000000000001ddfe-00050fb06e9eac3a.journal (Ungültige Nachricht)
PASS: /var/log/journal/39bbec808c774f5999d13c2d726b5095/user-3000@2aff64e680ed4dc49c06d7181465ee89-00000000000109f6-00050c9fe64ce87d.journal
PASS: /var/log/journal/39bbec808c774f5999d13c2d726b5095/system@e8b94c8111794efca6134cddc1e87d38-0000000000000001-00050ead9d097a84.journal
PASS: /var/log/journal/39bbec808c774f5999d13c2d726b5095/system@000513001402583b-7ef261cad484a1c2.journal~
Invalid tail monotonic timestamp░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ 0%
File corruption detected at /var/log/journal/39bbec808c774f5999d13c2d726b5095/user-1000@3b57de060a20401fad6ddfe19bee29e0-000000000001de13-00050fb08c3d7c1a.journal:000000 (of 8388608 bytes, 0%).
FAIL: /var/log/journal/39bbec808c774f5999d13c2d726b5095/user-1000@3b57de060a20401fad6ddfe19bee29e0-000000000001de13-00050fb08c3d7c1a.journal (Ungültige Nachricht)
PASS: /var/log/journal/39bbec808c774f5999d13c2d726b5095/system@000509a538b8b0af-911ecebc514f9eb9.journal~
Invalid tail monotonic timestamp░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ 0%
File corruption detected at /var/log/journal/39bbec808c774f5999d13c2d726b5095/user-1000@3b57de060a20401fad6ddfe19bee29e0-000000000000f0c1-00050c4d03bdd558.journal:000000 (of 8388608 bytes, 0%).
FAIL: /var/log/journal/39bbec808c774f5999d13c2d726b5095/user-1000@3b57de060a20401fad6ddfe19bee29e0-000000000000f0c1-00050c4d03bdd558.journal (Ungültige Nachricht)
PASS: /var/log/journal/39bbec808c774f5999d13c2d726b5095/system@000513005982e858-c9da13a70bba6883.journal~
PASS: /var/log/journal/39bbec808c774f5999d13c2d726b5095/user-1000@00051300439029e7-a053eb41bb4d55a1.journal~
Invalid tail monotonic timestamp░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ 0%
File corruption detected at /var/log/journal/39bbec808c774f5999d13c2d726b5095/user-3000@2aff64e680ed4dc49c06d7181465ee89-00000000000193b7-00050eea1ce7af69.journal:000000 (of 8388608 bytes, 0%).
FAIL: /var/log/journal/39bbec808c774f5999d13c2d726b5095/user-3000@2aff64e680ed4dc49c06d7181465ee89-00000000000193b7-00050eea1ce7af69.journal (Ungültige Nachricht)
PASS: /var/log/journal/39bbec808c774f5999d13c2d726b5095/system@e8b94c8111794efca6134cddc1e87d38-00000000000291f4-00051221c7c32793.journal
Invalid tail monotonic timestamp░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ 0%
File corruption detected at /var/log/journal/39bbec808c774f5999d13c2d726b5095/user-3000@2aff64e680ed4dc49c06d7181465ee89-0000000000004b7f-000509f1842e5335.journal:000000 (of 8388608 bytes, 0%).
FAIL: /var/log/journal/39bbec808c774f5999d13c2d726b5095/user-3000@2aff64e680ed4dc49c06d7181465ee89-0000000000004b7f-000509f1842e5335.journal (Ungültige Nachricht)
PASS: /var/log/journal/39bbec808c774f5999d13c2d726b5095/system@7fe067debac14915ac884294763d115f-000000000000f5d3-00050c5d3f679088.journal
PASS: /var/log/journal/39bbec808c774f5999d13c2d726b5095/user-4000@900d051454494c5ca155d0ce3d628cd4-000000000000f030-00050c4a7692166d.journal
PASS: /var/log/journal/39bbec808c774f5999d13c2d726b5095/system@7fe067debac14915ac884294763d115f-000000000000d60c-00050c130c1b6802.journal
PASS: /var/log/journal/39bbec808c774f5999d13c2d726b5095/user-2000@0deeb51d57b441548862e40bf66671b5-000000000001938c-00050ee9e5f08814.journal
PASS: /var/log/journal/39bbec808c774f5999d13c2d726b5095/system@0005130005bbc275-eb57e497cde2ae62.journal~
Invalid tail monotonic timestamp░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ 0%
File corruption detected at /var/log/journal/39bbec808c774f5999d13c2d726b5095/user-2000@0deeb51d57b441548862e40bf66671b5-000000000000321b-000509d752011876.journal:000000 (of 8388608 bytes, 0%).
FAIL: /var/log/journal/39bbec808c774f5999d13c2d726b5095/user-2000@0deeb51d57b441548862e40bf66671b5-000000000000321b-000509d752011876.journal (Ungültige Nachricht)
PASS: /var/log/journal/39bbec808c774f5999d13c2d726b5095/user-1000.journal
PASS: /var/log/journal/39bbec808c774f5999d13c2d726b5095/system@000512ab8488a5d0-ee52787fc02f401a.journal~
Invalid tail monotonic timestamp░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ 0%
File corruption detected at /var/log/journal/39bbec808c774f5999d13c2d726b5095/user-4000@900d051454494c5ca155d0ce3d628cd4-000000000000f126-00050c4dcd4a5602.journal:000000 (of 8388608 bytes, 0%).
FAIL: /var/log/journal/39bbec808c774f5999d13c2d726b5095/user-4000@900d051454494c5ca155d0ce3d628cd4-000000000000f126-00050c4dcd4a5602.journal (Ungültige Nachricht)
PASS: /var/log/journal/39bbec808c774f5999d13c2d726b5095/system@7fe067debac14915ac884294763d115f-0000000000000001-000509a53878f791.journal
PASS: /var/log/journal/39bbec808c774f5999d13c2d726b5095/system.journal
PASS: /var/log/journal/39bbec808c774f5999d13c2d726b5095/system@00050cb51b40c34c-430726518f819053.journal~
Invalid tail monotonic timestamp░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ 0%
File corruption detected at /var/log/journal/39bbec808c774f5999d13c2d726b5095/user-1000@3b57de060a20401fad6ddfe19bee29e0-0000000000000421-000509a5d669e42d.journal:000000 (of 8388608 bytes, 0%).
FAIL: /var/log/journal/39bbec808c774f5999d13c2d726b5095/user-1000@3b57de060a20401fad6ddfe19bee29e0-0000000000000421-000509a5d669e42d.journal (Ungültige Nachricht)
PASS: /var/log/journal/39bbec808c774f5999d13c2d726b5095/user-2000@00051300a342a018-ec4e97a1f425ccce.journal~
PASS: /var/log/journal/39bbec808c774f5999d13c2d726b5095/user-1000@000512afc68b2b6a-dc73b1c5d4d140e1.journal~
Hi bluelupo,
hast Du das Problem irgendwie gelöst?
Ich hatte gerade versucht mir mit einem journalctl -b -1 das journal meiner letzten session anzeigen zu lassen, da meine Kiste beim runterfahren eine Meditationspause einlegt.
Leider bekomme ich damit ein Journal von vor 14 Tagen angezeigt...
Ich vermute deshalb das gleiche Problem bei mir:
Quoteroot@neskaya:~# journalctl --verify
PASS: /var/log/journal/39bbec808c774f5999d13c2d726b5095/system@5ba1981e6a984177a2ffaec558110c1c-00000000000459fd-000513b16b0c6ad6.journal
PASS: /var/log/journal/39bbec808c774f5999d13c2d726b5095/system@5ba1981e6a984177a2ffaec558110c1c-0000000000045862-000513b16ae377e9.journal
PASS: /var/log/journal/39bbec808c774f5999d13c2d726b5095/user-1000.journal
PASS: /var/log/journal/39bbec808c774f5999d13c2d726b5095/system@00050ee319864716-64c0c8be3ac8c873.journal~
PASS: /var/log/journal/39bbec808c774f5999d13c2d726b5095/system@5ba1981e6a984177a2ffaec558110c1c-0000000000000001-00050ee31978e5b1.journal
PASS: /var/log/journal/39bbec808c774f5999d13c2d726b5095/system@5ba1981e6a984177a2ffaec558110c1c-0000000000070a24-00051618fd9b55c6.journal
Invalid tail monotonic timestamp░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ 0%
File corruption detected at /var/log/journal/39bbec808c774f5999d13c2d726b5095/user-1000@d40d2874bffd4044b9669079285425d2-00000000000238e5-00051148ff42573d.journal:000000 (of 8388608 bytes, 0%).
FAIL: /var/log/journal/39bbec808c774f5999d13c2d726b5095/user-1000@d40d2874bffd4044b9669079285425d2-00000000000238e5-00051148ff42573d.journal (Ungültige Nachricht)
Invalid tail monotonic timestamp░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ 0%
File corruption detected at /var/log/journal/39bbec808c774f5999d13c2d726b5095/user-1000@d40d2874bffd4044b9669079285425d2-00000000000459f2-000513b16b0c64dd.journal:000000 (of 8388608 bytes, 0%).
FAIL: /var/log/journal/39bbec808c774f5999d13c2d726b5095/user-1000@d40d2874bffd4044b9669079285425d2-00000000000459f2-000513b16b0c64dd.journal (Ungültige Nachricht)
PASS: /var/log/journal/39bbec808c774f5999d13c2d726b5095/user-1000@d40d2874bffd4044b9669079285425d2-0000000000000499-00050ee3cb9d2822.journal
PASS: /var/log/journal/39bbec808c774f5999d13c2d726b5095/system@5ba1981e6a984177a2ffaec558110c1c-00000000000238c2-0005114786d21ef0.journal
PASS: /var/log/journal/39bbec808c774f5999d13c2d726b5095/system.journal
Kann ich die logs einfach löschen und "von vorn" anfangen?
Gruß
ayla
/etc/systemd/journald.conf # begin
# See journald.conf(5) for details.
[Journal]
Storage=volatile
# end
way of non saving journals
Hi ayla,
du kannst mal probieren das Journal-Verzeichniss unter /var/log/journal komplett zu löschen (vielleicht erst mal wegmoven), dann sollte er wieder bei Null anfangen.
ok, hab die Antwort hier gefunden:
http://unix.stackexchange.com/questions/139513/how-to-clear-journalctl
Quote
- Edit /etc/systemd/journald.conf to set SystemMaxUse=1M
- Restarting journal: sudo systemctl restart systemd-journald
- Resetting SystemMaxUse=200M
- Re-Restarting the journal
after that:
Quotejournalctl --verify
PASS: /var/log/journal/39bbec808c774f5999d13c2d726b5095/user-1000.journal
PASS: /var/log/journal/39bbec808c774f5999d13c2d726b5095/system.journal
and journalctl -b -1 shows the last boot again, as expected.
ayla
@bluelupo: hatte das gerade durch während Du geantwortet hast :), trotzdem danke.
Eine Anweisung wie "jounalctl --clean" oder so wäre hilfreich.
Hi ayla,
ich weiß auch nicht mehr ganz genau wie ich das "gelöst" habe ;-) Ein korruptes Journal zu reparieren scheint es noch nicht zu geben, ich hab' auf jeden Fall nichts im Netz dazu gefunden.
Ein Bugreport der in diese Richtung geht existiert bereits:
https://bugs.freedesktop.org/show_bug.cgi?id=55239
Was ich mir dazu vor einiger Zeit dazu mal ergoogelt hatte war, dass das laut Poettering ein 'wontfix' ist. Die Meldung von korrupten Files beim --verify wäre demnach nur informativ, journalctl würde trotzdem soviel aus dem Journal recovern wie möglich ist, und eine repair-Option sei nicht angedacht:
https://bugs.freedesktop.org/show_bug.cgi?id=64116#c3
http://comments.gmane.org/gmane.comp.sysutils.systemd.devel/23136
hmm...
Ich vermute was Lennard Poettering da schreibt trift nicht wirklich den Punkt.
QuoteThere isn't really any point in deleting them. journalctl salvages
automatically everything it can when reading them. Since the files are
mostly append-only the corruptions usually only affect half-written
entries at the end, and hence all earlier once should just work.
Aus dem anderen, von mir verlinkten, Bugreport:
QuoteEssentially, journalctl's current behavior of pretending the
journal file ends at the first damaged region is unacceptable.
Das sieht mir eher nach dem hier aufgefallenen Verhalten aus.
Aber Poettering sagt ja auch: "alle Einträge vor dem Fehler sollten funktionieren",
wenn beide also doch das Gleiche meinen verstehe ich Poetterings Standpunkt nicht wirklich.
Journalctl hat nun mal z.B. die Option mit "-b -1" die Einträge des letzten boots anzuzeigen.
Wenn dies nur aufgrund korrupter Einträge, die vor dem letzten boot liegen, nicht mehr möglich ist
sollte der halbwegs unbedarfte Endnutzer auch eine Möglichkeit haben dies ohne größeren Aufwand
(z.B. 'ne Stunde googlen) zu reparieren, sprich journalctl sollte eine entsprechende
Bereinigungsfunktion anbieten oder sich halt am besten gleich selbst reparieren,
wie ja auch in den Bugreports vorgeschlagen.
"Wontfix" finde ich da -freundlich ausgedrückt- etwas abgehoben.
Und -wie ich irgendwo anders als "Reparaturmöglichkeit" gelesen hatte- einfach abwarten bis sich
das korrupte Log wieder von selbst löscht, scheint mir auch ne weniger brauchbare Alternative zu
sein -vor allem wenn ich kein "SystemMaxUse" gesetzt habe :)
Gruß
ayla
Ich habe alle Tips von Ayla bluelupo und ralul ausprobiert, leider ohne Erfolg.
Ich lande immer bei
Give root password for maintenance
(or press Control-D to continue):
bevo
Das klingt aber nicht nach "nur" einem fehlerhaften Journal.
Wann bekommst Du diese Nachricht (letzten 2-3 Zeilen davor) und was passiert wenn Du es mit STRG+D versuchst?
Muß ich abtippen da der Fehler auf einem anderen PC auftritt.
Welcome to emergency mode! After logging in type "journalctl -xb" to view
system logs, "systemctl reboot" to reboot, "systemctl default" or ^D to
try again to boot into default mode.
Die Zeilen davor sind alle ok.
wenn ich als root systemctl-default eingebe wird folgende Zeile ausgegeben:
Erro getting authority: Error initializing authority: Could not connect: No such file or directory (g-io-error-quark, 1)
danach wieder obige Zeilen.
Der Fehler tritt auch auf einem zweiten System nach dem letzten DU auf.
Dort habe ich bisher noch nichts geändert.
bevo
Für den "getting authority" error gibt es einen Bugreport, https://bugs.freedesktop.org/show_bug.cgi?id=89289, der polkit dafür verantwortlich macht.
Für Dein eigentliches Problem, den Abbruch des Bootvorgangs, fehlen Informationen um näheres sagen zu können. z.B. was Dein systemd gerade versucht hat zu starten oder zu überprüfen, was bei Deinem D-U upgedatet wurde, Zeitraum zwischen den letzten beiden D-U's.
@ayla
danke, dass Du dich da reinhängst.
Deine Fragen sind für mich schwierig zu beantworten. Zeitraum zwischen den DU's ca. 1 Woche. Was upgedatet wurde ???. Der output vom Bootvorgang wird alles mit ok gekenzeichnet, letzter Eintrag vor dem Abbruch [ok] Mounted /media/disk1part4
Merkwürdig, dass ein anderes System das gleiche Problem hat.
Der letzte Eintrag dort [ok] Reraches target Network is Online
Starting LSB: RPC portmapper replacement ....
Das System mit dem ich jetzt arbeite habe ich nicht updated um nicht in die gleichen Probleme zu kommen.
Na, mal schaun ob das Reinhängen was bringt :) , im Moment hab ich noch keine Ahnung was da bei Dir schief laufen könnte.
Kommst Du denn an Dein Journal dran wenn Du bei dem Abbruch das rootpasswort gibst?
journalctl -b -n 20 zeigt Dir die letzten 20 Zeilen. Möglicherweise kannst Du es auch in eine Datei pipen und anschließend aus einem Livesystem heraus wie unten beim history.log beschrieben behandeln. Also z.B. journalctl -b > /home/$dein_user/journaltext Wenns sein muß auch irgendwo nach /var/log, sollte home noch nicht zur Verfügung stehen.
An die Liste Deines letzten updates kommst Du relativ einfach, da es im Gegensatz zum Journal von systemd bereits eine Textdatei ist.
Livecd oder Stick anwerfen, Internetverbindung herstellen oder USB-Stick bereit halten und /var/log/apt/history.log des installierten Systems, nicht das der CD/stick, mit einem Editor anschauen/kopieren/per siduction-paste hochladen.
Hi bevo,
Give root password for maintenance
(or press Control-D to continue):
das sieht bei dir evtl. nach einen korrupten Filesystem aus. Dieser unfreiwillige Stop beim Booten ist weiter nicht so dramatisch, sondern soll deine Filesysteme vor weiteren Schaden schützen.
Lösung:
Starte ein Livesystem und führe ein fsck auf alle Dateisysteme die auf deinen System existieren durch.
Beispiel (an deine Gegebenheiten anpassen sdXY):
# fsck -v -f -c /dev/sda1
Wichtig ist hier, das deine Partition nicht gemountet ist vor allem wenn Fehler gefunden und repariert werden.
@ayla: Poetterings Standpunkt ist eigentlich recht einfach - vorausgesetzt, die Implementation von journald ist richtig:
* Korruption kann nur an Jounalenden vorkommen, weil Korruption nur passieren kann, wenn nicht sauber geschrieben wird - Stromausfall, Kernelpanic etc (ab dieser Korruption steht eh nur Grütze im Journal)
* journald erkennt das und schreibt nach einer Korruption in ein neues, sauberes File
* journald rekonstruiert nichts, sondern liest nur bis zur Korruption
* Ultima Ratio: Grütze repariert bleibt auch nur Grütze, da Grütze ;) - deswegen wird es kein Repair-Tool geben
Er hat in 0pointer ja auch irgendwo geschrieben, dass man sich die zerstörten Sachen auch mit anderen Tools anschauen könne, das aber auch recht sinnfrei sei, weil da dann wirklich nur Mist stehen würde, der nicht zu reparieren sei.
@bluelupo
fsck war auf beiden Systemen leider ohne Erfolg.
bevo
Es wird immer merkwürdiger :(
Ich mache wöchentlich D-U
1. System mit Fehler und diversem Rumprobieren nur alte history files von 2014
2. System mit Fehler ohne Änderungen history files vom 31.5.15
3. System (in use) kein history.log. Kein D-U nach Problemen mit 1. und 2. System , history.log mit Suchfunktion gesucht.
bevo
@ melmarker: Offensichtlich kann aber journald mit korrupten Einträgen nicht sauber umgehen, siehe bluelupos und mein Problem.
Dann mit einem Editor erst mal im conf-file rumfummeln bevor man die intakten logs wieder wie gewohnt anschauen kann ist ... reizend.
Wenn das vorkommen kann sollte es auch eine -einfache- Möglichkeit geben das wieder in Ordnung zu bringen.
@bevo:
1)
Aus dem Livesystem:
su
mount /dev/sd(Deine_installierte_root_Partititon) /mnt
ls -ls /mnt/var/log/apt
df -h
2) Das history.log vom 31.5. kann durchaus das aktuelle sein, apt packt die erst bei einer gewissen Größe zu einem .gz zusammen und beginnt ein neues.
3) Aus dem intakten system:
ls -ls /var/log/apt
@mods: vielleicht könnte man den thread splitten
@ayla: in dem Fall hilft dann nur eins - den guten Mann respektive die Entwickler mit aussagefähigen Bugs zuschmeissen.
Ich kann ja seine Argumentationskette nachvollziehen - nur dann muss halt journald wirklich so fehlerfrei sein, dass nur in definierten Situationen Grütze geschrieben wird - und diese Grütze muss dann auch wirklich fehlerfrei erkannt und ignoriert werden. Das Thema ist ja nicht erst seit gestern in der Diskussion.
@ayla
1)
root@siduction:/home/siducer# mount /dev/sdb1 /mnt
root@siduction:/home/siducer# ls -ls /mnt/var/log/apt
insgesamt 560
32 -rw-r--r-- 1 root root 30095 Okt 13 2014 history.log
16 -rw-r--r-- 1 root root 12421 Okt 2 2014 history.log.1.gz
12 -rw-r--r-- 1 root root 11845 Aug 29 2014 history.log.2.gz
12 -rw-r--r-- 1 root root 11007 Jul 26 2014 history.log.3.gz
12 -rw-r--r-- 1 root root 9260 Jul 1 2014 history.log.4.gz
12 -rw-r--r-- 1 root root 9630 Mai 27 2014 history.log.5.gz
12 -rw-r--r-- 1 root root 9856 Apr 24 2014 history.log.6.gz
20 -rw-r--r-- 1 root root 16753 Mär 31 2014 history.log.7.gz
164 -rw-r----- 1 root adm 160086 Okt 13 2014 term.log
40 -rw-r----- 1 root adm 39370 Okt 2 2014 term.log.1.gz
36 -rw-r----- 1 root adm 36372 Aug 29 2014 term.log.2.gz
40 -rw-r----- 1 root adm 37536 Jul 26 2014 term.log.3.gz
24 -rw-r----- 1 root adm 21434 Jul 1 2014 term.log.4.gz
32 -rw-r----- 1 root adm 31128 Mai 27 2014 term.log.5.gz
36 -rw-r----- 1 root adm 35778 Apr 24 2014 term.log.6.gz
60 -rw-r----- 1 root adm 57348 Mär 31 2014 term.log.7.gz
root@siduction:/home/siducer# df -h
Dateisystem Größe Benutzt Verf. Verw% Eingehängt auf
rootfs 3,5G 285M 3,2G 9% /
udev 10M 0 10M 0% /dev
tmpfs 779M 848K 779M 1% /run
tmpfs 1,2G 1,1G 108M 91% /fll/toram
/dev/loop1 1,1G 1,1G 0 100% /fll/siduction
tmpfs 3,5G 285M 3,2G 9% /fll/cow
aufs 3,5G 285M 3,2G 9% /
tmpfs 2,0G 0 2,0G 0% /dev/shm
tmpfs 2,0G 0 2,0G 0% /sys/fs/cgroup
tmpfs 100M 0 100M 0% /run/user
tmpfs 5,0M 0 5,0M 0% /run/lock
/dev/sdb1 20G 9,0G 9,6G 49% /mnt
2)
Ist richtig, an diesem System habe ich bisher nichts geändert (außer fsck)
3)
root@december:/home/bevo# ls -ls /var/log/apt
ls: Zugriff auf /var/log/apt nicht möglich: Datei oder Verzeichnis nicht gefunden
Zu 3) ??? Meditationspause... Das sind aber schon alle drei siduction- bzw. Debian basierte Systeme? inxi -S
Dann mach für eins und zwei aus dem live-system mal ein siduction-paste der beiden history.log's und poste die Links hier.
Wie siehts mit dem journal aus, kommst Du da, wie oben beschrieben, dran? Falls ja, ebenfalls jeweils ein siduction-paste der resultierenden Textdatei von "journalctl -b > /woauchimmer" .
Ja :) , 1=rider on the storm, 2-one step beond, 3=december
http://paste.siduction.org/20150607072004 (http://paste.siduction.org/20150607072004)
history.log von 1 bringt nichts, da alle Einträge von 2014 sind.
Journal von 1
http://paste.siduction.org/20150607074748 (http://paste.siduction.org/20150607074748)
Journal von 2
http://paste.siduction.org/20150607104825 (http://paste.siduction.org/20150607104825)
hmm.. Eine Lösung habe ich nicht, auch keine einigermaßen begründete Vermutung, wenn möglich könnte sich das mal jemand anschauen der mehr davon versteht.
Was ich gefunden habe ist dies:
Dein history.log zeigt daß Deine systemd-Version 220-2 ist.
Deine Journals zeigen bei beiden Systemen:
Quoteifplugd.agent[689]: Bad invocation: $INTERFACE is not set
net.agent[691]: Bad net.agent invocation: $INTERFACE is not set
Configuring network interfaces...warning: couldn't open interfaces file "/etc/network/interfaces"
Da gibt es einen Bug-Report https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=787263
Außerdem in unserem Forum http://forum.siduction.org/index.php?topic=5561.msg45523#msg45523 eine Meldung daß Ceni nicht mehr funktioniert.
Das sollte aber "eigentlich" nicht zum Abbruch des Bootvorgangs führen - wenigstens kann ich mit nicht vorstellen warum dies mehr zur Folge haben sollte als das eben das Netzwerk nicht funktioniert -es sei denn anschließend sollten noch irgendwelche Resourcen hinzugefügt werden.
Ein weiterer Punkt -von dem ich aber die "normalen" Meldungen nicht kenne, da ich es nach einer Neuinstallation immer purge, ist LVM2, welches Dir auf einem System die Meldung :
QuoteCannot add dependency job, ignoring: Invalid request descriptor
bringt und auf dem anderen:
QuoteStarting Activation of LVM2 logical volumes..
No volume groups found
Benutzt Du den Logical Volume Manager?
Sorry, keine weitere Idee, insbesondere keine zur Reparatur.
Gruß
ayla
EDIT:
Naja, was ich versuchen würde wenn ich nicht den Networkmanager benutzen würde, wäre mal nachzuschauen, ob da tatsächlich keine /etc/network/interfaces vorhanden ist, und falls nicht, diese von Hand anzulegen um zu schauen ob mein Bootvorgang dann weiter läuft.
Da aber bei Dir auch anscheinend mit apt was nicht stimmt wird das für mich zu komplex.
Hallo zusammen,
die Meldung vom LVM ist harmlos und auch korrekt wenn kein LVM im System genutzt wird ;-)
Quote
Starting Activation of LVM2 logical volumes..
No volume groups found
Danke für Eure Bemühungen :)
Dann werde ich mal neu installieren. :(
Bei meinem System 3 habe ich aus Vorsicht bisher kein D-U gemacht, um nicht in das gleiche Dilemma wie bei 1 und 2 zu geraten.
Nur für den Fall, daß bei 3 das gleiche passiert wie bei 1 und 2. Funktioniert ein gesichertes/geklontes System nach dem Zurückspielen auf die Originalpartition?
bevo
http://forum.siduction.org/index.php?topic=5322.msg43546#msg43546
In dem Thread findest Du verschiedene Möglichkeiten um mit dd ein komplettes Image zu erstellen und zurück zu spielen. Du möchtest wahrscheinlich den MBR mit sichern.
Es geht dort zwar um win7, funktioniert aber bei siduction genauso.
Eine eventuelle separate home-Partition solltest Du auch sichern, wegen der dort abgelegten Konfigurationsdateien des users, die u.U. mit upgedatet werden könnten. Glaube zwar nicht das es da im Moment ein Problem mit den .confs gäbe, aber sicher ist sicher.
Inzwischen ist übrigens systemd/udev 220-4 in unstable, bei welchem o.g. Netzwerkproblem gefixt sein soll.
Das System 2 konnte ich wieder zu Leben erwecken nachdem ich in der fstab die Zeile
usbfs /proc/bus/usb usbfs devmode=0666 0 0
deaktiviert habe.
Keine Ahnung warum und wieso da ein Zusammenhang ist. Zumal das System vor dem letzten D-U ja einwandfrei funktioniert hat.
Nochmal danke für die Unterstützung :)
bevo
Da gibts bei Arch einen Bug zu, allerdings für 219-2 und laut diesem sollte dies upstream gefixt sein...