Update-Manager hat GRUB deinstalliert – wie komme ich zurück zu Ubuntu?

Update-Manager hat GRUB deinstalliert – wie komme ich zurück zu Ubuntu?

Ich verwende Ubuntu 14.04 und aktualisiere es immer regelmäßig (fast jeden Tag). Heute, am 8. Juli, verhielt sich das Ubuntu-Update anders als sonst. Es hieß „Nicht alle Updates können installiert werden“ und schlug ein „Teilupdate“ vor. Das habe ich nie ausprobiert, aber ich vertraue Ubuntu. Eines der Dinge, die mir auf der Update-Liste aufgefallen sind, war der Bootloader GRUB, aber hey, ich vertraue Ubuntu.

Nach Abschluss wurde ich aufgefordert, neu zu starten, und als ich das tat, wurde Windows direkt gestartet. Das heißt, GRUB wird effektiv deinstalliert, und ich habe keine Wahl, ob ich jetzt Ubuntu starten möchte. Ich bin weder bei Linux noch bei Windows ein Hai, aber bei Windows 8 fühle ich mich deutlich behinderter (es war einfach im Lieferumfang enthalten).

Ist Ubuntu noch auf dem Laptop vorhanden? Wenn ja, wie kann ich möglichst schnell darauf zurückgreifen? (Ich muss am Wochenende eine Präsentation halten und das Einrichten eines neuen Systems und das Abrufen von Sicherungsdaten ist langsam.)


Grub-Installation nach Antwort von Christian Benke schlägt fehl


Ich teste das System jetzt mit einem Ubuntu-USB-Stick.

ubuntu@ubuntu:~$ sudo parted -l
Model: ATA TOSHIBA THNSNJ25 (scsi)
Disk /dev/sda: 256GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number  Start   End     Size    File system     Name                  Flags
 1      1049kB  1075MB  1074MB  ntfs            Basic data partition  hidden, diag
 2      1075MB  1180MB  105MB   fat32           Basic data partition  boot
 3      1180MB  1314MB  134MB   ntfs            Basic data partition  msftres
 4      1314MB  44.7GB  43.4GB  ntfs            Basic data partition  msftdata
 6      44.7GB  46.7GB  2000MB  linux-swap(v1)
 7      46.7GB  244GB   197GB   ext4
 5      244GB   256GB   12.1GB  ntfs            Basic data partition  hidden, diag

Ein schnelles „sudo mkdir /media/[Mountpoint]“, gefolgt von „sudo mount /dev/sda[X] /media/[Mountpoint]“, ermöglichte die Überprüfung der Partitionen:

/dev/sda1  Windows boot files
/dev/sda2  EFI files
/dev/sda3  Empty
/dev/sda4  Windows system
/dev/sda5  Toshiba recovery
/dev/sda6  Ubuntu swap partition (not mountable)
/dev/sda7  Ubuntu system

Offensichtlich möchte ich mit /dev/sda7 weitermachen.

ubuntu@ubuntu:~$ sudo mkdir /media/oldroot
ubuntu@ubuntu:~$ sudo mount /dev/sda7 /media/oldroot
ubuntu@ubuntu:~$ sudo mount --bind /dev /media/oldroot/dev
ubuntu@ubuntu:~$ sudo mount --bind /proc /media/oldroot/proc
ubuntu@ubuntu:~$ sudo mount --bind /sys /media/oldroot/sys
ubuntu@ubuntu:~$ sudo chroot /media/oldroot /bin/sh 
# lsb_release -d
Description:    Ubuntu 14.04.2 LTS
# grub-install /dev/sda
Installing for x86_64-efi platform.
grub-install: error: cannot find EFI directory.
# exit

Offensichtlich hat grub-install die EFI-Dateien unter /dev/sda2 nicht gefunden, aber das vorherige Mounten unter /media/oldroot/boot/efi schien problemlos zu funktionieren:

