Jessie Upgrade mit Problemen Systemd / Sysvinit

[Celica]

OK, habe noch einmal ein update & dist-upgrade laufen lassen.

Das führt alles zu nicht`s was systemd ans laufen bringt.

Alles andere ist nur Symptomdokterei.

Jetzt sind die Grubänderungen wirksam gewesen.
Das hätte ich dann sorüber lösen können, aber das ändert an der Sache nicht`s meiner Meinung nach.

Wenn da nicht die ultimative Lösung kommt, dann setze ich das System neu auf.
Das geht schneller wie alles andere was am Ende nur gefrikel ist.
War wohl zu heftig die Änderung von Wheezy auf Jessie.

Ich hasse Windows für so etwas und wenn das jetzt auch bei Linux anfängt ... aber ich glaube ja an das Gute

Habe all die Jahre über viel Spaß gehabt und wirklich ein tolles, stabiles und zuverlässiges System gehabt.
Da darf dann auch mal was außer der Reihe kommen.

Wenn jemand noch eine Idee hat wie ich Systemd ans laufen bekomme, dann probiere ich das gerne noch aus.

Mal am Rande:

Ich würde via Netinstaller aufsetzen wollen und hätte gerne XFCE4 als Desktop + ein paar andere Abweichungen die aber später kommen.
Ich habe gelesen das Tasksel mittlerweile ganz gut sein soll, habe aber in der Vergangenheit immer händisch installiert weil mir das einfach zu fett gewesen ist (zu viel drum herum).
Was empfiehlt sich den für einen XFCE4 Desktop der nicht ganz so überladen ist ?

Wie kann ich die meisten Einstellungen und Konfigurationen für meine Programme am besten beibehalten (eMail/Internet/...) ?

Ich freunde mich gerade schon einmal an

[guennid]

Abgesehen davon, dass ich mir durchaus nicht sicher bin, ob deine Probleme überhaupt durch systemd verursacht werden. Zumindest mit jessie geht's auch ohne systemd. (1)

Einen Rechner habe ich mit systemd upgegradet - außer den üblichen timeouts, die der mangelnden Anpassung geschuldet sind, war das problemlos. Die anderen Rechner fahre ich unter jessie/devuan nach wie vor mit sysvinit

(1) https://wiki.debianforum.de/Debian_ohne_systemd

[Celica]

OK, was müsste ich den machen um systemd loszuwerden (sauber) ?
Die Anleitung/Wiki habe ich gelesen.
Davon wird ja eher abgeraten habe ich gelesen.

Für die Zukunft wäre aber systemd doch die bessere/sauberere Lösung, oder ?

Ich möchte einfach nur ein sauber laufendes System was ich auch beim nächsten Mal sauber upgraden kann (so wie das bisher üblich gewesen ist).
Dann packe ich das lieber jetzt an und habe keine Probleme im laufenden Betrieb.

Habe bei meiner Frau ein Jessie mit systemd laufen und das macht keine Probleme, ist aber neu aufgesetzt wegen Rechnerwechsel.

Was ist die beste Lösung ?

[guennid]

Für die Zukunft wäre aber systemd doch die bessere/sauberere Lösung, oder?

Was ist besser und was ist sauber? Meine Debian-Systeme laufen bisher auch ohne systemd problemlos.

Inwieweit Debian das offenhalten wird, weiß man nicht. Erklärt wurde es. Aber systemd ist in Debian z.Z. als Standard gesetzt.

Wir kommen hier auf vermintes Gebiet. Und für Kriegführung bin ich schlecht gerüstet.

Musst du selbst entscheiden, was du willst.

[Celica]

Ich möchte ein sauberes System was rund läuft und nach Möglichkeit auch für für nächsten upgrades gerüstet ist.

Ich habe meinen Rechner jetzt wieder am laufen.
Fühlt sich aber merkwürdig an und habe jetzt schon das Gefühl als ob da was nicht rund laufen würde.

