[gelöst] Problem nach update jessie systemd

[peaceproject]

Hallo,
nachdem ich am 22.7.14 ein update in jessie gemacht habe, bleibt mein Rechner während des hochfahrens hängen und es erscheint folgende Meldung:

Code: Alles auswählen

Welcome to emergency mode! After logging in, type "journalctl -xb" to view
system logs, "systemctl reboot" to reboot, "systemctl default" to try again
to boot boot into default mode.
Welcome to emergency mode! After logging in, type "journalctl -xb" to view
system logs, "systemctl reboot" to reboot, "systemctl default" to try again
to boot boot into default mode.
Welcome to emergency mode! After logging in, type "journalctl -xb" to view
system logs, "systemctl reboot" to reboot, "systemctl default" to try again
to boot boot into default mode.

Danach wollte ich mit Hilfe einer Live-CD über chroot system-sysv deinstallieren und sysvinit-core installieren.

Nur wenn ich sysvinit-core installieren möchte, kommt folgende Meldung:

Code: Alles auswählen

The following packages will be REMOVED:
  brasero colord gdm3 gnome gnome-bluetooth gnome-color-manager
  gnome-control-center gnome-core gnome-disk-utility
  gnome-packagekit gnome-packagekit-session
  gnome-shell-extensions gnome-sushi gnome-system-log
  gnome-user-share gvfs gvfs-backends gvfs-daemons gvfs-fuse
  libpam-systemd nautilus nautilus-sendto network-manager
  network-manager-gnome packagekit packagekit-tools policykit-1
  policykit-1-gnome systemd-sysv udisks2
The following NEW packages will be installed:
  sysvinit-core
0 upgraded, 1 newly installed, 30 to remove and 31 not upgraded.
Need to get 0 B/130 kB of archives.
After this operation, 60,9 MB disk space will be freed.
Do you want to continue? [J/n] 

Hat jemand eine Idee, was ich tun kann, damit mein Rechner wieder normal bootet?

[peaceproject]

Ok, ich denke mal mein Problem hängt damit zusammen: Booting with lvm (especially with separate /usr) fails

Ich habe unter lvm2 unterschiedliche Partitionen angelegt.
/dev/mapper/home--tux-home
/dev/mapper/home--tux-tmp
/dev/mapper/home--tux-var
/dev/mapper/home--tux-usr
/dev/mapper/home--tux-root

Hat jemand eine Idee wie ich dieses Problem lösen kann?

[r4pt0r]

Mein Jessie-Notebook wollte nach dem Update bei dem auf systemd umgestellt wurde ebenfalls nicht booten - erstickte "irgendwann" beim einbinden der LVM-LVs.
Nach einem _ewig_ langen Timout (~4-5min!) kam ich automatisch in die systemd-rettungskonsole, über die zumindest fehleranalyse und ggf -behebung möglich ist. (auch wenn systemd weder WLAN noch NIC erfolgreich starten konnte -> pakete nachladen hätte nicht funktioniert)

Ursache war nur ein verwaister Eintrag in der fstab den virt-manager angelegt hatte, aber nach dem löschen der VM nicht mehr entfernt. Sobald eine Partition/LV nicht eingebunden werden kann scheint systemd komplett hilflos einfach abzubrechen (slebst wenn das laufwerk nicht "lebenswichtig" wäre).

Kontrollier mal diene fstab-einträge und entferne ggf mal alles was nicht unbedingt gebraucht wird. Nach dem (dann hoffentlich erfolgreichen) start gibt ein "mount -va" aufschluss über etwaige Probleme an denen systemd beim Starten scheitert...

So habe ich zumindest das Notebook mit LVM wieder zum laufne gebracht (allerdings nur mit separaten /boot, /root und /home LVs)

[peaceproject]

Hallo,
hier meine fstab

Code: Alles auswählen

# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
/dev/mapper/home--tux-root /               ext4    errors=remount-ro 0       1
/dev/mapper/home--tux-home /home          ext4    defaults        0       2
/dev/mapper/home--tux-tmp /tmp            ext4    defaults        0       2
/dev/mapper/home--tux-usr /usr            ext4    defaults        0       2
/dev/mapper/home--tux-var /var            ext4    defaults        0       2
/dev/sr0 /media/dvd auto rw,user,exec 0 0

[Nemissimo]

Ursache war nur ein verwaister Eintrag in der fstab den virt-manager angelegt hatte, aber nach dem löschen der VM nicht mehr entfernt. Sobald eine Partition/LV nicht eingebunden werden kann scheint systemd komplett hilflos einfach abzubrechen (slebst wenn das laufwerk nicht "lebenswichtig" wäre).

Kontrollier mal diene fstab-einträge und entferne ggf mal alles was nicht unbedingt gebraucht wird. Nach dem (dann hoffentlich erfolgreichen) start gibt ein "mount -va" aufschluss über etwaige Probleme an denen systemd beim Starten scheitert...

Guter Hinweis, vielen Dank. Bei mir standen in der fstab Einträge für /dev/sr0 und eine Netzwerkfreigabe, weil ich damit u.a. den Mount-Point festgelegt habe. Nach Auskommentieren beider Einträge klappt auch der Start mit systemd.

[peaceproject]

Guter Hinweis, vielen Dank. Bei mir standen in der fstab Einträge für /dev/sr0 und eine Netzwerkfreigabe, weil ich damit u.a. den Mount-Point festgelegt habe. Nach Auskommentieren beider Einträge klappt auch der Start mit systemd.

Vielen Dank Nemissimo, nachdem ich /dev/sr0 auskommentiert habe, klappt das hochfahren wieder wunderbar.
Also fstab war die Lösung.

[Nemissimo]

Vielen Dank Nemissimo, nachdem ich /dev/sr0 auskommentiert habe, klappt das hochfahren wieder wunderbar.
Also fstab war die Lösung.

Danke für die Blumen, aber der entscheidende Hinweis auf die fstab kam von r4pt0r - ich habe es nur ausprobiert, weil ich ja das gleiche Problem hatte...

[sCid]

Hallo zusammen,

ich bin neu hier und kein Linux Crack, seit einigen Jahren habe ich einen kleinen Fileserver worauf Debian als BS läuft. Vor kurzem habe ich wieder ein apt-get update und anschließend ein apt-get upgrade durchgeführt und jetzt habe ich ein ähnliches Problem wie peaceproject.

Mein Debian kommt nur noch mit "Welcome to emergency mode! After logging in, type "journalctl -xb" to view system logs, "Systemctl reboot" to reboot, "stemctl default" or ^D to try again to boot into default mode."

Die FSTAB habe ich via Knoppix angeschaut und auch versucht zu schreiben. Hatte da bisher keine UUID Einträge sonder die "Klassiker" /dev/sda1" ... etc. leider ohne Erfolg. Einmal habe ich die /dev/ Einträge auskommentiert und nur mit den UUIDs gearbeitet und anders herum

Via mdadm hatte bzw. habe ich zwei 2 TB Festplatte zusammengefasst /dev/sda1 und /dev/sdb1 zu einer. /dev/md0
das BS läuft eigentlich unter /dev/sdc1

jetzt habe ich mir dir die "journalctl -xb" angeschaut und dort ist folgender Eintrag in rot drin:
sd:4:0:0:0 [sdc] No Caching mode page found
sd:4:0:0:0 [sdc] Assuming drive cache: write through
sd:5:0:0:0 [sdc] Asking for cache data failed
sd:5:0:0:0 [sdc] Assuming drive cache: write through

Bin für jede Hilfe dankbar....

kurzer Nachbrenner...
kommentiere ich alles außer den neuen UUID Eintrag in der fstab aus fährt der Server ganz normal hoch, jedoch lässt sich apt-get update und nix anderes wirklich ausführen... Wie kann ich mein System retten?

Gruß sCid