ubuntu@ubuntu:~$ sudo mount /dev/sda2 /media/oldroot/boot/efi
ubuntu@ubuntu:~$ sudo chroot /media/oldroot /bin/sh 
# lsb_release -d
Description:    Ubuntu 14.04.2 LTS
# grub-install /dev/sda
Installing for x86_64-efi platform.
Installation finished. No error reported.
# update-grub
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-3.16.0-43-generic
Found initrd image: /boot/initrd.img-3.16.0-43-generic
Found linux image: /boot/vmlinuz-3.16.0-41-generic
Found initrd image: /boot/initrd.img-3.16.0-41-generic
Found linux image: /boot/vmlinuz-3.16.0-40-generic
Found initrd image: /boot/initrd.img-3.16.0-40-generic
Found linux image: /boot/vmlinuz-3.16.0-39-generic
Found initrd image: /boot/initrd.img-3.16.0-39-generic
Found linux image: /boot/vmlinuz-3.16.0-38-generic
Found initrd image: /boot/initrd.img-3.16.0-38-generic
Found linux image: /boot/vmlinuz-3.16.0-37-generic
Found initrd image: /boot/initrd.img-3.16.0-37-generic
Found linux image: /boot/vmlinuz-3.16.0-36-generic
Found initrd image: /boot/initrd.img-3.16.0-36-generic
Found linux image: /boot/vmlinuz-3.16.0-34-generic
Found initrd image: /boot/initrd.img-3.16.0-34-generic
Found linux image: /boot/vmlinuz-3.16.0-33-generic
Found initrd image: /boot/initrd.img-3.16.0-33-generic
Adding boot menu entry for EFI firmware configuration
done
# exit    

Dies hat das Problem jedoch nicht gelöst. Beim Neustart wurde GRUB nicht angezeigt und es ging direkt wieder zu Windows? Vielen Dank bisher, was scheint diesmal das Problem zu sein?


Die Neuinstallation der betroffenen Pakete schlägt fehl


Wie vorgeschlagen, schaue ich mir die Datei apt/history.log an, um zu sehen, was während des „partiellen Updates“ passiert ist, das GRUB zum Stillstand gebracht hat. Leider enthält sie keinen Eintrag für das Update vom 8. Juli:

ubuntu@ubuntu:~$ cat /media/summer7/var/log/apt/history.log

Start-Date: 2015-07-03  09:32:40
Commandline: aptdaemon role='role-commit-packages' sender=':1.79'
Upgrade: lightdm:amd64 (1.10.5-0ubuntu1, 1.10.5-0ubuntu1.1), liblightdm-gobject-1-0:amd64 (1.10.5-0ubuntu1, 1.10.5-0ubuntu1.1)
End-Date: 2015-07-03  09:32:42

Start-Date: 2015-07-05  20:02:01
Commandline: aptdaemon role='role-commit-packages' sender=':1.85'
Upgrade: libxcomp3:amd64 (3.5.0.31-0~605~ubuntu14.04.1, 3.5.0.32-0~668~ubuntu14.04.1), nxproxy:amd64 (3.5.0.31-0~605~ubuntu14.04.1, 3.5.0.32-0~668~ubuntu14.04.1), irqbalance:amd64 (1.0.6-2ubuntu0.14.04.1, 1.0.6-2ubuntu0.14.04.2)
End-Date: 2015-07-05  20:02:04

