Plötzlich wieder Windows...

[plipMan]

Hallo,

ich habe auf einem Lenovo Thinkpad P53 mit einem vorinstallierten Windows 10. Vor ein paar Monaten habe ich dem eine zweite SSD verpasst und Debian Buster installiert. Heute habe das Ding zum ersten Mal wieder eingeschaltet ein paar Pakete aktualisiert/instaliert, etc... Beim Versuch eines Neustarts hing der Rechner und ich habe ihn nach ein paar Minuten per Power-Button gekillt.
Beim Booten hatte ich dann plötzlich wieder den Windows-Bootmanager und konnte Windows auch starten. Das hat mich etwas irritiert, weil ich eigentlich dachte ich hätte die Platten damals alle formatiert und Windows auch nicht im Linux Bootmanager aufgetaucht ist.
Aber wie bekomme ich jetzt mein Linux zurück?

[plipMan]

Edit: Ich glaube ich hab mich nicht ganz klar ausgedrückt. Ich lande beim Starten im GRUB, aber da habe ich nur "Windows Boot Manager" und "System Setup" zur Auswahl.

[smutbert]

Da ist irgendetwas gewaltig schief gegangen.

update-grub aktualisiert das grub-Menü und wird bei jeder Kernel(de)installation und damit auch bei jedem Kernelupdate aufgerufen. Erklären lässt sich das Verhalten eigentlich fast nur durch ein kaputtes Dateisystem oder dadurch, dass du in Debian alle Kernel deinstalliert hast – dafür hättest du aber einige Warnungen ignorieren müssen. Es bleibt dir wohl nichts andere übrig als ein (Live-)Linux von CD, DVD, USB-Stick zu starten und die Situation genauer zu untersuchen.
Als erstes könntest du einmal das /- (oder /boot-, wenn es ein eigenes ist) Dateisystem mounten und nachsehen ob ein Kernel samt initrd in /boot liegt.

Ist das der Fall kannst du in das System chrooten und schauen was update-grub macht

und wenn nicht, kannst du ebenfalls in das System chrooten und einen Kernel installieren.

[plipMan]

Ich hatte unter anderem die buster-backports aus den Paketquellen entfernt und ein upgrade gemacht. Wenn ich mich recht erinnere gab es tatsächlich irgendeine Meldung mit einem zu entfernenden Kernel. Aber eine Warnung kam da nicht, deshalb hab ichs einfach akzeptiert.

Ich bin jetzt per Installations-Stick im Rescue Mode im root-FS. Es kam die Meldung, dass ich eine externe boot und efi Partition habe und die Frage, ob diese eingebunden werden sollen. Das habe ich bejaht. Was genau müsste ich denn da unter /boot sehen?

ls /boot liefert:
- efi
- grub
- lost+found

[MSfree]

ls /boot liefert:
- efi
- grub
- lost+found

Das ist ein bißchen wenig. Dort sollte eigentlich mindestens eine initrd..., eine config..., eine System.map... und eine vmlinuz... liegen. Bei mir sind dort gerade 2 solcher Dateien, für 2 Linuxkernel (einen alten und den aktuellen). Wenn nicht mindestens ein Kernel vorliegt, kann der Rechner nicht booten.

Wenn du in das installierte Linux mit chroot wechselst, mußt du dort

Code: Alles auswählen

apt-get install linux-image-amd64

aufrufen, um wieder den Standardkernel installiert zu bekommen. Bei diesem Vorgang wird auch /etc/grub/grub.cfg aktualisiert und der installierte Kernel eingetragen. Nach dem Reboot sollte die Kiste wieder normal hochkommen.

[plipMan]

Wenn du in das installierte Linux mit chroot wechselst, mußt du dort

Den Teil verstehe ich nicht ganz. Was genau muss ich da machen?

[plipMan]

Wenn du in das installierte Linux mit chroot wechselst, mußt du dort

Den Teil verstehe ich nicht ganz. Was genau muss ich da machen?

Ok, so wie ich das verstrehe ist das schon der Fall, wenn ich die Option "eine schell im Root-Fs öffnen" wähle. Ich habe den Kernel installiert und sehe die Auswahl jetzt auch wieder in Grub. Beim booten kommt aber laufend die Meldung: Volume Group "debian-vg" not found

[plipMan]

Falls das irgendeine Rolle spielt - die SSD ist verschlüsselt.

[smutbert]

Verschlüsselt und lvm – dann musst du natürlich auch sicherstellen, dass cryptsetup-initramfs und lvm2 installiert sind – wenn dir beim Update alle Kernel abhanden gekommen sind, trifft das möglicherweise ja auch auf diese Pakete zu.

[plipMan]

Nein, sind beide noch da.

[plipMan]

Das Problem ist behoben. Hier hatte jemand das gleiche Problem: https://ubuntuforums.org/showthread.php?t=2350675

Der Devicename unter ls /dev/mapper/ hat nicht mit dem Eintrag in /etc/crypttab übereingestimmt.
Wie auch immer das passiert...

Danke für Eure Hilfe!