Warnung: Libreswan kann Ihren Bootprozess stören – F29

Argss! Ja Argss! Da upgraded man 7800 Schritte lang seinen Desktop-PC auf ein Fedora 29, das auf den Servern ohne Probleme eingespielt werden konnte, auf dem Tablet und Laptop läuft, wo es exakt so per DNF eingespielt wurde, nur um dann festzustellen, daß das System nicht mehr bootet! Warum? Weil das Libreswan Paket wohl „defekt“ ist. ARGS!

Da tust Du alles um sicher zu sein und dann das!

Von dem Gedanken, das mein Desktop schnell mal eben auf ein neues Fedora hochgezogen werden kann, habe ich mich ja schon vor Jahren verabschiedet. Seit 0AD da drauf ist, dauert allein das  Herunterladen der Paket 25 Minuten und mehr, und 7800 Updateschritte brauchen auch mit SSD Support so um die 2 Stunden. Also schnappt man sich das Tablet, während der Desktop sein Upgrade fährt und macht was sinnvolles.. Kernel Updates einspielen z.B. 😉

Irgendwann war auch der Desktop durch und das obligatorische „reboot“ war fällig. Getan, gewartet, Festplattenpasswort eingetippt und …. tod.

Weil sich das schwer beschreiben läßt, hier der Bootlogauszug dazu:

Jun 14 19:13:06 meinpc systemd[1]: Started Restorecon maintaining path file context.
Jun 14 19:13:06 meinpc systemd[1]: Started LSB: Init script for live image..
Jun 14 19:13:06 meinpc systemd[1]: avahi-daemon.service: Start operation timed out. Terminating.
Jun 14 19:13:06 meinpc systemd[1]: systemd-logind.service: Start operation timed out. Terminating.
Jun 14 19:13:06 meinpc systemd[1]: ModemManager.service: Start operation timed out. Terminating.
Jun 14 19:13:06 meinpc ModemManager[1625]: <info> Caught signal, shutting down...
Jun 14 19:13:06 meinpc ModemManager[1625]: <info> ModemManager is shut down
Jun 14 19:13:06 meinpc systemd[1]: rtkit-daemon.service: Start operation timed out. Terminating.
Jun 14 19:13:06 meinpc systemd[1]: accounts-daemon.service: Start operation timed out. Terminating.
Jun 14 19:13:06 meinpc systemd[1]: systemd-machined.service: Start operation timed out. Terminating.
Jun 14 19:13:06 meinpc systemd[1]: NetworkManager.service: Start operation timed out. Terminating.
Jun 14 19:13:06 meinpc systemd[1]: rtkit-daemon.service: Failed with result 'timeout'.
Jun 14 19:13:06 meinpc systemd[1]: Failed to start RealtimeKit Scheduling Policy Service.
Jun 14 19:13:06 meinpc systemd[1]: accounts-daemon.service: Failed with result 'timeout'.
Jun 14 19:13:06 meinpc systemd[1]: Failed to start Accounts Service.
Jun 14 19:13:06 meinpc systemd[1]: ModemManager.service: Failed with result 'timeout'.
Jun 14 19:13:06 meinpc systemd[1]: Failed to start Modem Manager.
Jun 14 19:13:06 meinpc systemd[1]: Started NTP client/server.
Jun 14 19:13:06 meinpc systemd[1]: Started Hardware Monitoring Sensors.
Jun 14 19:13:06 meinpc systemd[1]: Starting SYSV: Late init script for live image....
Jun 14 19:13:06 meinpc systemd[1]: Starting ABRT Automated Bug Reporting Tool...
Jun 14 19:14:37 meinpc systemd[1]: Failed to get initial list of names: Connection timed out
Jun 14 19:14:37 meinpc systemd[1]: systemd-logind.service: Failed with result 'timeout'.
Jun 14 19:14:37 meinpc systemd[1]: Failed to start Login Service.
Jun 14 19:14:37 meinpc systemd[1]: systemd-machined.service: Failed with result 'timeout'.
Jun 14 19:14:37 meinpc systemd-coredump[1749]: Due to PID 1 having crashed coredump collection will now be turned off.
Jun 14 19:14:37 meinpc systemd[1]: Caught <ABRT>, dumped core as pid 1748.
Jun 14 19:14:37 meinpc systemd[1]: Freezing execution.
Jun 14 19:14:37 meinpc kernel: printk: systemd: 61 output lines suppressed due to ratelimiting
Jun 14 19:14:37 meinpc systemd-coredump[1749]: Process 1748 (systemd) of user 0 dumped core.