Start-Date: 2015-07-07  20:00:24
Commandline: aptdaemon role='role-commit-packages' sender=':1.81'
Install: linux-image-3.16.0-43-generic:amd64 (3.16.0-43.58~14.04.1), linux-headers-3.16.0-43:amd64 (3.16.0-43.58~14.04.1), linux-headers-3.16.0-43-generic:amd64 (3.16.0-43.58~14.04.1), linux-image-extra-3.16.0-43-generic:amd64 (3.16.0-43.58~14.04.1), linux-signed-image-3.16.0-43-generic:amd64 (3.16.0-43.58~14.04.1)
Upgrade: linux-signed-image-generic-lts-utopic:amd64 (3.16.0.41.33, 3.16.0.43.34), libfontembed1:amd64 (1.0.52-0ubuntu1.4, 1.0.52-0ubuntu1.5), linux-image-generic-lts-utopic:amd64 (3.16.0.41.33, 3.16.0.43.34), cups-browsed:amd64 (1.0.52-0ubuntu1.4, 1.0.52-0ubuntu1.5), linux-signed-generic-lts-utopic:amd64 (3.16.0.41.33, 3.16.0.43.34), cups-filters-core-drivers:amd64 (1.0.52-0ubuntu1.4, 1.0.52-0ubuntu1.5), cups-filters:amd64 (1.0.52-0ubuntu1.4, 1.0.52-0ubuntu1.5), libgtksourceview2.0-0:amd64 (2.10.5-1ubuntu2, 2.10.5-1ubuntu2.14.04.1), linux-generic-lts-utopic:amd64 (3.16.0.41.33, 3.16.0.43.34), linux-libc-dev:amd64 (3.13.0-55.94, 3.13.0-57.95), libgtksourceview2.0-common:amd64 (2.10.5-1ubuntu2, 2.10.5-1ubuntu2.14.04.1), linux-headers-generic-lts-utopic:amd64 (3.16.0.41.33, 3.16.0.43.34), libcupsfilters1:amd64 (1.0.52-0ubuntu1.4, 1.0.52-0ubuntu1.5)
End-Date: 2015-07-07  20:01:11

Tatsächlich scheint die Länge etwas zu kurz zu sein, nicht wahr? Außerdem lag der letzte Eintrag 2 Stunden in der Zukunft, verglichen mit dem Zeitpunkt, als die Datei zuletzt berührt wurde:

ubuntu@ubuntu:~$ ls -l /media/summer7/var/log/apt/history.log
-rw-r--r-- 1 root root 1925 Jul  7 18:01 /media/summer7/var/log/apt/history.log

Vielleicht handelt es sich hier also um eine Dateibeschädigung? Naja, ich habe es mit apt-get update versucht, aber es hat nicht funktioniert:

ubuntu@ubuntu:~$ sudo mount --bind /dev /media/oldroot/dev
ubuntu@ubuntu:~$ sudo mount --bind /proc /media/oldroot/proc
ubuntu@ubuntu:~$ sudo mount --bind /sys /media/oldroot/sys
ubuntu@ubuntu:~$ sudo chroot /media/oldroot apt-get update

Der Abruf aller Dateien schlug fehl mit der Fehlermeldung "konnte nicht aufgelöst werden", ähnlich wiediese FrageFolgendes schlägt fehl

ubuntu@ubuntu:~$ sudo chroot /media/oldroot ping dk.archive.ubuntu.com
ping: unknown host dk.archive.ubuntu.com

und die Datei /media/oldroot/etc/resolv.conf ist völlig leer. Ist das ein schlechtes Zeichen?

Antwort1

Ich hatte am selben Tag dasselbe Problem wie Sie. Ich habe an einigen Dingen gearbeitet, Ubuntu hat ein Teilupdate vorgeschlagen, ich habe dem zugestimmt und dann den Großteil des gestrigen Tages damit verbracht, zu versuchen, Grub neu zu installieren (ohne Erfolg).

Meine Installation war ein Dual-Boot mit Windows 8.1, daher hatte ich neben den Windows-Partitionen drei Linux-Partitionen: eine für das System („/“), eine für Home („/home“) und eine für Swap. Ich konnte Grub nicht mit Boot-Repair neu installieren, also habe ich mit einem Ubuntu-USB-Stick gebootet und das Installationsprogramm gestartet.

Als ich gefragt wurde, was ich tun wollte, habe ich etwas anderes ausgewählt. Dann habe ich mein ursprüngliches Systemverzeichnis „/“ als Root-Partition festgelegt und dem Installer gesagt, es zu formatieren. Ich habe Swap als Swap und mein Home-Verzeichnis als „/home“ festgelegt, aber dem Installer gesagt, das Home-Verzeichnis nicht zu formatieren.

