16
Ubuntu startet nicht mehr
Moin,
ich habe in einer HyperV-Umgebung ein Ubuntu 16.04.3 laufen. Plötzlich fährt die VM nicht mehr hoch:
Jetzt hocke ich in der Shell und weiß nicht, was zu tun ist. Für meine Begriffe würde mir theoretisch das hier helfen:
https://www.linuxquestions.org/questions/linux-newbie-8/gave-up-waiting- ...
(Antwort von AwesomeMachine)
Boote ich nämlich mit der Installations-CD in den Rettungsmodus, kann ich die Partition /dev/sda1 mounten: mount /dev/sda1 /mnt
Schaue ich mir nun /mnt an, sehe ich auch meine Ubuntu-Installation.
Mittels cat /etc/fstab den Inhalt angesehen, dort fehlt der Eintrag für die Root-Partition samt passender UUID. Die UUID kann ich ebenfalls anzeigen (ls -al /dev/disk/by-uuid).
Frage: Ich gehe richtig in der Annahme, dass der Root-Eintrag in die /etc/fstab muss, damit das System wieder bootet? Nur, wie kriege ich den Eintrag dort hinein?
vi oder gedit funktionieren nicht.
EDIT: Bullshit, ich war im Installerverzeichnis. Die Einträge in der richtigen /etc/fstab scheinen korrekt.
Frage also: Wie kriege ich das System wieder zum Laufen?
Gruß
ich habe in einer HyperV-Umgebung ein Ubuntu 16.04.3 laufen. Plötzlich fährt die VM nicht mehr hoch:
Gave up waiting for root device. Common problems:
— Boot args (cat /proc/cmdline)
— Check rootdelay= (did the system wait long enough?)
— Check root= (did the system wait for the right device?)
— Missing modules (cat /proc/modules; ls /dev)
ALERT! /dev/SDC5 does not exist.
Dropping to a shell! Jetzt hocke ich in der Shell und weiß nicht, was zu tun ist. Für meine Begriffe würde mir theoretisch das hier helfen:
https://www.linuxquestions.org/questions/linux-newbie-8/gave-up-waiting- ...
(Antwort von AwesomeMachine)
Boote ich nämlich mit der Installations-CD in den Rettungsmodus, kann ich die Partition /dev/sda1 mounten: mount /dev/sda1 /mnt
Schaue ich mir nun /mnt an, sehe ich auch meine Ubuntu-Installation.
Mittels cat /etc/fstab den Inhalt angesehen, dort fehlt der Eintrag für die Root-Partition samt passender UUID. Die UUID kann ich ebenfalls anzeigen (ls -al /dev/disk/by-uuid).
Frage: Ich gehe richtig in der Annahme, dass der Root-Eintrag in die /etc/fstab muss, damit das System wieder bootet? Nur, wie kriege ich den Eintrag dort hinein?
vi oder gedit funktionieren nicht.
EDIT: Bullshit, ich war im Installerverzeichnis. Die Einträge in der richtigen /etc/fstab scheinen korrekt.
Frage also: Wie kriege ich das System wieder zum Laufen?
Gruß
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 366223
Url: https://administrator.de/contentid/366223
Ausgedruckt am: 04.12.2024 um 08:12 Uhr
16 Kommentare
Neuester Kommentar
Hi,
nur als Hinweis weil du von sdA sprichst...
Was ist sdC
~Arano
nur als Hinweis weil du von sdA sprichst...
Was ist sdC
ALERT! /dev/SDC5 does not exist.
~Arano
Hi Arano,
danke für die Antwort. Sorry, ich hatte blöderweise einen Text aus dem Netz kopiert, ohne genauer hinzuschauen. Klappt so natürlich nich.
Der korrekte Text ist hier (kann ich leider in der VM nicht kopieren)
Die UUID ist sda1, also der Root-Partition zugeordnet.
Gruß
danke für die Antwort. Sorry, ich hatte blöderweise einen Text aus dem Netz kopiert, ohne genauer hinzuschauen. Klappt so natürlich nich.
Der korrekte Text ist hier (kann ich leider in der VM nicht kopieren)
Die UUID ist sda1, also der Root-Partition zugeordnet.
Gruß
Hallo,
Ist da ein Update ueber das Ubuntusystem gelaufen? Weil wenn ja, koennte das ein Ausloeser sein.
https://ubuntuforums.org/showthread.php?t=2326179
Ganz am Ende des dortigen Thread. Musst es fuer Dich anpassen.
BFF
Ist da ein Update ueber das Ubuntusystem gelaufen? Weil wenn ja, koennte das ein Ausloeser sein.
https://ubuntuforums.org/showthread.php?t=2326179
Ganz am Ende des dortigen Thread. Musst es fuer Dich anpassen.
BFF
Nach dem Bild hast du bei der Diskette I/O Errors aber wenn du keine nutzt kannst du diese ja "Rauswerfen".
Du hast unten einen ALERT! das eine UUID nicht vorhanden ist was wohl deine Systempartition ist.
Da scheint dein Problem zu sein.
Starte mal ein Rescue System und lass mal FSCK laufen mit -f -v auf deine Platten und schau mal ob die UUIDs mit denen in der fstab auf deiner Systemplatte stimmen.
(Beachte das bei Änderungen/Reparatur vorher ein Backup Image gemacht werden sollte für den Fehlerfall)
Du hast unten einen ALERT! das eine UUID nicht vorhanden ist was wohl deine Systempartition ist.
Da scheint dein Problem zu sein.
Starte mal ein Rescue System und lass mal FSCK laufen mit -f -v auf deine Platten und schau mal ob die UUIDs mit denen in der fstab auf deiner Systemplatte stimmen.
(Beachte das bei Änderungen/Reparatur vorher ein Backup Image gemacht werden sollte für den Fehlerfall)
Danke Euch für die Anregungen.
@bff
Das einzige, was für mich passend war, war
update-initramfs -u -k 4.4.0-87-generic
--> Ist durchgelaufen, immer noch selber Fehler
@kaiand
Stimmt, Disklaufwerk schmeiße ich raus, wenn der Laden wieder läuft
fsck bringt leider auch nichts. So wie ich das verstehe, ist das auch weniger ein Problem mit dem Filesystem, als mehr mit dem Bootvorgang an sich.
@bff
Das einzige, was für mich passend war, war
update-initramfs -u -k 4.4.0-87-generic
--> Ist durchgelaufen, immer noch selber Fehler
@kaiand
Stimmt, Disklaufwerk schmeiße ich raus, wenn der Laden wieder läuft
fsck bringt leider auch nichts. So wie ich das verstehe, ist das auch weniger ein Problem mit dem Filesystem, als mehr mit dem Bootvorgang an sich.
Da die Kiste jetzt mal langsam wieder laufen muss und ich auch nach einigen Stunden keine Lösung gefunden habe: Datensicherung eingespielt, alles paletti. Die Fehlerursache kenne ich nicht, da ist kein Update des Betriebssystems gelaufen.
Was ich gerade noch gefunden habe (kann / will ich nicht mehr ausprobieren, da die Rücksicherung durch ist):
https://forums.bunsenlabs.org/viewtopic.php?id=1515
Klingt zumindest vielversprechend, vielleicht hat ja mal jemand ein ähnliches Problem. Oder ich hab das in drei Tagen wieder, dann muss ich mir nicht die Lesezeichen im Browser vollmüllen
Gruß
Was ich gerade noch gefunden habe (kann / will ich nicht mehr ausprobieren, da die Rücksicherung durch ist):
https://forums.bunsenlabs.org/viewtopic.php?id=1515
Klingt zumindest vielversprechend, vielleicht hat ja mal jemand ein ähnliches Problem. Oder ich hab das in drei Tagen wieder, dann muss ich mir nicht die Lesezeichen im Browser vollmüllen
Gruß
Hallo Coreknabe,
sollte das wieder auftreten, von einem RESCUE system starten und mit blkid prüfen,
ob die Festplatten in der VM die korrekten UUIDs haben, die in der /etc/fstab erwartet werden.
Siehe auch:
blkid
UUID
fstab
Allgemeines zu Laufwerksänderungen
grüße vom it-frosch
sollte das wieder auftreten, von einem RESCUE system starten und mit blkid prüfen,
ob die Festplatten in der VM die korrekten UUIDs haben, die in der /etc/fstab erwartet werden.
Siehe auch:
blkid
UUID
fstab
Allgemeines zu Laufwerksänderungen
grüße vom it-frosch
Hi Frosch,
auch Dir vielen Dank!
Obskures Verhalten: Nachdem ich die VM zurückgesichert hatte, habe ich mich eingeloggt. Es wurden Sicherheitsupdates installiert und der Server verlangte nach Neustart. Erledigt, danach war die VM wieder mit dem obenbeschriebenen Fehler lahmgelegt.
Erneutes Rücksichern, diesmal noch einen Tag zurück: Klappt. Ich beobachte mal, ob da ein Zusammenhang mit den Sicherheitsupdates besteht.
Deine Lösungsvorschläge behalte ich bis dahin im Hinterkopf.
Gruß
auch Dir vielen Dank!
Obskures Verhalten: Nachdem ich die VM zurückgesichert hatte, habe ich mich eingeloggt. Es wurden Sicherheitsupdates installiert und der Server verlangte nach Neustart. Erledigt, danach war die VM wieder mit dem obenbeschriebenen Fehler lahmgelegt.
Erneutes Rücksichern, diesmal noch einen Tag zurück: Klappt. Ich beobachte mal, ob da ein Zusammenhang mit den Sicherheitsupdates besteht.
Deine Lösungsvorschläge behalte ich bis dahin im Hinterkopf.
Gruß
Moin,
Update... Problem trat heute wieder auf.
"Lösung": Booten des Kernels 4.4.0-116 klappt nicht, boote ich den älteren Kernel 4.4.0-112, funktioniert es.
Die Einträge im Grubmenü für 116 und 112 habe ich mir angesehen, sind identisch, daran liegt es also auch nicht. Evtl. Kernelbug? Konnte bei Google hierzu allerdings nichts finden.
Verstehe allerdings immer noch nicht, warum das jetzt anderthalb Tage lief (VM wird nachts zur Sicherung herunter- und danach wieder hochgefahren).
Ich beobachte das weiter und poste hier, wenn es etwas neues gibt.
Gruß
Update... Problem trat heute wieder auf.
"Lösung": Booten des Kernels 4.4.0-116 klappt nicht, boote ich den älteren Kernel 4.4.0-112, funktioniert es.
Die Einträge im Grubmenü für 116 und 112 habe ich mir angesehen, sind identisch, daran liegt es also auch nicht. Evtl. Kernelbug? Konnte bei Google hierzu allerdings nichts finden.
Verstehe allerdings immer noch nicht, warum das jetzt anderthalb Tage lief (VM wird nachts zur Sicherung herunter- und danach wieder hochgefahren).
Ich beobachte das weiter und poste hier, wenn es etwas neues gibt.
Gruß
Hi,
ich kratze ja eigentlich immer nur an der Oberfläche.
Aber hast du "rootdelay" mal probiert ?
Vielleicht ist der neue Kernel schneller und das Device ist noch nicht vollständig initialisiert... (Oder der HyperV noch beschäftigt = verzögert/langsamer. Andere Backups, what ever)
https://unix.stackexchange.com/questions/67199/whats-the-point-of-rootwa ...
https://www.thomas-krenn.com/de/wiki/GRUB_Bootloader_bootet_nicht_von_LV ...
~Arano
ich kratze ja eigentlich immer nur an der Oberfläche.
Aber hast du "rootdelay" mal probiert ?
Vielleicht ist der neue Kernel schneller und das Device ist noch nicht vollständig initialisiert... (Oder der HyperV noch beschäftigt = verzögert/langsamer. Andere Backups, what ever)
https://unix.stackexchange.com/questions/67199/whats-the-point-of-rootwa ...
https://www.thomas-krenn.com/de/wiki/GRUB_Bootloader_bootet_nicht_von_LV ...
/etc/default/grub
30 Sek Verzögerung bevor Root eingebunden wird.GRUB_CMDLINE_LINUX_DEFAULT="quiet rootdelay=30"~Arano
Mahlzeit.
Nur so als Idee.
Hat die VM noch ein virtuelles CD/DVD-Laufwerk? Wenn ja schalte das mal ab.
Da gabs voriges Jahr mal Probleme mit, allerdings wenn die Sicherung ueber das laufende System gehen sollte.
BFF
Nur so als Idee.
Hat die VM noch ein virtuelles CD/DVD-Laufwerk? Wenn ja schalte das mal ab.
Da gabs voriges Jahr mal Probleme mit, allerdings wenn die Sicherung ueber das laufende System gehen sollte.
BFF
Moin,
@Arano
Die Links kenne ich schon, bringt nix. Sobald ich den Kernel -116 boote, kann die eigentliche Root-Partition nicht mehr eingebunden werden. Die korrekte /etc/default/grub wird entsprechend auch nicht eingelesen, da kann ich reinschreiben, was immer ich will.
@bff
Ich hatte auch schon das Diskettenlaufwerk entfernt, taucht trotzdem wieder auf, sobald ich den Kernel -116 boote. Siehe Antwort an @Arano, der verdaddelt irgendwie die korrekte Root-Partition
Wenn ich den Kernel -112 boote, läuft alles wie gehabt. Ich würde also einen Kernelbug vermuten.
Gruß
@Arano
Die Links kenne ich schon, bringt nix. Sobald ich den Kernel -116 boote, kann die eigentliche Root-Partition nicht mehr eingebunden werden. Die korrekte /etc/default/grub wird entsprechend auch nicht eingelesen, da kann ich reinschreiben, was immer ich will.
@bff
Ich hatte auch schon das Diskettenlaufwerk entfernt, taucht trotzdem wieder auf, sobald ich den Kernel -116 boote. Siehe Antwort an @Arano, der verdaddelt irgendwie die korrekte Root-Partition
Wenn ich den Kernel -112 boote, läuft alles wie gehabt. Ich würde also einen Kernelbug vermuten.
Gruß
Moin,
Update: Mittlerweile gibt es den Kernel 4.4.0-119, Update erfolgte automatisch. Auch hier bleibt die VM mit der eingangs beschriebenen Fehlermeldung hängen. Es muss also ein Problem beim Kernelwechsel geben.
Gruß
Update: Mittlerweile gibt es den Kernel 4.4.0-119, Update erfolgte automatisch. Auch hier bleibt die VM mit der eingangs beschriebenen Fehlermeldung hängen. Es muss also ein Problem beim Kernelwechsel geben.
Gruß
Hallo Coreknabe,
nur eine dumme Idee, aber ist bei dem neuen Kernel vielleicht ein Modul rausgeflogen, dass du verwendest?
grüße vom it-frosch
nur eine dumme Idee, aber ist bei dem neuen Kernel vielleicht ein Modul rausgeflogen, dass du verwendest?
grüße vom it-frosch
Und ein Abschluss-Update. Mir sind noch zwei Sachen aufgefallen:
- Über den HyperV-Manager ließ sich die VM nicht geplant herunterfahren, sondern ging einfach aus --> Problem mit den Integration Services?
- Das System lief unter Ubuntu 16.04 32bit, wobei sich sowas neu ja nicht mehr ohne Weiteres installieren lässt, da sich bei Ubuntu nur ein 64bit-ISO herunterladen lässt.
Ich habe den Server jetzt auf 16.04 64bit migriert, das läuft jetzt auch mit dem aktuellen Kernel 4.4.0-122. Nicht wirklich der Ursache auf den Grund gegangen, aber ich habe jetzt hoffentlich in dieser Hinsicht meine Ruhe und bin auch ein wenig zukunftssicherer.
Danke noch mal für Eure Anregungen!
- Über den HyperV-Manager ließ sich die VM nicht geplant herunterfahren, sondern ging einfach aus --> Problem mit den Integration Services?
- Das System lief unter Ubuntu 16.04 32bit, wobei sich sowas neu ja nicht mehr ohne Weiteres installieren lässt, da sich bei Ubuntu nur ein 64bit-ISO herunterladen lässt.
Ich habe den Server jetzt auf 16.04 64bit migriert, das läuft jetzt auch mit dem aktuellen Kernel 4.4.0-122. Nicht wirklich der Ursache auf den Grund gegangen, aber ich habe jetzt hoffentlich in dieser Hinsicht meine Ruhe und bin auch ein wenig zukunftssicherer.
Danke noch mal für Eure Anregungen!
Hallo,
Danke fuer diese Rueckmeldung.
Ich denke fast, dass das Grundproblem wirklich die verwendete 32-bit Version war. Und da MS und Ubuntu Hand in Hand arbeiten, kann ich mir vorstellen, dass Hyper-V und/oder Ubuntu 32-bit einfach mal so ein Problem haben kann, was mit "x64" nicht da ist.
Schoene Arbeitswoche.
BFF
Danke fuer diese Rueckmeldung.
Ich denke fast, dass das Grundproblem wirklich die verwendete 32-bit Version war. Und da MS und Ubuntu Hand in Hand arbeiten, kann ich mir vorstellen, dass Hyper-V und/oder Ubuntu 32-bit einfach mal so ein Problem haben kann, was mit "x64" nicht da ist.
Schoene Arbeitswoche.
BFF