Stack trace of thread 1748:
#0 0x00007fa4b3f9087b kill (libc.so.6)
#1 0x00005583475eeeda n/a (systemd)
#2 0x00007fa4b4133070 __restore_rt (libpthread.so.0)
#3 0x00007fa4b3f9057f raise (libc.so.6)
#4 0x00007fa4b3f7a895 abort (libc.so.6)
#5 0x00007fa4b3fd39c7 __libc_message (libc.so.6)
#6 0x00007fa4b3fda2cc malloc_printerr (libc.so.6)
#7 0x00007fa4b3fdbafc _int_free (libc.so.6)
#8 0x00007fa4b4066ac7 __vasprintf_chk (libc.so.6)
#9 0x00007fa4b43d0630 log_format_iovec (libsystemd-shared-239.so)
#10 0x00007fa4b43d0b09 log_struct_internal (libsystemd-shared-239.so)
#11 0x0000558347610a0f n/a (systemd)
#12 0x00005583476132cb n/a (systemd)
#13 0x000055834766368e n/a (systemd)
#14 0x000055834763fb3b n/a (systemd)
#15 0x00005583476436aa n/a (systemd)
#16 0x0000558347626eed n/a (systemd)
#17 0x00007fa4b4455f02 n/a (libsystemd-shared-239.so)
#18 0x00007fa4b4457da5 sd_event_dispatch (libsystemd-shared-239.so)
#19 0x00007fa4b4457f30 sd_event_run (libsystemd-shared-239.so)
#20 0x00005583476300f6 n/a (systemd)
#21 0x00005583475ea78b n/a (systemd)
#22 0x00007fa4b3f7c413 __libc_start_main (libc.so.6)
#23 0x00005583475ec41e n/a (systemd)

So, jetzt sitzt der User da und hat kein System mit dem er was machen könnte, weiß nicht, was da nicht ging und hat natürlich auch kein Backup gemacht, von dem der User jetzt eh nicht wüßte, wie er es in dem Zustand zurückspielen sollte 🙂

Was also machen ?

  1.  Resetknopf drücken, wenn alle Festplattenindikatoren aufgehört haben zu blinken.
  2.  Kernelbootmenü abwarten
  3.  „e“ drücken, und die Zeile „linux ……“ um “ 1 init=/bin/bash“ am Ende erweitern, ggf. noch „splash quite rghb“ entfernen,  damit man bei nächsten boot was sieht.
  4.  STRG+x drücken
  5.  Jede Menge Kernel Meldungen laufen über den Bildschirm, wenn die aufhören, RETURN drücken.
  6.  /etc/init.d/network start
  7.  mount / -o remount,rw
  8.  dnf update

Jetzt wird uns dnf erzählen, daß crypto-policies wegen libreswan-libs nicht installiert werden kann. Das löst man so auf:

dnf erase libreswan*

es fliegen runter :

NetworkManager-libreswan-gnome-1.2.10-1.fc29.x86_64
NetworkManager-libreswan-1.2.10-1.fc29.x86_64
libreswan-3.27-1.fc29.x86_64

und jetzt kann man mit dnf update auch das letzte Paket für einen aktuelles Fedora installieren und oh Wunder, der Rechner booted wieder. Bugreport filed!

Hinweis: Dieses Problem wird natürlich nur ausgelöst, wenn man libreswan auch mal irgendwann installiert hatte 😉

