Opensuse Leap 15.4 Boot von USB Stick friert ein auf Lenovo SR635

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

Die Installation mit Opensuse Leap 15.3 war erfolgreich. Alles hat funktioniert. Updates konnten alle installiert werden.

Dann habe ich ein Update nach Leap 15.4 gemacht nach Vorgabe aus der SDB. Update war erfolgreich.
Aber der Rechner bootet jetzt nicht mehr:

Booting openSUSE Leap 15.4
Loading Linux 5.14.21-150400.24.21-default …
Loading initial ramdisk …

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)

initrdefi /boot/initrd-5.14.14.21-150400.24.21-default

Jetzt gehen mir die Ideen aus. Vor allem da ich mit dem Update den Rechner praktisch kaputtschieße.

Das ist von Post #1 hieroben.

Und das von jetzt.

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.

Zeige bitte den Link, den Du zum Herunterladen genutzt hast.

Hast Du die heruntergeladene Datei überprüft](SDB:Download help - openSUSE Wiki)?

Wie hast Du das heruntergeladene .iso-Image auf den USB-Stick transferiert (dd, imagewriter, Etcher, … )?

Tritt das bereits beim Starten des Installationsmediums auf oder erst beim ersten Start des installierten Systems?

Viele Grüße

susejunky

evtl mal wieder das Lenovo Bios???

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?

  1. Ja, ich habe beide Varianten versucht.
  2. 15.3 erfolgreich installiert und alle Online-Updates gemacht. Danach ein Upgrade von 15.3 auf 15.4. Sorry für die Ungenauigkeit.
  3. Das Upgrade habe ich nach SDB:System upgrade to Leap 15.4 - openSUSE Wiki gemacht. Lief fehlerfrei durch. Aber mit dem Reboot war dann wieder das gleiche Fehlerbild da.

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

dracut -f

die initrd neu zu erstellen?

Viele Grüße

susejunky

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:

  1. Leap 15.4 -> Booten per USB Stick scheitert im initrd
  2. Tumbleweed (aktuell) -> Booten per USB Stick scheitert im initrd
  3. Leap 15.3 -> Installation und Betrieb funktioniert
  4. Upgrade von Leap 15.3 auf 15.4 per SDB:System upgrade to Leap 15.4 - openSUSE Wiki -> Booten scheitert im initrd. Damit ist das System ein Brick.
  5. 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.

Im Prinzip ja …

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.

Viele Grüße

susejunky

Hallo,

man muss ja versuchen dem Tag Struktur zu geben…

Folgender Plan:

  1. 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,…
  1. Reboot
  • funktioniert: Jubel anstimmen.
  • funktioniert nicht-> Booten über USB Rescue Stick mit Leap 15.3 und weiter untersuchen…

Noch irgend eine Idee?

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.

Viele Grüße

susejunky

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.

linux:~ # lsb_release -d
Description: openSUSE Leap 15.4

/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

UUPS deutsch:
Nur Infos, bei mir auch…

Daran kann ich nichts auffälliges erkennen. Zwar verwende ich openSUSE Tumbleweed aber bei mir sieht die Ausgabe von “dracut -f” fast genau so aus.

Noch ein Hinweis:

Wenn Du Terminal-Ausgaben in Deinen Beitrag einfügst, dann verwende dabei bitte Code-Tags (das “#” in der Werkzeugleiste des Forum-Editors).

Viele Grüße

susejunky

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:


AMD:/boot # ll -h
insgesamt 143M
-rw-r--r-- 1 root root 1,7K  1. Jun 21:51 boot.readme
-rw-r--r-- 1 root root 246K 12. Okt 09:58 config-5.14.21-150400.24.28-default
drwxr-xr-x 3 root root  16K  1. Jan 1970  efi
drwxr-xr-x 7 root root 4,0K  3. Nov 11:23 grub2
lrwxrwxrwx 1 root root   35  3. Nov 11:22 initrd -> initrd-5.14.21-150400.24.28-default
-rw------- 1 root root  39M  3. Nov 11:23 [FONT=courier new]initrd-5.14.21-150400.24.28-default
-rw-r--r-- 1 root root 445K 12. Okt 10:30 symvers-5.14.21-150400.24.28-default.gz
-rw-r--r-- 1 root root  484 12. Okt 10:30 sysctl.conf-5.14.21-150400.24.28-default
-rw-r--r-- 1 root root 4,9M 12. Okt 10:25 System.map-5.14.21-150400.24.28-default
-rw-r--r-- 1 root root  17M 12. Okt 10:38 vmlinux-5.14.21-150400.24.28-default.gz
lrwxrwxrwx 1 root root   36  3. Nov 11:22 vmlinuz -> vmlinuz-5.14.21-150400.24.28-default
-rw-r--r-- 1 root root  11M 12. Okt 12:15 vmlinuz-5.14.21-150400.24.28-default
-rw-r--r-- 1 root root   65 12. Okt 12:15 .vmlinuz-5.14.21-150400.24.28-default.hmac
[/FONT]

Der Server hat folgendes:


**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.

[/FONT]