[gelöst] Reparatur der "alten" Jessie

[TomL]

Moin

Vor 2-3 Wochen hatte ich meinem PC eine SSD gegönnt, um darauf das aktuelle, laufende OS zu installieren. Auf der SSD habe ich Stretch installiert, welches seit dem absolut zuverlässig läuft. Im PC ist natürlich jetzt auch noch die alte Harddisk installiert, auf der zum einen Jessie installiert ist, mit der ich die ganze Zeit zuvor gearbeitet habe. Und darüber hinaus war auf einer Mini-Partition Debian 9 LXDE installiert - damals aus Neugier, um mal zu testen. Auf der HD ist natürlich auch Grub installiert, welches beide Systeme starten konnte. So sieht das aus:

Code: Alles auswählen

SSD                    HD
sda->grub           sdb->grub
Startet alle 3      Startet die 2 HD-OS

sda1            sdb1            sdb3
Debian 9        Debian 8        Debian 9
Openbox         Openbox         LXDE

Aktuell ist grub als primärer "Booter" natürlich auf der SSD installiert. Das SSD-grub erkennt alle 3 OS und kann sie auch starten. Gleichermaßen kann ich aber auch über das Bios-F12-Menu direkt die Harddisk booten und mit dem dort installierten Grub die alte Jessie oder D9-LXDE starten. Das HD-Grub weiss allerdings nix von der SSD, ein update-grub werde ich auch nicht durchführen. Aber das ist nicht das Problem.

Nach der Installation der SSD und als das neue D9 schon eine Zeitlang lief, habe ich bereits mehrfach die "alte" Jessie von der Harddisk gestartet, um mal was zu testen, was nachzusehen, mit FreeFileSync (gibs leider noch nicht für D9) mein Backup zu prüfen, usw. Jessie von der HD ließ sich mehrfach problemlos starten. Bis gestern abend.

Seit gestern abend starten beide OS von der Harddisk nicht mehr. Und absolut sicher und ohne jeden Zweifel .... ich habe nix an denen verändert. Im aktuellen Stretch sind nicht mal diese beiden Partitionen gemountet.... ich wollte die auf jeden Fall erstmal untouched liegen lassen. Beide Systeme haben sich nicht mehr mit dem Netzwerk verbunden. Das System D9-LXDE konnte ich wieder in Betrieb reparieren. Jessie krieg ich nicht mit GUI gestartet. Das waren/sind die Symptome

- Jessie startet mit haufenweise Fehlermeldungen
- Der Bildschirm bleibt schwarz
- Die TTYs funktionieren
- Ich kann mich als root anmelden und auf Konsole arbeiten
- Ich kann mich nicht als User anmelden, es blitzt kurz was auf, dann erscheint wieder der Login-Screen
- Ich habe einen neuen Test-User angelegt, nur mit den skel-Files... das gleiche, Anmeldung nicht möglich
- Als root kann ich sogar mit startx openbox starten, der allerdings "uncustomized" ist

Einen Teil der Fehlermeldungen konnte ich beseitigen. Ich habe u.a. systemd-networkd deaktiviert, es war nicht möglich damit eine Netzverbindung zu öffnen. Nun ist wieder "networking" aktiviert und die "interfaces" eingerichtet. Die Netzwerkverbindung funktioniert wieder.

Das sehe ich jetzt im log:

Code: Alles auswählen

