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