Bitte lesen Sie auch das Update dazu : Update: Fedora 29 bootet nicht nach Upgrade

How To Linux – Backspace funktioniert nicht ?

Du hast eine Linux CHROOT eingerichtet und die Backspace-Taste funktioniert nicht ?

Anstatt nach links, rückt die nach rechts ?

Du hast /etc/ komplett in die Chroot kopiert, aber es hilft nicht ?

stty -a gibt in der Chroot genau das gleiche aus, wie in der realen Umgebung ? (wenn nicht => stty sane )

Dann solltest Du mal das machen :

cd /
tar c /usr/share/terminfo | tar x -C /opt/chroot/

(den Pfad muß man natürlich an seine Installation anpassen)

 

 

Linux – wenn ssh nicht portforwarden will

Wenn SSH Euren Port trotz richtiger Angabe der Parameter nicht forwarden will, könntet Ihr Opfer des Fortschritts geworden sein.

Das Problem

Der Befehl :

ssh -g -R *:24007:192.168.178.1:24007 root@remoteserver.de

sagt dem entfernen Server normalerweise, daß der Remote-Server einen Port 24007 für alle zugänglich auf 0.0.0.0 binden soll und alles was reinkommt, soll an die lokale IP 192.168.178.1 Port 24007 weitergeleitet werden.

Wenn das aber immer im Netstat auf 127.0.0.1 angezeigt wird:

tcp 0 0 127.0.0.1:24007 0.0.0.0:* LISTEN 13927/sshd: root@pt….

dann ist Eure SSHD-Config zu alt 🙂 Vor einigen Jahren wurde eine neue Option eingeführt, so daß der SSHD zwingend konfiguriert sein muß, globale Ports binden zu können.

Die Lösung

Fügt in die /etc/ssh/sshd_config  die folgende Zeile ein und startet den Dienst neu:

GatewayPorts yes

Damit darf der SSHD das wieder für Euch erledigen und die Tunnelwelt funktioniert für Euch wieder.

Das könnte auch interessant sein:

SSH VPN mit den iproute2 Tools
UDP Traffic per SSH tunneln
TAR erfolgreich per SSH tunneln

Tomcat: Manager App nicht verfügbar

Kleine Ursache, großes Tralala

Einer meiner Tomcats hat mich heute mit der Meldung beglückt, daß er die Resource „/manager/html“ nicht zur Verfügung stellen könne, obwohl die Anwendung installiert ist. Das ist ist immer, da diese zum Defaultzustand eines Tomcats dazugehört. Darüber lassen sich Webanwendungen als WAR File installieren.

Jetzt findet man im Netz alle erdenklichen Ansätze, leider half heute nicht einer.

Das erste was auffiel war, daß das Manager Verzeichnis zwar da war, aber die anderen normalen Verzeichnisse im webapps Verzeichnis  nicht:

drwxr-xr-x  5 root root     4096 13. Aug 2013  host-manager
drwxr-xr-x  5 root root     4096 13. Aug 2013  manager
drwxr-xr-x  3 root root     4096 18. Feb 2012  plattform
drwxr-xr-x  3 root root     4096 13. Aug 2013  ROOT

Wenn das nicht der Fall ist, kann es gehen, muß aber nicht. Diese holt man sich aus dem Tomcat ZIP/TGZ File. Wenn man dies nicht mehr zur Hand hat, einfach nochmal von der Webseite runterladen.

Die eigentliche Störungsquelle

Damit habe ich dann nicht gerechnet. Die eigentliche Störungsquelle war trivialer Natur. Die früher installierte Webanwendung war defekt und verhinderte den korrekten Start des Tomcats, obwohl im Logfile dazu kein Hinweis stand! Mit sowas rechnet man nicht, daß bis dato die Webanwendung lief.

In dem Fall einfach von Hand die alte WAR Datei aus dem Webapps Verzeichnis entfernen und den Tomcat neustarten.

Danach war auch der Manager wieder erreichbar.