-- Logs begin at Fr 2016-12-30 11:55:16 CET, end at Mi 2017-02-22 16:59:09 CET. --
Feb 22 16:56:56 thomaspc avahi-daemon[1376]: open(/var/run/avahi-daemon//pid): Permission denied
Feb 22 16:56:56 thomaspc avahi-daemon[1376]: Failed to create PID file: Permission denied
Feb 22 16:56:57 thomaspc systemd-logind[1373]: Failed to enable subscription: The name org.freedesktop.systemd1 was not provided by any .service files
Feb 22 16:56:57 thomaspc systemd-logind[1373]: Failed to fully start up daemon: No route to host
Feb 22 16:56:57 thomaspc systemd[1]: Failed to start Login Service.
Feb 22 16:56:57 thomaspc systemd[1]: Failed to start Avahi mDNS/DNS-SD Stack.
Feb 22 16:57:15 thomaspc systemd[1]: Failed to start Light Display Manager.

Das war der Status von systemd-networkd.... das habe ich erstmal mit der "networking" umgangen

Code: Alles auswählen

● systemd-networkd.service - Network Service
   Loaded: loaded (/lib/systemd/system/systemd-networkd.service; disabled)
   Active: failed (Result: start-limit) since Mi 2017-02-22 11:01:38 CET; 1min 27s ago
     Docs: man:systemd-networkd.service(8)
  Process: 2020 ExecStart=/lib/systemd/systemd-networkd (code=exited, status=1/FAILURE)
 Main PID: 2020 (code=exited, status=1/FAILURE)

Feb 22 11:01:38 thomaspc systemd[1]: Failed to start Network Service.
Feb 22 11:01:38 thomaspc systemd[1]: Unit systemd-networkd.service entered failed state.
Feb 22 11:01:38 thomaspc systemd[1]: systemd-networkd.service has no holdoff time, scheduling restart.
Feb 22 11:01:38 thomaspc systemd[1]: Stopping Network Service...
Feb 22 11:01:38 thomaspc systemd[1]: Starting Network Service...
Feb 22 11:01:38 thomaspc systemd[1]: systemd-networkd.service start request repeated too quickly, refusing to start.
Feb 22 11:01:38 thomaspc systemd[1]: Failed to start Network Service.
Feb 22 11:01:38 thomaspc systemd[1]: Unit systemd-networkd.service entered failed state.

Auffällig ist diese Häufung von "permission denied"

Code: Alles auswählen

-- Logs begin at Fr 2016-12-30 11:55:16 CET, end at Mi 2017-02-22 11:04:18 CET. --
Feb 22 10:49:08 thomaspc avahi-daemon[1201]: open(/var/run/avahi-daemon//pid): Permission denied
Feb 22 10:49:08 thomaspc avahi-daemon[1201]: Failed to create PID file: Permission denied
Feb 22 10:49:10 thomaspc systemd-logind[1195]: Failed to enable subscription: The name org.freedesktop.systemd1 was not provided by any .service files
Feb 22 10:49:10 thomaspc systemd-logind[1195]: Failed to fully start up daemon: No route to host
Feb 22 10:49:11 thomaspc systemd[1]: Failed to start Login Service.
Feb 22 10:49:11 thomaspc systemd[1]: Failed to start Avahi mDNS/DNS-SD Stack.
Feb 22 10:49:29 thomaspc systemd[1]: Failed to start Light Display Manager.
Feb 22 11:01:03 thomaspc dhclient[1489]: receive_packet failed on eth0: Network is down
Feb 22 11:01:04 thomaspc dhclient[1952]: send_packet: Network is unreachable
Feb 22 11:01:04 thomaspc dhclient[1952]: send_packet: please consult README file regarding broadcast address.
Feb 22 11:01:04 thomaspc dhclient[1952]: dhclient.c:2331: Failed to send 300 byte long packet over fallback interface.
Feb 22 11:01:37 thomaspc systemd-networkd[2011]: Could not create manager: Permission denied
Feb 22 11:01:38 thomaspc systemd[1]: Failed to start Network Service.
Feb 22 11:01:38 thomaspc systemd-networkd[2014]: Could not create manager: Permission denied
Feb 22 11:01:38 thomaspc systemd[1]: Failed to start Network Service.
Feb 22 11:01:38 thomaspc systemd-networkd[2016]: Could not create manager: Permission denied
Feb 22 11:01:38 thomaspc systemd[1]: Failed to start Network Service.
Feb 22 11:01:38 thomaspc systemd-networkd[2018]: Could not create manager: Permission denied
Feb 22 11:01:38 thomaspc systemd[1]: Failed to start Network Service.
Feb 22 11:01:38 thomaspc systemd-networkd[2020]: Could not create manager: Permission denied
Feb 22 11:01:38 thomaspc systemd[1]: Failed to start Network Service.
Feb 22 11:01:38 thomaspc systemd[1]: Failed to start Network Service.

Ich habe nicht den leisesten Schimmer, was hier passiert sein kann..... und ich war definitiv nicht mit nem unpassenden Schraubenzieher irgendwo dran am rumschrauben. Wie gesagt, das funktionierte mehrfach, dann habe ich es ne Zeitlang nicht gestartet, und gestern abend das obige Ergebnis.

Hat jemand eine Idee, wo ich vielleicht mit weiterer Diagnose ansetzen könnte, um Jessie wieder ans Laufen zu bringen?

[scientific]

Ich seh hier mit Tapatalk leider die code-Tags nicht besonders gut...

Aber deine Problembeschreibung könnte auch eine volle Partition sein... Hatte so ähnliche Symptome auch vorgestern auf einer knapp bemessenen systempartition.

Wenn du als root von der Console reinkommst, führ

Code: Alles auswählen

 apt clean

aus... Das leert den cache von apt. Da kann gut und gern mal das eine oder andere GB frei werden...

Lg scientific

[TomL]

Aber deine Problembeschreibung könnte auch eine volle Partition sein...

Ich habs kontrolliert, das scheint es jedoch nicht zu sein. Auf der 200 GB-Partition ist Jessie in den knapp 2 Jahren auf gute 11 GB angewachsen. Also eigentlich Platz satt. Ausser dem OS und den user-confs im Home-Dir habe ich ja nie viel auf unseren Rechnern .... es geht ja alles auf den Server.

[schorsch_76]

Da wird das rootfs readonly sein. Du hast eine neue SSD drin. In der fstab hast du vermutlich sda oder so angegeben und keine UUID für die rootfs. Damit wird der grub bzw der Kernel dein rootfs nicht richtig zuordnen. Ich vermute dass der Kernel deine sda (vermutlich SSD) Platte versucht als rootfs zu mounten.

Stelle auf UUID um in allen Systemen.

Ich habe bsp /boot und grub von meinem Hauptsystem aus so gemountet:
UUID=xxxxxx /boot

"Subsysteme" aka Testversionen haben kein grub installiert aber der Kernel und initrd liegen auf der /boot. Bsp.
/boot/rt/vmlinux-xyz-rt

/boot -> /boot-part/rt
UUID=xxxxxx /boot-part

Die 40_custom im Hauptsystem hat Einträge für RT oder was auch immer.