Ich habe dem Installer außerdem gesagt, dass er den Bootloader auf der Festplatte (in meinem Fall /dev/sda) installieren soll, nicht auf einer Partition. Die Installation wurde abgeschlossen, beim Neustart erschien Grub und ich konnte Ubuntu und Windows 8.1 neu starten.

Mein Home-Verzeichnis war vollständig intakt, mein Desktop-Hintergrund und .bashrc wurden automatisch geladen und als ich mit der Neuinstallation von Programmen begann, wurde ich automatisch wieder bei Teamviewer, Chrome usw. angemeldet.

Wenn Sie separate /home- und Systempartitionen haben, ist dies möglicherweise die beste Lösung. Es gehen keine Daten verloren und die Neuinstallation dauert nicht zu lange.

Antwort2

Sie können ein kleines bootfähiges Live-System verwenden wieGrmlund der Befehlchrootum wieder in Ihr altes System zu gelangen und den defekten Bootloader zu reparieren.

Nachdem Sie von der Live-CD gebootet haben, möchten Sie auf das Dateisystem Ihres installierten Linux-Systems zugreifen. Als erstes mounten Sie also die Root-Partition des installierten Linux (als Root-Benutzer in Ihrer Live-CD-Umgebung):

# mkdir /media/oldroot
# mount /dev/sda1 /media/oldroot

Wenn Sie nicht sicher sind, welche Ihre Linux-Partition ist, mounten Sie alle verfügbaren Partitionen und prüfen Sie, welche Ihre Root-Partition ist.

Der nächste Schritt, um eine funktionsfähige Chroot-Umgebung zu erhalten, ist das Mounten der Pseudo-Dateisysteme (/Entwickler,/proc,/sys) von Ihrer Live-CD-Umgebung innerhalb der Root-Partition, die wir gerade gemountet haben:

# mount --bind /dev /media/oldroot/dev
# mount --bind /proc /media/oldroot/proc
# mount --bind /sys /media/oldroot/sys

Jetzt ist unser System bereit zum Chrooten, das heißt, Sie "ersetzen" die Umgebung Ihrer Live-CD durch das installierte System (Wir sagen ihm auch, dass es/bin/shals Eingabeaufforderung in der installierten Umgebung:

# chroot /media/oldroot /bin/sh
# 

Stellen Sie sicher, dass Sie Ihr altes installiertes Linux verwenden:

# lsb_release -d
Description:    Ubuntu 14.04.2 LTS

Versuchen Sie, aus dem Chroot heraus

# grub-install /dev/sda

um den Grub-Bootloader im Master-Boot-Record Ihrer Festplatte neu zu installieren.

Wenn Grub2 tatsächlich deinstalliert wurde und Grub-Install nicht existiert, können Sie es neu installieren, indem Sie das Grub2-Paket auf einen USB-Stick kopieren:

Laden Sie die Deb-Datei herunter vonhttp://packages.ubuntu.com/trusty/grub2und kopiere es auf einen USB-Stick. Mounte den USB-Stick in deinem Chroot (Verwende Alt-F2, um ein zweites TTY in der Live-CD-Umgebung zu erhalten und den USB-Stick zu mounten, wechsle anschließend mit Alt-F1 zurück in die Chroot-Umgebung):

-- Press <Alt-F2> to get to the second tty of the live-cd-env
# mkdir /media/oldroot/media/<yourusername>/usb_stick
# mount /dev/sdb1 /media/oldroot/media/<youruser>/usb_stick

-- Press <Alt-F1> to get back to the first tty to our chroot
# cd /media/<yourusername>/usb_stick
# ls
dpkg -i grub2_2.02~beta2-9_amd64.de
# dpkg -i grub2_2.02~beta2-9_amd64.deb

Danach weiter mitgrub-install.

verwandte Informationen