Ich habe versucht Opensuse Leap 15.4 auf einem Lenovo SR635 (AMD 7202) zu installieren.
Der Rechner friert immer bei Loading initial RAM Disk ein. Es ist also nicht möglich eine Installation, Update, Rescue, etc. durchzuführen.
Es wurden 2 unterschiedliche USB Sticks verwendet und mit diesen Sticks wurden erfolgreich diese Version auf anderen Rechnern installiert.
Opensuse Leap 15.3 konnte mit dem USB Stick erfolgreich auf dem Lenovo SR635 installiert werden.
Das ist jetzt eine suboptimale Lösung da der Support für 15.3 Ende des Jahres ausläuft und ich lieber die aktuelle Version sauber darauf hätte.
Die Frage ist jetzt ob es sich um einen Fehler im Bootstrap Prozess handelt oder in dem verwendeten Kernel von Leap 15.4.
Du hast anscheinend verschiedene Sticks da. Wenn eine 15.3 dabei ist (und als Reserve betrachtet werden kann) könntest du darauf ein on-line Upgrade nach 15.4 machen. Schauen ob der dann noch immer funktioniert.
Mir wäre ein clean new 15.4 Installation eigentlich lieber mit einem funktionierenden Bootstrap Prozess. Dadurch habe ich jetzt erheblich mehr Aufwand als ich ursprünglich veranschlagt habe. Die beiden letzten SR635 Server konnte ich mit Leap 15.2 völlig problemlos und schnell installieren. Laufen auch
Weitere Planung:
Tumbleweed Installation USB Stick erstellen und ausprobieren.
Online Update von Leap 15.3 auf 15.4 ohne USB Stick
Damit bleibt der Rechner stehen. Auch die Grub Option mit Rescue bleibt genauso hängen.
Genau genommen ist es folgender Aufruf nach Grub (Version 2.06)
Hast du jetzt mit beide Varianten versucht, oder war dein erster Post nur ungenau?
Übrigens, wenn man von z.B. 15.3 auf 15.4 geht heißt das “Upgrade”. Entgegen “Update”, wovon man redet wenn es um neuere Versionen von Paketen innerhalb eine openSUSE Version geht.
Und “der SDB” ist unklar. Entweder du linkst gleich dahin, so das wir wissen welche du meinst, oder du erklärst klar welche Art und Weise du genwählt hast.
Nächster Versuch:
AKtuelle Version von Tumbleweed auf USB Stick gezogen:
Gleiches Ergebnis: Der Rechner friert ein mit:
Loading initial ramdisk …
Ein brandneuer Lenovo Server SR635 (AMD 7202, 128GB RAM, NVME SSDs) kann nicht mit der Aktuellen OpenSUSE Distribution Leap oder Tumbleweed ausgestattet werden.
Das ist richtig bitter. Ich habe mit SUSE 1.09 vor 27 Jahren angefangen und alle Versionen seither benutzt.
Ich habe von diesem USB Stick mit diesem Image bereits andere Rechner installiert. (Keine Lenovo Server sondern ein PC mit AMD CPU).
Ich habe mehrere verschiedene USB Sticks verwendet und diese immer mit der aktuellen Version von Imagewriter beschrieben.
Danach habe ich ein ISO von Tumbleweed auf diesen Stick gezogen mit dem gleichen Ergebnis.
Es tritt bereits beim Starten des Installationsmediums auf.
Von einem dieser USB Sticks konnte ich erfolgreich ein Leap 15.3 installieren und es lief stabil. Nach einem Upgrade auf 15.4 mittels Zypper ohne USB Stick konnte der Rechner nicht mehr booten und fror im gleichen Schritt ein. Das ist sehr hässlich da ich eigentlich noch 2 Lenovo Server SR635 die bereits im RZ verbaut sind so remote Upgraden muss. Die wären dann tot!
Es handelt sich um einen neuen Lenovo Server SR635 mit folgender Version des Bios:
AMI
UEFI Version 6.41 (BUILD ID:CFE132K)
UEFI Copyright: Version 2.20.1275 Copyright 2022 American Megatrends,Inc
UEFI Build Time 05/26/2022 09:42:57
PSP Bootloader Version 0.C.0.84
SMU FW Version 0.36.113.0
BMC Version 5.44
Was könnte es im Bios sein das der Rechner mit einem aktuelle Kernel nicht bootet?
Wenn ich Dich richtig verstehe, dann hast Du ein openSUSE Leap 15.3 Installationsmedium (USB-Stick), welches Du erfolgreich starten kannst und eine openSUSE Leap 15.4 Installation (Lenovo Server SR635), die beim Starten im Laden der initrd hängen bleibt.
Hast Du schon einmal versucht das Rettungssystem des openSUSE Leap 15.3 Installationsmediums (USB-Stick) zu starten, per chroot zur openSUSE Leap 15.4 Installation (Lenovo Server SR635) zu wechseln und dort mit
Nicht ganz. Ich habe mehrere Rechner (laptop bis PC) die alle mit Opensuse Leap laufen. Ich habe im Moment nur einen Lenovo SR635 im direkten Zugriff, die anderen beiden Server sind produktiv und im RZ verbaut.
Den SR635 habe ich jetzt mehrfach mit verschiedenen Versionen installiert:
Leap 15.4 -> Booten per USB Stick scheitert im initrd
Tumbleweed (aktuell) -> Booten per USB Stick scheitert im initrd
Leap 15.3 -> Installation und Betrieb funktioniert
Neuinstallation von Leap 15.3 -> Installation und Betrieb funktioniert -> Das ist der aktuelle Stand des Lenovo Server SR635
Wenn ich es richtig verstehe habe ich genau das bereits mit Schritt 3 und 4 so gemacht?
Mein Problem ist ja das der Rechner im initrd hängen bleibt und ich damit keine Möglichkeit habe irgend etwas über die Ursache zu erfahren. Laptop, und PCs haben alle keine Probleme mit dem Upgrade von 15.3 -> 15.4 gezeigt.
Klar könnte ich jetzt nochmal das lauffähige System 15.3 nach 15.4 upgraden. Dann keinen Reboot durchführen sondern versuchen die Installation und initrd zu untersuchen. Nur ich habe keine Idee wonach ich suchen sollte.
Ich habe den Vorschlag mit dem chroot aus zwei Gründen gemacht:
Vielleicht erlaubt die eine oder andere Ausgabe von “dracut -f” Rückschlüsse auf die Problemursache.
Weiterhin könntest Du in der chroot
-Umgebung Dateien wie z.B. /boot/grub2/grub.cfg, /etc/default/grub, … untersuchen und testen, was passiert, wenn Du GRUB2 nochmals installierst. Auch könntest Du das initrd inhaltlich prüfen (mit lsinitrd). Und ein Blick in das NVRAM des Rechners (mit efibootmgr) könnte ggf. auch Hinweise liefern.
Ich gebe zu, das ist Alles ein “stochern im Nebel”. Da ich das Problem mangels vergleichbarer Hardware nicht nachstellen kann, bin ich leider auch nicht in der Lage Dich mit konkreteren Hinweisen zu unterstützen.
Das lauffähige System mit 15.3 erhält ein Upgrade zu 15.4
Diesmal nicht über die Console sondern es wird remote per ssh laufen gelassen. (Im Consolenmodus konnte ich nicht die Ausgaben von zypper etc zwischenspeichern)
Kein Reboot sondern remote alles mögliiche untersuchen
Ausgaben zypper
Ausgaben von dracut (wurde automatisch mit gestartet)
lsinstrd , … prüfen
gegebenenfalls Änderungen durchführen, zusätzliche Kernel installieren und in Grub eintragen,…
Reboot
funktioniert: Jubel anstimmen.
funktioniert nicht-> Booten über USB Rescue Stick mit Leap 15.3 und weiter untersuchen…
Vor dem Upgrade würde ich noch einige Start-relevanten Informationen (Inhalt NVRAM; /etc/default/grub; /boot/grub2/grub.cfg; Ergebnis von lsinitrd; …) sichern.
Auch würde ich die Liste der Repositories sorgfältig prüfen (=> ${releaseserver} korrekt gesetzt?) und zunächst nur die 6 “Standard”-Repositories (oss, non-oss, update oss, update non-oss, update backports, update sle) aktivieren (auch wenn der SDB-Artikel sagt, dass diese Einschränkung nicht mehr erforderlich ist). Weitere Repositories würde ich nur dann bereits beim Upgrade aktivieren, wenn das zwingend notwendig ist. Ansonsten würde ich weitere Repositories erst einbinden, wenn das Grundsystem funktionstüchtig ist. Ebenso würde ich mit weiteren Kernel-Versionen verfahren.
Also lauffähiges 15.3 installiert und alle Updates gefahren.
Nach SDB Vorschrift habe ich jetzt ein Upgrade zu 15.4 gemacht. Dabei bin ich auf folgende Ausgaben von dracut gestossen:
dracut: Executing: /usr/bin/dracut -f /boot/initrd-5.14.21-150400.24.28-default 5.14.21-150400.24.28-default
dracut: dracut module ‘systemd-coredump’ will not be installed, because command ‘coredumpctl’ could not be found!
dracut: dracut module ‘systemd-coredump’ will not be installed, because command ‘/usr/lib/systemd/systemd-coredump’ could not be found!
dracut: dracut module ‘systemd-networkd’ will not be installed, because command ‘networkctl’ could not be found!
dracut: dracut module ‘systemd-networkd’ will not be installed, because command ‘/usr/lib/systemd/systemd-networkd’ could not be found!
dracut: dracut module ‘systemd-networkd’ will not be installed, because command ‘/usr/lib/systemd/systemd-networkd-wait-online’ could not be found!
dracut: dracut module ‘systemd-repart’ will not be installed, because command ‘systemd-repart’ could not be found!
dracut: dracut module ‘systemd-resolved’ will not be installed, because command ‘resolvectl’ could not be found!
dracut: dracut module ‘systemd-resolved’ will not be installed, because command ‘/usr/lib/systemd/systemd-resolved’ could not be found!
dracut: dracut module ‘dbus-broker’ will not be installed, because command ‘dbus-broker’ could not be found!
dracut: dracut module ‘rngd’ will not be installed, because command ‘rngd’ could not be found!
dracut: dracut module ‘lvmmerge’ will not be installed, because command ‘lvm’ could not be found!
dracut: dracut module ‘lvm’ will not be installed, because command ‘lvm’ could not be found!
dracut: dracut module ‘tpm2-tss’ will not be installed, because command ‘tpm2’ could not be found!
dracut: dracut module ‘iscsi’ will not be installed, because command ‘iscsi-iname’ could not be found!
dracut: dracut module ‘iscsi’ will not be installed, because command ‘iscsiadm’ could not be found!
dracut: dracut module ‘iscsi’ will not be installed, because command ‘iscsid’ could not be found!
dracut: dracut module ‘biosdevname’ will not be installed, because command ‘biosdevname’ could not be found!
dracut: dracut module ‘memstrack’ will not be installed, because command ‘memstrack’ could not be found!
dracut: memstrack is not available
dracut: If you need to use rd.memdebug>=4, please install memstrack and procps-ng
dracut: dracut module ‘squash’ will not be installed, because command ‘mksquashfs’ could not be found!
dracut: dracut module ‘squash’ will not be installed, because command ‘unsquashfs’ could not be found!
dracut: dracut module ‘systemd-coredump’ will not be installed, because command ‘coredumpctl’ could not be found!
dracut: dracut module ‘systemd-coredump’ will not be installed, because command ‘/usr/lib/systemd/systemd-coredump’ could not be found!
dracut: dracut module ‘systemd-repart’ will not be installed, because command ‘systemd-repart’ could not be found!
dracut: dracut module ‘systemd-resolved’ will not be installed, because command ‘resolvectl’ could not be found!
dracut: dracut module ‘systemd-resolved’ will not be installed, because command ‘/usr/lib/systemd/systemd-resolved’ could not be found!
dracut: dracut module ‘dbus-broker’ will not be installed, because command ‘dbus-broker’ could not be found!
dracut: dracut module ‘rngd’ will not be installed, because command ‘rngd’ could not be found!
dracut: dracut module ‘lvmmerge’ will not be installed, because command ‘lvm’ could not be found!
dracut: dracut module ‘lvm’ will not be installed, because command ‘lvm’ could not be found!
dracut: dracut module ‘tpm2-tss’ will not be installed, because command ‘tpm2’ could not be found!
dracut: dracut module ‘iscsi’ will not be installed, because command ‘iscsi-iname’ could not be found!
dracut: dracut module ‘iscsi’ will not be installed, because command ‘iscsiadm’ could not be found!
dracut: dracut module ‘iscsi’ will not be installed, because command ‘iscsid’ could not be found!
dracut: dracut module ‘memstrack’ will not be installed, because command ‘memstrack’ could not be found!
dracut: memstrack is not available
dracut: If you need to use rd.memdebug>=4, please install memstrack and procps-ng
dracut: dracut module ‘squash’ will not be installed, because command ‘mksquashfs’ could not be found!
dracut: dracut module ‘squash’ will not be installed, because command ‘unsquashfs’ could not be found!
dracut: *** Including module: systemd ***
dracut: *** Including module: systemd-initrd ***
dracut: *** Including module: i18n ***
dracut: *** Including module: drm ***
dracut: *** Including module: plymouth ***
dracut: *** Including module: kernel-modules ***
dracut: *** Including module: kernel-modules-extra ***
dracut: *** Including module: resume ***
dracut: *** Including module: rootfs-block ***
dracut: *** Including module: suse-btrfs ***
dracut: *** Including module: suse-xfs ***
dracut: *** Including module: terminfo ***
dracut: *** Including module: udev-rules ***
dracut: Skipping udev rule: 40-redhat.rules
dracut: Skipping udev rule: 50-firmware.rules
dracut: Skipping udev rule: 50-udev.rules
dracut: Skipping udev rule: 91-permissions.rules
dracut: Skipping udev rule: 80-drivers-modprobe.rules
dracut: *** Including module: dracut-systemd ***
dracut: *** Including module: haveged ***
dracut: *** Including module: ostree ***
dracut: *** Including module: usrmount ***
dracut: *** Including module: base ***
dracut: *** Including module: fs-lib ***
dracut: *** Including module: shutdown ***
dracut: *** Including module: suse ***
dracut: *** Including module: suse-initrd ***
dracut: *** Including modules done ***
dracut: *** Installing kernel module dependencies ***
dracut: *** Installing kernel module dependencies done ***
dracut: *** Resolving executable dependencies ***
dracut: *** Resolving executable dependencies done ***
dracut: *** Hardlinking files ***
dracut: Mode: real
dracut: Files: 800
dracut: Linked: 2 files
dracut: Compared: 0 xattrs
dracut: Compared: 92 files
dracut: Saved: 339,1 KiB
dracut: Duration: 0.006888 seconds
dracut: *** Hardlinking files done ***
dracut: *** Generating early-microcode cpio image ***
dracut: *** Constructing AuthenticAMD.bin ***
dracut: *** Store current command line parameters ***
dracut: Stored kernel commandline:
dracut: resume=UUID=f88ef4b8-6abe-4aca-ab40-884dc7932c8e
dracut: root=UUID=42a6931c-dd5c-40f9-949d-8a14ee47ab67 rootfstype=ext4 rootflags=rw,relatime
dracut: *** Stripping files ***
dracut: *** Stripping files done ***
dracut: *** Creating image file ‘/boot/initrd-5.14.21-150400.24.28-default’ ***
dracut: *** Creating initramfs image file ‘/boot/initrd-5.14.21-150400.24.28-default’ done ***
CA enrolled. Skip /etc/uefi/certs/40905999.crt
Habe den Rechner noch nicht rebootet und habe alles bis jetzt remote gemacht um solche Ausgaben sichern zu können.
/boot/grub/grub.cfg habe ich mir bereits angesehen und verglichen. AUßer der neueren Kernelversion kann ich erst einmal keinen Unterschied feststellen.
yast2 läßt sich noch remote starten (gab noch keinen Reboot!) Das einzige was mir im Bootmenu noch einfällt wäre vielleicht die CPU Mitigation. Überlege ob ich sie auf AUS setze (ist ja eh eine AMD CPU)
That are only Infos, that something is not installed.
Same here…
dracut: dracut module 'systemd-resolved' will not be installed, because command 'resolvectl' could not be found!
LANG=C cnf resolvectl
The program 'resolvectl' can be found in following packages:
* systemd-network path: /usr/bin/resolvectl, repository: zypp (repo-oss) ]
* systemd-network path: /usr/bin/resolvectl, repository: zypp (repo-sle-update) ]
Try installing with:
zypper install systemd-network
Danke für den Hinweis.
Inzwischen habe ich das System rebootet. Im Bootprozess bleibt es wieder hängen.
Mit einem Opensuse leap 15.3 kann ich ein Rescuesystem booten vom USB Stick.
Aus Bequemlichkeit habe ich ein aktuelles Knoppix genommen und der Rechner bootet damit ohne Probleme. SSH gestartet um bequemer remote arbeiten zu können.
Alle Festplatten sind problemlos zugreifbar.
Ich habe /var/log geprüft: Der Bootprozess kommt nicht so weit in eines der Logfiles etwas zu schreiben. (messages warn, …)
dmesg und journalctl schreiben in /run was leider nicht persistent ist und deswegen leer ist.
Folgendes finde ich merkwürdig:
Mein PC hat folgendes /boot Verzeichnis:
**root@Microknoppix**:**/media/knoppix/42a6931c-dd5c-40f9-949d-8a14ee47ab67/boot**# ll -h
total 56M
-rw-r--r-- 1 root root 1.7K Jun 1 15:51 boot.readme
-rw-r--r-- 1 root root 246K Oct 12 03:58 config-5.14.21-150400.24.28-default
drwxr-xr-x 2 root root 4.0K Aug 10 06:09 **dracut**
drwxr-xr-x 2 root root 4.0K Oct 27 10:26 **efi**
drwxr-xr-x 6 root root 4.0K Nov 2 06:50 **grub2**
lrwxrwxrwx 1 root root 35 Nov 2 06:43 **initrd** -> initrd-5.14.21-150400.24.28-default
-rw------- 1 root root 23M Nov 2 06:50 initrd-5.14.21-150400.24.28-default
-rw-r--r-- 1 root root 445K Oct 12 04:30 symvers-5.14.21-150400.24.28-default.gz
-rw-r--r-- 1 root root 484 Oct 12 04:30 sysctl.conf-5.14.21-150400.24.28-default
-rw-r--r-- 1 root root 4.9M Oct 12 04:25 System.map-5.14.21-150400.24.28-default
-rw-r--r-- 1 root root 17M Oct 12 04:38 vmlinux-5.14.21-150400.24.28-default.gz
lrwxrwxrwx 1 root root 36 Nov 2 06:43 **vmlinuz** -> vmlinuz-5.14.21-150400.24.28-default
-rw-r--r-- 1 root root 11M Oct 12 06:15 vmlinuz-5.14.21-150400.24.28-default
Laut den Boot Messages wird der initrd geladen. Wieso ist der initrd vom Server erheblich größer als der vom PC?
Ich hatte jetzt schon überlegt [FONT=courier new]initrd-5.14.21-150400.24.28-default vom PC rüberzukopieren und nachzuschauen ob das dann bootet.