Wie Root-Server nach fehlerhaftem Kernel-Update wieder bootfähig machen?
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
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.
Bekam gerade den erklärenden Hinweis: Bei einem Standard-Partitions-Layout die Bootpartition wahrscheinlich /dev/md1 ist. Daher ist das boot-Verzeichnis leer, solange dieses nicht entsprechend dahin gemountet ist. Das hatte ich übersehen bzw. in der "Panik" vergessen ("mea culpa").
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
On Mon, 18 Jun 2018, Jens Schleusener wrote:
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.
Bekam gerade den erklärenden Hinweis:
Bei einem Standard-Partitions-Layout die Bootpartition wahrscheinlich /dev/md1 ist. Daher ist das boot-Verzeichnis leer, solange dieses nicht entsprechend dahin gemountet ist.
Das hatte ich übersehen bzw. in der "Panik" vergessen ("mea culpa").
Sorry, noch ein Nachschlag: Grrh, tatsächlich liegt das /boot Verzeichnis auf einer eigenen Partition und enthält augenblicklich: -rw-r--r-- 1 root root 512 Oct 30 2015 backup_mbr lrwxrwxrwx 1 root root 1 Aug 6 2017 boot -> . -rw-r--r-- 1 root root 1.7K May 17 2017 boot.readme -rw-r--r-- 1 root root 177K Apr 12 09:51 config-4.4.126-48-default -rw-r--r-- 1 root root 176K May 23 15:37 config-4.4.132-53-default -rw-r--r-- 1 root root 176K Jun 14 09:43 config-4.4.136-56-default -rw-r--r-- 1 root root 0 Jun 18 11:45 do_purge_kernels drwxr-xr-x 2 root root 1.0K Dec 22 14:13 dracut drwxr-xr-x 2 root root 1.0K Aug 6 2017 grub drwxr-xr-x 7 root root 1.0K Jun 18 11:46 grub2 lrwxrwxrwx 1 root root 25 Jun 18 11:45 initrd -> initrd-4.4.136-56-default -rw------- 1 root root 15M Jun 14 01:13 initrd-4.4.126-48-default -rw------- 1 root root 15M Jun 14 01:14 initrd-4.4.132-53-default -rw------- 1 root root 15M Jun 18 11:46 initrd-4.4.136-56-default drwx------ 2 root root 12K Feb 16 2016 lost+found -rwxr-xr-x 1 root root 169 Oct 30 2015 perl-BL_delayed_exec -rw-r--r-- 1 root root 335K Apr 12 10:42 symvers-4.4.126-48-default.gz -rw-r--r-- 1 root root 335K May 23 16:23 symvers-4.4.132-53-default.gz -rw-r--r-- 1 root root 335K Jun 14 10:33 symvers-4.4.136-56-default.gz -rw-r--r-- 1 root root 377 Apr 12 10:42 sysctl.conf-4.4.126-48-default -rw-r--r-- 1 root root 377 May 23 16:23 sysctl.conf-4.4.132-53-default -rw-r--r-- 1 root root 377 Jun 14 10:32 sysctl.conf-4.4.136-56-default -rw-r--r-- 1 root root 3.2M Apr 12 10:30 System.map-4.4.126-48-default -rw-r--r-- 1 root root 3.2M May 23 16:16 System.map-4.4.132-53-default -rw-r--r-- 1 root root 3.2M Jun 14 10:14 System.map-4.4.136-56-default -rw-r--r-- 1 root root 6.8M Apr 12 10:48 vmlinux-4.4.126-48-default.gz -rw-r--r-- 1 root root 6.8M May 23 16:28 vmlinux-4.4.132-53-default.gz -rw-r--r-- 1 root root 6.8M Jun 14 10:38 vmlinux-4.4.136-56-default.gz lrwxrwxrwx 1 root root 26 Jun 18 11:45 vmlinuz -> vmlinuz-4.4.136-56-default -rw-r--r-- 1 root root 5.9M Apr 12 11:26 vmlinuz-4.4.126-48-default -rw-r--r-- 1 root root 65 Apr 12 11:26 .vmlinuz-4.4.126-48-default.hmac -rw-r--r-- 1 root root 6.0M May 23 17:10 vmlinuz-4.4.132-53-default -rw-r--r-- 1 root root 65 May 23 17:10 .vmlinuz-4.4.132-53-default.hmac -rw-r--r-- 1 root root 6.0M Jun 14 11:15 vmlinuz-4.4.136-56-default -rw-r--r-- 1 root root 65 Jun 14 11:15 .vmlinuz-4.4.136-56-default.hmac Da in zypp.conf "multiversion.kernels = latest,latest-1,running" steht, sind sonst immer zwei Versionen erhalten, hier scheint aber irgendetwas bei der Kernelinstallation "daneben" gegangen zu sein (der neue Kernel war ja noch nicht "running"). Auch die .hmac hash Dateien habe ich sonst nicht gesehen. Da es kein lokales System ist, wüßte ich momentan nicht wie ich entsprechende Parameter beim Booten setzen könnte, um den vorigen (funktionierenden) Kernel 4.4.132-53-default zu nutzen. Ich muß also über das Rescue-System ein bootfähiges System erzeugen, habe aber Angst irgendetwas zu zerschiessen. Daher noch einmal die vielleicht etwas zu "bequeme" Frage, ob jemand mir eine Empfehlung geben kann?
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
On Mon, 18 Jun 2018, Jens Schleusener wrote:
On Mon, 18 Jun 2018, Jens Schleusener wrote:
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.
Bekam gerade den erklärenden Hinweis:
Bei einem Standard-Partitions-Layout die Bootpartition wahrscheinlich /dev/md1 ist. Daher ist das boot-Verzeichnis leer, solange dieses nicht entsprechend dahin gemountet ist.
Das hatte ich übersehen bzw. in der "Panik" vergessen ("mea culpa").
Sorry, noch ein Nachschlag:
Grrh, tatsächlich liegt das /boot Verzeichnis auf einer eigenen Partition und enthält augenblicklich:
-rw-r--r-- 1 root root 512 Oct 30 2015 backup_mbr lrwxrwxrwx 1 root root 1 Aug 6 2017 boot -> . -rw-r--r-- 1 root root 1.7K May 17 2017 boot.readme -rw-r--r-- 1 root root 177K Apr 12 09:51 config-4.4.126-48-default -rw-r--r-- 1 root root 176K May 23 15:37 config-4.4.132-53-default -rw-r--r-- 1 root root 176K Jun 14 09:43 config-4.4.136-56-default -rw-r--r-- 1 root root 0 Jun 18 11:45 do_purge_kernels drwxr-xr-x 2 root root 1.0K Dec 22 14:13 dracut drwxr-xr-x 2 root root 1.0K Aug 6 2017 grub drwxr-xr-x 7 root root 1.0K Jun 18 11:46 grub2 lrwxrwxrwx 1 root root 25 Jun 18 11:45 initrd -> initrd-4.4.136-56-default -rw------- 1 root root 15M Jun 14 01:13 initrd-4.4.126-48-default -rw------- 1 root root 15M Jun 14 01:14 initrd-4.4.132-53-default -rw------- 1 root root 15M Jun 18 11:46 initrd-4.4.136-56-default drwx------ 2 root root 12K Feb 16 2016 lost+found -rwxr-xr-x 1 root root 169 Oct 30 2015 perl-BL_delayed_exec -rw-r--r-- 1 root root 335K Apr 12 10:42 symvers-4.4.126-48-default.gz -rw-r--r-- 1 root root 335K May 23 16:23 symvers-4.4.132-53-default.gz -rw-r--r-- 1 root root 335K Jun 14 10:33 symvers-4.4.136-56-default.gz -rw-r--r-- 1 root root 377 Apr 12 10:42 sysctl.conf-4.4.126-48-default -rw-r--r-- 1 root root 377 May 23 16:23 sysctl.conf-4.4.132-53-default -rw-r--r-- 1 root root 377 Jun 14 10:32 sysctl.conf-4.4.136-56-default -rw-r--r-- 1 root root 3.2M Apr 12 10:30 System.map-4.4.126-48-default -rw-r--r-- 1 root root 3.2M May 23 16:16 System.map-4.4.132-53-default -rw-r--r-- 1 root root 3.2M Jun 14 10:14 System.map-4.4.136-56-default -rw-r--r-- 1 root root 6.8M Apr 12 10:48 vmlinux-4.4.126-48-default.gz -rw-r--r-- 1 root root 6.8M May 23 16:28 vmlinux-4.4.132-53-default.gz -rw-r--r-- 1 root root 6.8M Jun 14 10:38 vmlinux-4.4.136-56-default.gz lrwxrwxrwx 1 root root 26 Jun 18 11:45 vmlinuz -> vmlinuz-4.4.136-56-default -rw-r--r-- 1 root root 5.9M Apr 12 11:26 vmlinuz-4.4.126-48-default -rw-r--r-- 1 root root 65 Apr 12 11:26 .vmlinuz-4.4.126-48-default.hmac -rw-r--r-- 1 root root 6.0M May 23 17:10 vmlinuz-4.4.132-53-default -rw-r--r-- 1 root root 65 May 23 17:10 .vmlinuz-4.4.132-53-default.hmac -rw-r--r-- 1 root root 6.0M Jun 14 11:15 vmlinuz-4.4.136-56-default -rw-r--r-- 1 root root 65 Jun 14 11:15 .vmlinuz-4.4.136-56-default.hmac
Da in zypp.conf "multiversion.kernels = latest,latest-1,running" steht, sind sonst immer zwei Versionen erhalten, hier scheint aber irgendetwas bei der Kernelinstallation "daneben" gegangen zu sein (der neue Kernel war ja noch nicht "running"). Auch die .hmac hash Dateien habe ich sonst nicht gesehen.
Da es kein lokales System ist, wüßte ich momentan nicht wie ich entsprechende Parameter beim Booten setzen könnte, um den vorigen (funktionierenden) Kernel 4.4.132-53-default zu nutzen. Ich muß also über das Rescue-System ein bootfähiges System erzeugen, habe aber Angst irgendetwas zu zerschiessen.
Daher noch einmal die vielleicht etwas zu "bequeme" Frage, ob jemand mir eine Empfehlung geben kann?
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.
Die waren tatsächlich hilfreich, der letzte Versuch, der zum Erfolg führte, sah prinzipiell etwa so aus (nach Einloggen ins Rescue-System): mount /dev/md2 /mnt mount /dev/md1 /mnt/boot rm -fr /mnt/boot/* cp -a boot.180614/* boot/ # Nicht sicher ob nötig: chroot-prepare /mnt mount -o bind /dev /mnt/dev mount -o bind /sys /mnt/sys mount -t proc /proc /mnt/proc cp /proc/mounts /mnt/etc/mtab # Dann: chroot /mnt /bin/bash grub-install /dev/sda grub-install /dev/sdb grub2-mkconfig -o /boot/grub2/grub.cfg Ganz ist das Problem natürlich damit nicht gelöst, denn es bleibt die Frage, was da passiert ist? Auch benutzt das System jetzt natürlich "nur" Kernel 4.4.132-53-default und ich weiß nicht, ob ich das Kernel Update noch einmal versuchen oder besser auf den nächsten Kernel warten sollte. Sorry für die etwas "unkontrollierten" Mails Jens
participants (1)
-
Jens Schleusener