Hallo, heute ist für mich der GAU eingetreten: Nach einem Kernel-Update auf einem gemieteten Root-Server (openSUSE 42.3, ein einziges Softraid-Filesystem) mittels "zypper up" von wohl "config-4.4.132-53-default" auf "kernel-default-4.4.136-56.1" konnte das System nicht mehr booten (ein Vorabtest auf einem nahezu identischen System daheim, allerdings ohne Soft-Raid, lief übrigens problemlos). Auf der mir angebotenen Konsolen-Ausgabe konnte ich so etwas wie "kernel panic" lesen. Und nach Aktivieren des Rescue-Systems und einem "mount /dev/md2 /mnt) sah ich, dass das "(/mnt)/boot" Verzeichnis seltsamerweise leer war und ein Modifikationsdatum vom 16. Februar 2016 hatte. Der Inhalt des Server-Filesystems schien aber komplett sowie les- und schreibbar. Es existieren noch zwei gesicherte /boot-Verzeichnisse vom 14.06.2018 und 17.04.2018, die jeweils als /boot zuvor erfolgreich in Nutzung waren, ich weiss aber nicht, ob die nun hilfreich sind. Hier einmal der Inhalt von "/boot.180614" (nur Top-Level): -rw-r--r-- 1 root root 512 Oct 30 2015 boot.180614/backup_mbr lrwxrwxrwx 1 root root 1 Aug 6 2017 boot.180614/boot -> . -rw-r--r-- 1 root root 1.7K May 17 2017 boot.180614/boot.readme -rw-r--r-- 1 root root 177K Apr 12 09:51 boot.180614/config-4.4.126-48-default -rw-r--r-- 1 root root 176K May 23 15:37 boot.180614/config-4.4.132-53-default drwxr-xr-x 2 root root 4.0K Dec 22 14:13 boot.180614/dracut drwxr-xr-x 2 root root 4.0K Aug 6 2017 boot.180614/grub drwxr-xr-x 7 root root 4.0K Jun 14 01:15 boot.180614/grub2 lrwxrwxrwx 1 root root 25 May 27 22:16 boot.180614/initrd -> initrd-4.4.132-53-default -rw------- 1 root root 15M Jun 14 01:13 boot.180614/initrd-4.4.126-48-default -rw------- 1 root root 15M Jun 14 01:14 boot.180614/initrd-4.4.132-53-default drwx------ 2 root root 4.0K Feb 16 2016 boot.180614/lost+found -rwxr-xr-x 1 root root 169 Oct 30 2015 boot.180614/perl-BL_delayed_exec -rw-r--r-- 1 root root 335K Apr 12 10:42 boot.180614/symvers-4.4.126-48-default.gz -rw-r--r-- 1 root root 335K May 23 16:23 boot.180614/symvers-4.4.132-53-default.gz -rw-r--r-- 1 root root 377 Apr 12 10:42 boot.180614/sysctl.conf-4.4.126-48-default -rw-r--r-- 1 root root 377 May 23 16:23 boot.180614/sysctl.conf-4.4.132-53-default -rw-r--r-- 1 root root 3.2M Apr 12 10:30 boot.180614/System.map-4.4.126-48-default -rw-r--r-- 1 root root 3.2M May 23 16:16 boot.180614/System.map-4.4.132-53-default -rw-r--r-- 1 root root 6.8M Apr 12 10:48 boot.180614/vmlinux-4.4.126-48-default.gz -rw-r--r-- 1 root root 6.8M May 23 16:28 boot.180614/vmlinux-4.4.132-53-default.gz lrwxrwxrwx 1 root root 26 May 27 22:16 boot.180614/vmlinuz -> vmlinuz-4.4.132-53-default -rw-r--r-- 1 root root 5.9M Apr 12 11:26 boot.180614/vmlinuz-4.4.126-48-default -rw-r--r-- 1 root root 6.0M May 23 17:10 boot.180614/vmlinuz-4.4.132-53-default Als Hilfe wurde mir https://wiki.ubuntuusers.de/GRUB_2/Reparatur/ empfohlen. Ich habe einfach einmal (nach einem "chroot /mnt") /boot mit dem Inhalt von /boot.180614 überschrieben und die Schritte unter "RAID-System" der obigen Anleitung ausgeführt (dabei aber grub-install durch grub2-install ersetzt), das lief eigentlich ohne Fehler ab, ein heiß ersehntes erfolgreiches Booten fand aber leider nicht statt. Auch der Versuch, mit dem text-orientierten yast2 "System/Boot Loader" aufzurufen klappte beim ersten Mal, ein "Ok" schrieb zwar etwas, verhalf aber nicht zum Booten. Mittlerweile komme ich aber nicht mehr in das "Boot Loader Setting"-Menü, wahrscheinlich habe ich mir schon etwas zerschossen. Auch der Versuch mittels "zypper" einen "neuen" älteren Kernel zu installieren, schien zwar erfolgreich, führte aber auch zu keinen erfolgreichen Booten. Wie man wohl bemerkt, bin ich schon etwas "durcheinander" und verzweifelt, da ich es sehr schade fände, wenn 25 Jahe Open Source Support durch fossies.org eventuell so schmälich enden würden. Hat jemand vielleicht noch eine rettende Idee? Viele Grüße Jens