Verhalten von journalctl eigenartig

[ayla]

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.

[bevo]

@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 

Code Select Expand

[ok] Mounted /media/disk1part4


Merkwürdig, dass ein anderes System das gleiche Problem hat.
Der letzte Eintrag dort

Code Select Expand

[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.

[ayla]

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?

Code Select Expand

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.

Code Select Expand

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.

[bluelupo]

Hi bevo,

Code Select Expand


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):

Code Select Expand


# fsck -v -f -c /dev/sda1


Wichtig ist hier, das deine Partition nicht gemountet ist vor allem wenn Fehler gefunden und repariert werden.

[melmarker]

@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.

[bevo]

@bluelupo
fsck war auf beiden Systemen leider ohne Erfolg.



bevo

[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

[ayla]

@ 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:

Code Select Expand

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

[melmarker]

@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.

[bevo]

@ayla
1)

Code Select Expand

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)

Code Select Expand

root@december:/home/bevo# ls -ls /var/log/apt
ls: Zugriff auf /var/log/apt nicht möglich: Datei oder Verzeichnis nicht gefunden

[ayla]

Zu 3) Meditationspause... Das sind aber schon alle drei siduction- bzw. Debian basierte Systeme?

Code Select Expand

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" .

[bevo]

Ja , 1=rider on the storm, 2-one step beond, 3=december


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

Journal von 2

http://paste.siduction.org/20150607104825

[ayla]

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:

ifplugd.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 :

Cannot add dependency job, ignoring: Invalid request descriptor

bringt und auf dem anderen:

Starting 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.

[bluelupo]

Hallo zusammen,

die Meldung vom LVM ist harmlos und auch korrekt wenn kein LVM im System genutzt wird ;-)

Starting Activation of LVM2 logical volumes..
No volume groups found

[bevo]

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