Allerdings gibt es mit Systemd ja noch ein paar mehr Einschränkungen bzgl. Gnome und XFCE4 wenn ich das richtig gelesen habe,was ich nicht so ganz verstehe.
Bei meiner Frau kann ich mit XFCE4 keine Einschränkungen erkennen und wie geschrieben läuft der Lapi mit Systemd ohne Probleme (von hausgemachten mal abgesehen .

Ich möchte hier bestimmt kein Glaubensjrieh anzetteln.
Dafür habe ich auch nicht ausreichend Wissen um mitreden zu können.

Darum geht es mir auch nicht.

Was müsste ich den befürchten wenn ich bei aufsetzen würde und XFCE4, später vielleicht auch GNOME, installieren möchte?

[guennid]

Was müsste ich den befürchten wenn ich bei aufsetzen würde und XFCE4, später vielleicht auch GNOME, installieren möchte?

Fehlt das was in diesem "Satz"?

Befürchten musst du gar nichts. Gnome wirst du wohl ohne systemd bei Debian gar nicht mehr aufsetzen können.

Wenn du möglichst wenig am System schrauben, manche sagen auch "frickeln", willst, bist du bei Debian mit systemd wahrscheinlich besser bedient.

Ih wollte nur aufzeigen, dass es immer noch auch ohne geht. Aber dann muss man sich reinhängen.

[edit] vergessene quote-tags eingefügt

[Celica]

Ja, danke. Hatte ich auch so verstanden.

Ich komme immer mehr zu dem Entschluss den Rechner einmal neu aufzusetzen.
In der Regel "schraube" ich nicht so viel an dem System herum.
Ich bin froh wenn alles rund läuft.

Stellen sich mir also ein paar Fragen:

XFCE4 von Hand nach einer Grundinstallation installieren, oder taugt die Auswahl während der Neuinstallation ?
Ich würde mein /home Verzeichnis auf meiner separaten HDD stehen lassen wollen und während der Neuinstallation mit einbinden.
Wie kann ich anschließend verhindern, dass sich alte Konfigdateien ins Gehege kommen wenn ich die Programme / Pakete Stück für Stück wieder installiere.

Auf der anderen Seite möchte ich mitunter z.B. für Icedove wieder den jetzigen Zustand herstellen.

[guennid]

Ich kann dir da nicht groß helfen, da ich offenbar ziemlich anders installiere als du. Schon grub nutze ich nicht. Mir reicht lilo.

XFCE4 von Hand nach einer Grundinstallation installieren, oder taugt die Auswahl während der Neuinstallation ?

Da du wenig "schrauben" willst, würde ich letzteres probieren. Ich weiß halt nicht, ob du in der Lage bist, einen xserver händisch zum Laufen zu bringen.

Und grundsätzlich: Immer ein Problem nach dem anderen angehen.

Ungereimtheiten in deinem ersten posting: Einmal geht nur der Standard-Kernel, dann wieder geht der überhaupt nicht. Und der verwendete Kernel hat mit der Frage systemd/sysvinit herzlich wenig zu tun.

Grüße, Günther

[Celica]

Am Anfang meines Beitrages wusste ich ehrlich gesagt noch gar nicht so Recht wo der Schuh drückt.
Ich konnte erst einmal nicht ohne weiteres starten.
Hatte mit dem Kernel wohl nix zu tun, sage ich mal jetzt.

Dann habe ich verstanden das systemd bei mir nicht funktioniert und ich deswegen die Auswahl des Images mit sysvinit machen musste, wobei ich ja auch geschrieben habe, dass ich mit dem ersten Eintrag von Hand X starten konnte. Da ist auch ein Widerspruch irgendwie drinnen

Einen Xserver würde ich schon zum laufen bekommen, aber wenn ich nach der Grundinstallation (so wie ich das immer gemacht habe) meine "xserver-xorg-video-intel" mit XFCE4 und ein bisserl mehr installiere, dann wäre das der schlanke Weg.
Aus der Netinstaller heraus bekommst du alles mit installiert was du nicht haben möchtest , dafür muss ich viel im Nachgang installieren.
Vielleicht probiere ich das einfach mal aus.

Grundsätzlich läuft mein System wieder, aber wie ich schon geschrieben habe, das fühlt sich nicht rund an und wenn systemd nicht wirklich läuft, dann gibt das vielleicht später Probleme.
Ich habe auch gesehen im Zuge meiner Anfreundung , dass sich viel unnützes Zeug angesammelt hat. Da wäre es vielleicht schon an der Zeit mal wieder Platte zu putzen !

Grub nutze ich halt schon recht lange. Hatte damit auch schon meine Berührungspunkte, aber in Summe bin ich schon sehr zufrieden damit. Braucht nicht jeder einen solchen Bootloader, dass verstehe ich auch.

Ich schlafe mal eine Nacht drüber und vielleicht beginne ich das neue Jahr mit einem neuen Rechner.

[rendegast]

'update-grub'

ausgeführt und neu gestarted.
Allerdings kann ich keine Veränderung sehen.
Der Rechner startet nach wie vor mit dem Image was nicht funktioniert und landet am prompt.

Es wird der beim Start gewählte Booteintrag in der Datei /boot/grub/grubenv hinterlegt und beim nächsten Start ausgelesen zur Vorgabe.
Dafür muß einmal mit dem "richtigen" Booteintrag gestartet werden.
(Tools für die händische Bearbeitung: grub-editenv, grub-set-default)

Gelegentlich hat grub ein Problem mit einer existierenden grubenv und verweigert das Schreiben derselben.
Ein Löschen der Datei kann da helfen.

find /etc -name "*dpkg*" | sort
/etc/bluetooth/audio.conf.dpkg-remove
/etc/bluetooth/rfcomm.conf.dpkg-remove
/etc/bluetooth/serial.conf.dpkg-remove
/etc/ca-certificates.conf.dpkg-old
/etc/sane.d/fujitsu.conf.dpkg-dist
/etc/slim.conf.dpkg-dist

Was sollte ich damit machen ?

Sichten und mit der entsprechenden aktuellen Version vergleichen.
Meistens eigene, durch den Upgrade-Mechanismus nicht übertragbare oder obsolete Optionswerte führen zum Erstellen solcher Dateien.

[guennid]

Am Anfang meines Beitrages wusste ich ehrlich gesagt noch gar nicht so Recht wo der Schuh drückt.

Kann ich sehr gut nachvollziehen. Da hilft nur: Gut überlegen: wie anfangen und wenn irgend möglich relevante Fehlermeldungen. Ansonsten wird der Thread dann leider manchmal zum gefundenen Fressen für Empörungs-Junkies.

[Celica]

Alles gut. Danke.
Werde heute alles so belassen wie es ist. Schließlich ist der Rechner ja zu benutzen.
Am letzten Tag im Jahr mache ich mir keinen Stress mehr.
Früher wäre mir das wichtig gewesen, heute liegen die Prioritäten wo anders.

Ich denke das ich in einer ruhigen Minute den Rechner neu aufsetze.

Ich wünsche hier allen einen guten Rutsch ins neue Jahr.

[Taomon]

Zeig mal das

Code: Alles auswählen

apt --dry-run purge libsystemd-daemon0:amd64 libsystemd-login0:amd64 

Habe ich bei mir nicht drauf und steht auch (deprecated) bei den Paketen in deiner Ausgabe.


Gruß Taomon

[Celica]

Hallo,

ich wünsche allen ein frohes neues Jahr.

Bevor ich das System neu aufsetze, wollte ich noch der Aufforderung aus dem letzten Beitrag nachkommen.

Code: Alles auswählen

root@debian:~# apt --dry-run purge libsystemd-daemon0:amd64 libsystemd-login0:amd64 
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.       
Statusinformationen werden eingelesen.... Fertig
Die folgenden Pakete werden ENTFERNT:
  libsystemd-daemon0* libsystemd-login0*
0 aktualisiert, 0 neu installiert, 2 zu entfernen und 1 nicht aktualisiert.
Purg libsystemd-daemon0 [215-17+deb8u5]
Purg libsystemd-login0 [215-17+deb8u5]

Hat aber keine Auswirkung auf mein eigentliches Problem bzgl. "systemd".

Trotzdem herzlichen Dank.

[guennid]

Mit --dry-run simulierst du lediglich eine Operation, ohne sie auszuführen. Auf gut deutsch also "Trockenübung"

Vermute, das war nicht bekannt, wenn doch, vergiss meinen Hinweis.

Der Parameter ist ziemlich überflüssig, da apt beim Removen immer nachfragt und Abbruchoption bietet. Aber na ja, an Parkinson-Leidende mögen das anders sehen.

[edit] Kommafehler

[DeletedUserReAsG]

So überflüssig ist der Parameter in bestimmten Situationen nicht.

Ansonsten würde ich auch sagen, dass ein sauberes Neuaufsetzen vielleicht Zeit und Nerven spart.

[Celica]

Alles gut. Danke. War ein Versuch wert.
Sollte da nicht noch ein Wunder geschehen, dann werde ich nächste Woche den Rechner einmal neu machen.

Fühlt sich einfach sauberer an
In der Hoffnung eine Investition in die Zukunft zu machen.

Eine Frage hätte ich noch: Ich hatte seiner Zeit mit UEFI zu kämpfen. Nicht das hier der Hund begraben ist.

[Taomon]

Der Befehl kann auch nix bewirken, war nur eine Simulation, da ich wie geschrieben die Pakete nicht drauf habe und die Abhängigkeiten nicht kenne.

Code: Alles auswählen

apt purge libsystemd-daemon0:amd64 libsystemd-login0:amd64 

Code: Alles auswählen

apt update && apt full-upgrade

Gruß Taomon

[Celica]

Letzteres hatten ich schon.
Wie schaut das mit UEFI aus?

[maledora4]

Wie schaut das mit UEFI aus?

Rein von der Logik her, ist die EFI doch weit "vor systemd/sysvinit" 'dran.

[Celica]

Hallo,

hatte gestern meinen Rechner dann neu aufgesetzt. War kein Problem. /home hatte ich dannn nach der Installation eingebunden und alles gut. Die alten Konfig Dateien konnte ich 1:1 wieder nutzen, Profile für Icedove und Iceweasel ebenso. Damit war das System ganz schnell wieder am Start.

Was ich aber herausgefunden habe: Bei dem Versuch meine NFS-Laufwerke wieder über die "fstab" einzubinden, hat sich exakt der gleiche Fehler eingestellt wie bei dem Upgrade von Wheezy zu Jessie. Der Start ist beim Eingabeprompt für Maintenance hängen geblieben.

Kurz überlegt was ich zuletzt konfiguriert hatte und dann bin ich auch drauf gekommen. Die NFS-Laufwerke in der "fstab" sind der Fehler. Das kann ich reproduzieren !

Code: Alles auswählen

#NFS Laufwerke
192.168.1.8:/home/christopher   /mnt/Netbook    nfs     user,noauto,timeo=14,soft,intr    0 0
192.168.1.6:/home/martina/       /mnt/T410    nfs     user,noauto,timeo=14,soft,intr      0 0
192.168.1.2:/srv/video/   /mnt/yaVDR1Video    nfs     user,noauto,timeo=14,soft,intr    0 0
192.168.1.2:/srv/share/vdr   /mnt/yaVDR1ShareVDR    nfs     user,noauto,timeo=14,soft,intr    0 0
192.168.1.4:/srv/share/vdr/   /mnt/yaVDR2/   nfs      user,noauto,timeo=14,soft,intr      0 0
192.168.1.4:/srv/video/   /mnt/yaVDR2Video/   user,noauto,timeo=14,soft,intr      0 0

Das habe ich schon in einem anderen Beitrag viewtopic.php?f=12&t=163604&p=1116391#p1116391 gepostet, da ich gerade keine Ahnung habe wie das in Jessie funktioniert die NFS-Laufwerke via AutoFS zu mounten.
Da gibt es ein Problem bzw. funktioniert das anders.

Meiner Meinung nach komplizierter und nicht wirklich Benutzerfreundlich, aber vielleicht klärt sich das auch noch.

Vielleicht habt Ihr eine Idee, oder sagt wie ihr das für euch gelöst habt.

Jedenfalls kann ich mit 99,9% Sicherheit sagen was mein eigentliches Problem gewesen ist bei dem Upgrade.
Damit ist eigentlich alles richtig gelaufen, nur habe ich nicht die NFS-Laufwerke auf dem Schirm gehabt.
Sicherlich auch irgendwo beschrieben, aber so tief stecke ich nicht in der Materie.

[TomL]

Das habe ich schon in einem anderen Beitrag viewtopic.php?f=12&t=163604&p=1116391#p1116391 gepostet, da ich gerade keine Ahnung habe wie das in Jessie funktioniert die NFS-Laufwerke via AutoFS zu mounten.

Mich wundert, wenn Du für Dich selber feststellst, dass Du "keine Ahnung von den Jsessie-Funktionalitäten hast" und gleichermaßen feststellst, dass eine unmittelbare systemd-Methode unter systemd "untauglich" oder "benutzerunfreundlich" ist. Es gibt natürlich verschiedene alternative Möglichkeiten, das zu lösen, auch welche, die ohne systemd funktionieren:

1. systemd deinstallieren und stattdessen wieder sysvinit zu verwenden. Da gibt es hier einen Fachmann für. Ob diese Lösung dann aber noch unter Stretch läuft ist für mich erst mal fraglich.
2. Jessie deinstallieren und dafür Wheezy installieren. Dann läuft auch wieder sysvinit. Wheezy hat noch bis 05.2018 LTS-Support
3. Einfach die vorgeschlagene Mount-Unit erstellen, mehrfach kopieren und das Problem als gelöst abhaken
4. Ein Script erstellen, welches die Mounts in Abhängigkeit der Netzwerkverfügbarkeit durchführt
5. Den zweifelhaften Versuch starten, mit einem Sleep 'sowieso' den Bootprozess zu blockieren und die Mounts in der rc.local durchzuführen, wobei da wieder die Möglichkeit besteht, dass es die rc.local in Stretch gar nicht mehr geben wird.
6. Die Mounts als Pam-Mount einzustellen, die durch/mit der User-Anmeldung erfolgen
7. Jeden einzelnen Mount in der fstab mit einem Requires-Boot-Blocker versehen, wie der aktiven network-online.target... wobei da nicht ganz klar ist, wie und wann der Network-Manager "Network is up" definiert.

[Celica]

OK, Sarkasmus verstanden ! Danke für den Hinweis

Ja, ich bin nur ein Mensch der privat Linux benutzt und auf Debian schwört ... und das schon recht lange.
Ich bin kein Profi (ganz, ganz weit weg davon!) und habe auch beruflich nicht`s damit zu tun.
Einfach nur interessiert an freier Software und dem drum herum.

... und ja, eine andere Distribution wäre für mich vielleicht besser geeignet die einem mehr abnimmt und mir das Leben einfacher macht, aber: Genau das war seiner Zeit der Grund warum ich von Suse & Co. über Red Hat (seiner Zeit) zu Debian gekommen bin. Ich wollte einfach mehr lernen.
... und ja, ich lerne jeden Tag und mit jeder Version neues. Das macht es auf der einen Seite nicht immer ganz einfach für mein Umfeld (in dem Fall die Menschen hier im Forum) und mich, aber es macht auch Spaß.
... und ja, die Einleitung und der vorzeitige Fazit waren vielleicht nicht ganz richtig, da Systemd ja eigentlich gearbeitet hat und Debian hier keine Schuld trifft.
An dieser Stelle auch noch einmal ein herzliches Dankeschön an alle Entwickler und Diejenigen, die daran teilhaben und das Projekt unterstützen. Eine tolle Sache die meinen allergrößten Respekt verdient !
Aber deswegen war es mir auch wichtig hier in diesem Beitrag noch einmal den eigentlichen Fehler zu posten, damit auch andere wie ich, die einfach nur die SuFi benutzen eine Spur erhalten.

Der Unterschied zu damals ist, dass ich heute (Familie, Beruf, Haus, ...) bei weitem nicht mehr so viel Zeit habe um mich mit den Themen zu beschäftigen und vielleicht auch mal ein paar blöde Fragen mehr poste und vielleicht mehr Hilfe benötige, aber deswegen werde ich Debian nicht den Rücken kehren.

... und ja, ich werde die "Mount-Units" ausprobieren, da wie du schon geschrieben hast, das wohl die beste Lösung zu sein scheint, zumindest meine Interpretation.
Wenn ich mich irre, dann nur zu
Ich bin offen !

[TomL]

... und ja, eine andere Distribution wäre für mich vielleicht besser geeignet die einem mehr abnimmt und mir das Leben einfacher macht, aber:

Das Problem ist bei allen Distributionen das gleiche, wenn sie systemd verwenden oder theoretisch vielleicht ein anderes Init-System einsetzen, welches ebenfalls soviel wie möglich gleichzeitig zu starten versucht. Dann muss der Anwender selber sicherstellen, dass seine von ihm nachträglich hinzugefügten Abhängigkeiten erfüllt sind. Ein Boot-System weiss erst Mal nichts von Deinen NFS-Laufwerken, es muss erst mal auch dann booten, wenn die gar nicht vorhanden sind. Und wenn du diese dem Init-System 'unbekannten' Laufwerke hinzufügst, muss Du dem Init-System auch mitteilen, wann es die bearbeiten darf.....ansonsten versucht es das einfach zum frühesten Zeitpunkt, den es selber bestimmt.... und genau da hakt es dann mit dem Netzwerk.

Ein weitere imho auch sehr einfache Alternative wäre für Dich ein einfaches Mount-Script. Da kannst Du alle Mounts ähnlich der fstab nacheinander eintragen. Aber auch dafür braucht es dann eine Systemd-Unit, um das Script zum passenden Zeitpunkt zu starten.

[rendegast]

#NFS Laufwerke
192.168.1.8:/home/christopher /mnt/Netbook nfs user,noauto,timeo=14,soft,intr 0 0
192.168.1.6:/home/martina/ /mnt/T410 nfs user,noauto,timeo=14,soft,intr 0 0
192.168.1.2:/srv/video/ /mnt/yaVDR1Video nfs user,noauto,timeo=14,soft,intr 0 0
192.168.1.2:/srv/share/vdr /mnt/yaVDR1ShareVDR nfs user,noauto,timeo=14,soft,intr 0 0
192.168.1.4:/srv/share/vdr/ /mnt/yaVDR2/ nfs user,noauto,timeo=14,soft,intr 0 0
192.168.1.4:/srv/video/ /mnt/yaVDR2Video/ user,noauto,timeo=14,soft,intr 0 0

Bei Deinem letzten Eintrag

192.168.1.4:/srv/video/ /mnt/yaVDR2Video/ user,noauto,timeo=14,soft,intr 0 0

fehlt 'nfs'.
Wohl die Ursache des Problems.




Die Einträge in meiner fstab erzeugen

/var/run/systemd/generator/local-fs.target.requires/mnt-yaVDR2Video.mount

/var/run/systemd/generator/mnt-Netbook.mount
/var/run/systemd/generator/mnt-T410.mount
/var/run/systemd/generator/mnt-yaVDR1ShareVDR.mount
/var/run/systemd/generator/mnt-yaVDR1Video.mount
/var/run/systemd/generator/mnt-yaVDR2.mount
/var/run/systemd/generator/mnt-yaVDR2Video.mount

also ein lokaler Mount, der dann ja nicht vollzogen werden kann.
Zudem in der erzeugten Unit
Type=user,noauto,timeo=14,soft,intr
Options=0
also invalide.

wish-bug: systemd resp. dessen Mount-generator prüft die Validität der Einträge und macht Meldung statt Bockmist.
'crontab' kann das ja auch.