coreknabe
Goto Top

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:

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ß

Content-Key: 366223

Url: https://administrator.de/contentid/366223

Ausgedruckt am: 19.03.2024 um 02:03 Uhr

Mitglied: Arano
Arano 27.02.2018 um 12:02:10 Uhr
Goto Top
Hi,

nur als Hinweis weil du von sdA sprichst...
Was ist sdC
ALERT! /dev/SDC5 does not exist.

~Arano
Mitglied: Coreknabe
Coreknabe 27.02.2018 aktualisiert um 12:31:37 Uhr
Goto Top
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)

evalprob

Die UUID ist sda1, also der Root-Partition zugeordnet.

Gruß
Mitglied: BassFishFox
BassFishFox 27.02.2018 um 12:55:50 Uhr
Goto Top
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
Mitglied: kaiand1
kaiand1 27.02.2018 um 12:59:30 Uhr
Goto Top
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)
Mitglied: Coreknabe
Coreknabe 27.02.2018 um 13:45:05 Uhr
Goto Top
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.
Mitglied: Coreknabe
Coreknabe 27.02.2018 um 14:07:53 Uhr
Goto Top
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 face-smile

Gruß
Mitglied: it-frosch
it-frosch 27.02.2018 aktualisiert um 15:03:18 Uhr
Goto Top
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
Mitglied: Coreknabe
Coreknabe 27.02.2018 um 16:03:26 Uhr
Goto Top
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ß
Mitglied: Coreknabe
Coreknabe 01.03.2018 um 11:13:51 Uhr
Goto Top
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ß
Mitglied: Arano
Arano 01.03.2018 um 11:42:07 Uhr
Goto Top
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 ...
/etc/default/grub
GRUB_CMDLINE_LINUX_DEFAULT="quiet rootdelay=30"
30 Sek Verzögerung bevor Root eingebunden wird.


~Arano
Mitglied: BassFishFox
BassFishFox 01.03.2018 um 12:52:34 Uhr
Goto Top
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
Mitglied: Coreknabe
Coreknabe 06.03.2018 um 10:27:17 Uhr
Goto Top
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ß
Mitglied: Coreknabe
Coreknabe 06.04.2018 um 08:44:47 Uhr
Goto Top
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ß
Mitglied: it-frosch
it-frosch 10.04.2018 um 10:54:50 Uhr
Goto Top
Hallo Coreknabe,

nur eine dumme Idee, aber ist bei dem neuen Kernel vielleicht ein Modul rausgeflogen, dass du verwendest?

grüße vom it-frosch
Mitglied: Coreknabe
Coreknabe 24.04.2018 um 17:10:21 Uhr
Goto Top
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!
Mitglied: BassFishFox
BassFishFox 24.04.2018 um 19:21:34 Uhr
Goto Top
Hallo,

Danke fuer diese Rueckmeldung. face-smile

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. face-smile

BFF