Leap 15.5 und Tumbleweed booten nach der Installation nicht

@404_UsernameNotFound da das System bei initrd einfriert, also bevor ein NVIDIA Treiber greifen würde, postuliere ich mal, dass das damit nichts zu tun hat.

Ich benutzte/benutze beim Test keine Verschlüsselung. Ersteinmal soll es so laufen.

Und Du hast auch überprüft, dass bei der OS-Installation eine eigene ESP angelegt und mit einem GRUB2/shim-Bootloader (passend zu OS-Version) bestückt wird und dieser auch korrekt im NVRAM Deines UEFIs eingetragen ist und die Boot-Reihenfolge auch entsprechend angepasst wurde?

Wie setzt Du das “physisch abhängen” konkret um (S-ATA-Kabel abziehen, Stromkabel abziehen Komplettausbau bei M.2, …)?

@susejunky Ja, Komplettausbau der M2 SSD, da ich nur einen Slot habe und die neue SSD diesen dann braucht. Das System hat noch mehrere XFS Datenplatten, die zunächst nicht gemounted werden. Inzwischen möchte ich das System erstmal mit der automatischen Partitionierung installieren. Da Leap 15.5 Live auf diesem Computer auch nicht booted und genauso während initrd einfriert, während es auf meinem Thinkpad bootet, gehe ich davon aus, dass es irgendeine Hardware Komponente ist, deren Treiber nicht sauber geladen wird. Daher wäre es toll, wenn man initrd irgendwie zu mehr verbosity überreden könnte, um zu sehen, an welcher Stelle es denn hängt.

Auch wenn diese Platten nicht eingehängt werden, so besteht doch die Möglichkeit, dass sie ESPs beinhalten und diese im NVRAM Deines UEFIs vermerkt sind.

Da Du laut Deinem Beitrag #1 openSUSE Tumbleweed installieren wolltest, hast Du sicherlich auch noch das zugehörige Installationsmedium parat. Von diesem könntest Du das Rescue-System starten und die in #17 genannten Daten ermitteln.

Oder hast Du einen bestimmten Grund aus dem heraus die gewünschten Daten nicht zeigen willst?

@susejunky Nein, die Platten sind reine Datenplatten und enthalten keinerlei EFI oder Legacy Boot Partition, selbst wenn, wäre das egal, da der korrekte Grub2 Eintrag gewählt wird. Das Tumbleweed Rescue System bootet ebenfalls nicht, wie wir im Englischen Forum besprochen hatten. Mit Leap 15.5’s rescue system komme ich rein. So habe ich auch versucht das initrd image neu zu bauen (nach chroot Prozess), was das Problem nicht behoben hat.

Es handelt sich um eine einzige, vollständig zur Verfügung stehende M2 SSD. Die Installation läuft fehlerfrei, aber der erste Bootprozess scheitert während initrd und es bedarf eines harten resets.

Ich respektiere Deine Entscheidung zu Deinem System nur ausgesuchte Informationen in Prosa zur Verfügung zu stellen.

Leider kann ich Dir unter diesen Voraussetzungen nicht weiterhelfen, wünsche Dir aber weiterhin viel Erfolg.

@susejunky ich bin mir nicht sicher, was Du meinst. Du hast nach den gleichen Dingen gefragt, die wir im verlinkten Englischen threat schon besprochen haben. Ferner musst Du mir schon zugestehen am PC sein zu koennen, um Dir nochmal die Partitionstabelle und Hardwareinformation zu erstellen.

Wie gesagt, ich habe das System auf ein voellig naktes reduziert, d.h. eine frische Festplatte und ich lasse Tumbleweed (oder auch 15.5) alles machen, was es will. Alle anderen Festplatten sind physisch abgehaengt (power Kabel raus!) und dem System zur Zeit also voellig unbekannt. Das kann man mir schon glauben.

Ich habe extra fuer Dich auch heute noch die aktuelle Version von Tumbelweed gezogen (nun Kernel 6.6.1) und installiert. Das allererste reboot friert bei initrd, “Loading initial ramdisk”, ein. Reset ist erforderlich. Vom USB Installationsmedium bootet nicht einmal der Rescue Modus, der auch bei initrd einfriert.

Mit einer 15.3 Live disk komme ich ins System und

efibootmgr -v

BootCurrent: 0008
Timeout: 1 seconds
BootOrder: 0000,0006,0007,0008,0004
Boot0000* opensuse-secureboot   HD(1,GPT,5b8d4987-7a25-4643-be00-8cdb6dca1b34,0x800,0x100000)/File(\EFI\OPENSUSE\SHIM.EFI)
Boot0004* Hard Drive    BBS(HD,,0x0)..GO..NO..........S.a.m.s.u.n.g. .S.S.D. .9.9.0. .P.R.O. .4.T.B....................A...........................%8I1A.......D..Gd-.;.A..MQ..L.S.a.m.s.u.n.g. .S.S.D. .9.9.0. .P.R.O. .4.T.B........BO..NO........}.I.n.n.o.s.t.o.r.I.n.n.o.s.t.o.r. .1...0.0....................A.............................J..Gd-.;.A..MQ..L.0.9.0.2.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.9.9.7........BO
Boot0006* opensuse      HD(1,GPT,5b8d4987-7a25-4643-be00-8cdb6dca1b34,0x800,0x100000)/File(\EFI\OPENSUSE\GRUBX64.EFI)..BO
Boot0007* UEFI OS       HD(1,GPT,5b8d4987-7a25-4643-be00-8cdb6dca1b34,0x800,0x100000)/File(\EFI\BOOT\BOOTX64.EFI)..BO
Boot0008* UEFI: InnostorInnostor 1.00, Partition 2      PciRoot(0x0)/Pci(0x1d,0x0)/USB(0,0)/USB(0,0)/HD(2,MBR,0x0,0x1cec18,0xa000)..BOcode here

Boot0008 ist der USB Stick mit 15.3 Live und wie Du siehst gibt es kein konkurierendes OS, dass grub2-efi oder dem BIOS bekannt sind.

Hier die default Partitionstabelle; sda ist der USB Live Stick:

parted -l

Model: Innostor Innostor (scsi)
Disk /dev/sda: 16.2GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags: 

Number  Start   End     Size    Type     File system  Flags
 1      32.8kB  970MB   970MB   primary               boot, type=cd
 2      970MB   991MB   21.0MB  primary  fat16        esp, type=ef
 3      992MB   16.2GB  15.2GB  primary  ext4         type=83

Model: NVMe Device (nvme)
Disk /dev/nvme0n1: 4001GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: 

Number  Start   End     Size    File system     Name  Flags
 1      1049kB  538MB   537MB   fat32                 boot, esp
 2      538MB   1300GB  1299GB  btrfs
 3      1300GB  3866GB  2566GB  xfs
 4      3866GB  4001GB  135GB   linux-swap(v1)        swap

Das zeigt Dir genau eine 32bit ESP vom Live Stick nun abgesehen.

Vielleicht interessiert Dich auch die Hardware; der Kernel ist natuerlich von 15.3 Live.

inxi -F

System:
  Host: localhost.localdomain Kernel: 5.3.18-150300.59.101-default
    arch: x86_64 bits: 64 Desktop: KDE Plasma v: 5.18.6
    Distro: openSUSE Leap 15.3
Machine:
  Type: Desktop Mobo: Gigabyte model: X99P-SLI-CF serial: N/A
    UEFI: American Megatrends v: F25b date: 03/13/2018
CPU:
  Info: 6-core model: Intel Core i7-5930K bits: 64 type: MT MCP cache:
    L2: 1.5 MiB
  Speed (MHz): avg: 1774 min/max: 1200/3700 cores: 1: 1587 2: 1269 3: 1346
    4: 1890 5: 2113 6: 2088 7: 2511 8: 1515 9: 1253 10: 3119 11: 1201 12: 1406
Graphics:
  Device-1: NVIDIA GM200 [GeForce GTX 980 Ti] driver: nouveau v: kernel
  Display: x11 server: X.org v: 1.20.3 with: Xwayland driver: X:
    loaded: nouveau unloaded: fbdev,modesetting,nv,vesa dri: nouveau
    gpu: nouveau resolution: 3840x2160~60Hz
  API: OpenGL v: 4.3 vendor: nouveau mesa v: 20.2.4 renderer: NV120
  API: EGL Message: EGL data requires eglinfo. Check --recommends.
Audio:
  Device-1: Intel C610/X99 series HD Audio driver: snd_hda_intel
  Device-2: NVIDIA GM200 High Definition Audio driver: snd_hda_intel
  API: ALSA v: k5.3.18-150300.59.101-default status: kernel-api
  Server-1: PulseAudio v: 14.2-rebootstrapped status: active (root, process)
Network:
  Device-1: Intel Ethernet I218-V driver: e1000e
  IF: eth0 state: up speed: 1000 Mbps duplex: full mac: 40:8d:5c:b4:74:5d
Drives:
  Local Storage: total: 3.65 TiB used: 589 MiB (0.0%)
  ID-1: /dev/nvme0n1 vendor: Samsung model: SSD 990 PRO 4TB size: 3.64 TiB
  ID-2: /dev/sda vendor: Innostor model: N/A size: 15.08 GiB type: USB
Partition:
  ID-1: / size: 13.83 GiB used: 589 MiB (4.2%) fs: overlay source: ERR-102
Swap:
  Alert: No swap data was found.
Sensors:
  System Temperatures: cpu: 30.0 C mobo: N/A gpu: nouveau temp: 64.0 C
  Fan Speeds (rpm): N/A gpu: nouveau fan: 0
Info:
  Processes: 260 Uptime: 0h 15m Memory: total: 128 GiB available: 125.64 GiB
  used: 2.34 GiB (1.9%) Shell: Bash inxi: 3.3.31

Das BIOS ist das neueste offizielle BIOS, aber das board ist ein paar Jahre alt.

lsblk -f

NAME        FSTYPE   FSVER            LABEL                       UUID                                 FSAVAIL FSUSE% MOUNTPOINT
loop0       squashfs 4.0                                                                                     0   100% /run/overlay/squashfs_container
loop1       ext4     1.0                                          e9098ec1-d667-446f-a7c8-32989e1aa869  888.2M    73% /run/overlay/rootfsbase
sda         iso9660  Joliet Extension openSUSE_Leap_15.3_KDE_Live 2022-11-18-16-07-27-00                              
├─sda1      iso9660  Joliet Extension openSUSE_Leap_15.3_KDE_Live 2022-11-18-16-07-27-00                     0   100% /run/overlay/live
├─sda2      vfat     FAT16            BOOT                        448A-52B6                                           
└─sda3      ext4     1.0              cow                         69c635e0-5fe9-4713-aa12-d05ac252bbb3   12.5G     4% /run/overlay/overlayfs
nvme0n1                                                                                                               
├─nvme0n1p1 vfat     FAT32                                        948E-3B76                                           
├─nvme0n1p2 btrfs                                                 8b12abf7-b515-4d11-b9a5-add8e23a352b                
├─nvme0n1p3 xfs                                                   bc8abf2f-9893-4fb2-9637-7bd9d51dfb71                
└─nvme0n1p4 swap     1                                            810469d6-888d-4f69-a2af-757ca7e8ed64

Und vielleicht noch grub.cfg (nach mounten der root partition der SSD)?

cat grub.cfg
 
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub2-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

### BEGIN /etc/grub.d/00_header ###
set btrfs_relative_path="y"
export btrfs_relative_path
if [ -f ${config_directory}/grubenv ]; then
  load_env -f ${config_directory}/grubenv
elif [ -s $prefix/grubenv ]; then
  load_env
fi

if [ "${env_block}" ] ; then
  set env_block="(${root})${env_block}"
  export env_block
  load_env -f "${env_block}"
fi

if [ "${next_entry}" ] ; then
   set default="${next_entry}"
   set next_entry=
   save_env next_entry
   if [ "${env_block}" ] ; then
     save_env -f "${env_block}" next_entry
   fi
   set boot_once=true
else
   set default="${saved_entry}"
fi

if [ x"${feature_menuentry_id}" = xy ]; then
  menuentry_id_option="--id"
else
  menuentry_id_option=""
fi

export menuentry_id_option

if [ "${prev_saved_entry}" ]; then
  set saved_entry="${prev_saved_entry}"
  save_env saved_entry
  set prev_saved_entry=
  save_env prev_saved_entry
  set boot_once=true
fi

function savedefault {
  if [ -z "${boot_once}" ]; then
    saved_entry="${chosen}"
    if [ "${env_block}" ] ; then
      save_env -f "${env_block}" saved_entry
    else
      save_env saved_entry
    fi

  fi
}

function load_video {
  if [ x$feature_all_video_module = xy ]; then
    insmod all_video
  else
    insmod efi_gop
    insmod efi_uga
    insmod ieee1275_fb
    insmod vbe
    insmod vga
    insmod video_bochs
    insmod video_cirrus
  fi
}

if [ x$feature_default_font_path = xy ] ; then
   font=unicode
else
insmod part_gpt
insmod btrfs
search --no-floppy --fs-uuid --set=root 8b12abf7-b515-4d11-b9a5-add8e23a352b
    font="/usr/share/grub2/unicode.pf2"
fi

if loadfont $font ; then
  if [ "${grub_platform}" = "efi" ]; then
    echo "Please press 't' to show the boot menu on this console"
  fi

  set gfxmode=auto
  load_video
  insmod gfxterm
fi
terminal_input console

for i in gfxterm; do
  if [ x${use_append} = xtrue ]; then
     terminal_output --append $i
  elif terminal_output $i; then
     use_append=true;
  fi
done

insmod part_gpt
insmod btrfs
search --no-floppy --fs-uuid --set=root 8b12abf7-b515-4d11-b9a5-add8e23a352b
insmod gfxmenu
loadfont ($root)/boot/grub2/themes/openSUSE/DejaVuSans-Bold14.pf2
loadfont ($root)/boot/grub2/themes/openSUSE/DejaVuSans10.pf2
loadfont ($root)/boot/grub2/themes/openSUSE/DejaVuSans12.pf2
loadfont ($root)/boot/grub2/themes/openSUSE/ascii.pf2
insmod png
set theme=($root)/boot/grub2/themes/openSUSE/theme.txt
export theme
if [ x${boot_once} = xtrue ]; then
  set timeout=0
elif [ x$feature_timeout_style = xy ] ; then
  set timeout_style=menu
  set timeout=8
# Fallback normal timeout code in case the timeout_style feature is
# unavailable.
else
  set timeout=8
fi
if [ -n "$extra_cmdline" ]; then
  menuentry "Help on bootable snapshot #$snapshot_num" {
    echo "Select the default entry of the snapshot boot menu."
    echo "Examine the snapshot, and if it's OK,"
    echo "   run 'snapper rollback' and reboot."
    echo "See 'System Rollback by Booting from Snapshots'"
    echo "   in the manual for more information."
    echo "  ** Hit Any Key to return to boot menu **  "
    read
  }
fi
### END /etc/grub.d/00_header ###

### BEGIN /etc/grub.d/00_tuned ###
set tuned_params=""
set tuned_initrd=""
### END /etc/grub.d/00_tuned ###

### BEGIN /etc/grub.d/05_crypttab ###
### END /etc/grub.d/05_crypttab ###

### BEGIN /etc/grub.d/10_linux ###
menuentry 'openSUSE Tumbleweed'  --class opensuse --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-8b12abf7-b515-4d11-b9a5-add8e23a352b' {
        load_video
        set gfxpayload=keep
        insmod gzio
        insmod part_gpt
        insmod btrfs
        search --no-floppy --fs-uuid --set=root 8b12abf7-b515-4d11-b9a5-add8e23a352b
        echo    'Loading Linux 6.6.1-1-default ...'
        linux   /boot/vmlinuz-6.6.1-1-default root=UUID=8b12abf7-b515-4d11-b9a5-add8e23a352b  ${extra_cmdline} resume=/dev/disk/by-uuid/810469d6-888d-4f69-a2af-757ca7e8ed64 security=apparmor mitigations=auto
        echo    'Loading initial ramdisk ...'
        initrd  /boot/initrd-6.6.1-1-default
}
submenu 'Advanced options for openSUSE Tumbleweed' --hotkey=1 $menuentry_id_option 'gnulinux-advanced-8b12abf7-b515-4d11-b9a5-add8e23a352b' {
        menuentry 'openSUSE Tumbleweed, with Linux 6.6.1-1-default' --hotkey=2 --class opensuse --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-6.6.1-1-default-advanced-8b12abf7-b515-4d11-b9a5-add8e23a352b' {
                load_video
                set gfxpayload=keep
                insmod gzio
                insmod part_gpt
                insmod btrfs
                search --no-floppy --fs-uuid --set=root 8b12abf7-b515-4d11-b9a5-add8e23a352b
                echo    'Loading Linux 6.6.1-1-default ...'
                linux   /boot/vmlinuz-6.6.1-1-default root=UUID=8b12abf7-b515-4d11-b9a5-add8e23a352b  ${extra_cmdline} resume=/dev/disk/by-uuid/810469d6-888d-4f69-a2af-757ca7e8ed64 security=apparmor mitigations=auto
                echo    'Loading initial ramdisk ...'
                initrd  /boot/initrd-6.6.1-1-default
        }
        menuentry 'openSUSE Tumbleweed, with Linux 6.6.1-1-default (recovery mode)' --hotkey=3 --class opensuse --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-6.6.1-1-default-recovery-8b12abf7-b515-4d11-b9a5-add8e23a352b' {
                load_video
                set gfxpayload=keep
                insmod gzio
                insmod part_gpt
                insmod btrfs
                search --no-floppy --fs-uuid --set=root 8b12abf7-b515-4d11-b9a5-add8e23a352b
                echo    'Loading Linux 6.6.1-1-default ...'
                linux   /boot/vmlinuz-6.6.1-1-default root=UUID=8b12abf7-b515-4d11-b9a5-add8e23a352b single  ${extra_cmdline}
                echo    'Loading initial ramdisk ...'
                initrd  /boot/initrd-6.6.1-1-default
        }
}

### END /etc/grub.d/10_linux ###

### BEGIN /etc/grub.d/20_linux_xen ###

### END /etc/grub.d/20_linux_xen ###

### BEGIN /etc/grub.d/20_memtest86+ ###
### END /etc/grub.d/20_memtest86+ ###

### BEGIN /etc/grub.d/25_bli ###
if [ "$grub_platform" = "efi" ]; then
  insmod bli
fi
### END /etc/grub.d/25_bli ###

### BEGIN /etc/grub.d/30_os-prober ###
### END /etc/grub.d/30_os-prober ###

### BEGIN /etc/grub.d/30_uefi-firmware ###
if [ "$grub_platform" = "efi" ]; then
        menuentry 'UEFI Firmware Settings' $menuentry_id_option 'uefi-firmware' {
                fwsetup --is-supported
                if [ "$?" = 0 ]; then
                        fwsetup
                else
                        echo "Your firmware doesn't support setup menu entry from a boot loader"
                        echo "Press any key to return ..."
                        read
                fi
        }
fi
### END /etc/grub.d/30_uefi-firmware ###

### BEGIN /etc/grub.d/40_custom ###
# This file provides an easy way to add custom menu entries.  Simply type the
# menu entries you want to add after this comment.  Be careful not to change
# the 'exec tail' line above.
### END /etc/grub.d/40_custom ###

### BEGIN /etc/grub.d/41_custom ###
if [ -f  ${config_directory}/custom.cfg ]; then
  source ${config_directory}/custom.cfg
elif [ -z "${config_directory}" -a -f  $prefix/custom.cfg ]; then
  source $prefix/custom.cfg
fi
### END /etc/grub.d/41_custom ###

### BEGIN /etc/grub.d/80_suse_btrfs_snapshot ###
btrfs-mount-subvol ($root) /.snapshots @/.snapshots
if [ -f "/.snapshots/grub-snapshot.cfg" ]; then
  source "/.snapshots/grub-snapshot.cfg"
fi
### END /etc/grub.d/80_suse_btrfs_snapshot ###

### BEGIN /etc/grub.d/90_persistent ###
### END /etc/grub.d/90_persistent ###

### BEGIN /etc/grub.d/95_textmode ###
if [ "${grub_platform}" = "efi" ]; then
  # On EFI systems we can only have graphics *or* serial, so allow the user
  # to switch between the two
  hiddenentry 'Text mode' --hotkey 't' {
    set textmode=true
    terminal_output console
  }
fi
### END /etc/grub.d/95_textmode ###

Hast Du nun vielleicht eine Idee, was hier los ist?

Danke!

Um ehrlich zu sein ist der ganze Thread recht lehrreich für mich und ich habe jetzt noch mal in die dracut-manpage geschaut um rauszufinden ob man das Geschehen während des Ladens vom initramfs auch verbose bekommen kann.

Zitat aus der manpage-Sektion troubleshooting:

Identifying your problem area
1. Remove 'rhgb' and 'quiet' from the kernel command line
2. Add 'rd.shell' to the kernel command line. This will present a shell should dracut be unable to locate your root device
3. Add 'rd.shell rd.debug log_buf_len=1M' to the kernel command line so that dracut shell commands are printed as they are executed
4. The file /run/initramfs/rdsosreport.txt is generated, which contains all the logs and the output of all significant tools, which are mentioned later.

Quelle: dracut 056

Ich kann die Auswirkungen der Parameter gerade mangels Zugriff auf meinen openSUSE-Rechner nicht testen. Wenn du glaubst, dass dir das bei der Ursachensuche helfen kann kannst du die command line parameter ja mal testen, sofern noch nicht geschehen.

Zur Erläuterung:

Ich kenne Dein System nicht und habe auch keinen Zugriff darauf. Bei meinen Systemen tritt das von Dir beschriebene Problem nicht auf (und ist bisher so auch noch nie aufgetreten).

Um das von Dir beschriebene Problem näher untersuchen zu können, ist es ein erster Schritt konkrete (und möglichst aktuelle) Informationen aus Deinem System mit den gleichwertigen aus meinem System zu vergleichen und eventuelle Abweichungen weiter zu untersuchen.

Es war (und ist) nicht meine Absicht unfreundlich zu sein oder Dich gar persönlich anzugreifen. Sollte ich diesen Eindruck erweckt haben, so bitte ich das zu entschuldigen.

Was mir an Deinen Informationen bisher aufgefallen ist:

Bei der von Dir gezeigten Ausgabe von efibootmgr sind die Einträge Bootxxxx nicht fortlaufend nummeriert (1,2,3 und 5 fehlen). Bei meinen Systemen entstehen solche Lücken nur dann, wenn ich mit efibootmgr -b n -B Einträge explizit lösche. Auch hätte ich erwartet noch Einträge der “Alt”-Installationen zu sehen. Das alles hat zwar sehr wahrscheinlich keine Relevanz bezüglich Deines Problems, aber momentan habe ich keine Erklärung dafür.

Weiter sind mir keine Abweichungen zu meinem System aufgefallen.

Folgende Fragen habe ich noch:

Tritt das Problem auch dann auf, wenn Du alle Deine verbauten Datenträger bei der Installation (und danach beim ersten Systemstart) aktiv lässt?

Dass der Installer startet, das Rettungssystem aber nicht, das kenne ich so nicht und kann es momentan weder nachvollziehen noch erklären.

@404_UsernameNotFound , das klingt sehr vielversprechend und ich werde das heute Abend ausprobieren. Nach solchen kernel parametern hatte ich bisher vergeblich gesucht und deshalb auch mein orginaler post. Ich dachte immer dracut ist nur zum Bauen des initrd images und spielt beim eigentlichen Bootvorgang keine Rolle mehr. Daher habe ich vielleicht an der falschen Stelle gesucht.

Danke und ich melde mich am Abend (wir sind 6 Stunden hinterher) dann mit dem Ergebnis.

@susejunky Danke für die Rückmeldung. Ja ich habe eine komplette Neuinstallation nach dem abhängen der anderen Platten durchgeführt. Das die Boot Nummerierung nicht kontinuierlich ist, ist in der Tat eigenartig und war mir gar nicht aufgefallen. Ich bin kein UEFI Experte, aber bleiben eventuell alte Information trotz Formatierung im BIOS/NVRAM, die dann eine Art Platzhalter implementieren, und wie kann man den evt. zurücksetzen. Ich dachte, das geschieht mit efibootmgr bzw. ist nach einer frischen Installation mit forced formating gar nicht extra nötig.

@404_UsernameNotFound ich habe die dracut/initrd boot parameters getestet. Leider wird noch immer nichts geprintet und nach dem reset mit 15.3 Live habe ich versucht, mir

/run/initramfs/rdsosreport.txt

anzusehen, aber das gesamte Verzeichnis ist leer. Sehr merkwürdig. Es scheint so, als ob die SSD evt. nicht gesehen wird bzw. der crash sehr früh passiert?

Eigentlich wollte ich wissen, ob Du auch eine Installation durchgeführt hast ohne die restlichen Datenträger zu deaktivieren.

@susejunky das hatte ich als erstes getan, da ich nicht mit diesen Problemen gerechnet hatte. Danach habe ich das System immer weiter vereinfacht, also die anderen Festplatten zuerst nicht mounten lassen, dann physisch abgehängt. Genauso mit den Partitionen. Bis es läuft, lasse ich alles auf default, erzwinge aber eine Formatierung.

Ich habe gestern auch mal Fedrora 39 frisch installiert. Das lief zunächst ohne Probleme, als ich dann aber einen neuen Kernel nutzen wollte, ist es auch beim booten hängengeblieben. Ich kenne mich aber als 20+ Jahre Suse Mensch nicht mit den Eigenheiten anderer Distributionen aus.

Was wurde denn zwischen dem letzten funtionierenden Suse, Leap 15.3 und 15.4 fundamental geändert, das den Bootprozess beeinflussen könnte?

Da ich ausschließlich openSUSE Tumbleweed nutze, kann ich zu den openSUSE Leap Versionen nichts sagen.

Hast Du schon einmal überprüft, ob das bei der Installation erzeugte initrd alle Treiber enthält, die erforderlich sind, um auf eine NVMe zuzugreifen (nvme, nvme-core, …)?

@susejunky leider bekomme ich Tumbleweed nicht zum Laufen. Ich habe heute

openSUSE-Tumbleweed-NET-x86_64-Snapshot20231117-Media.iso

gezogen und dieses bootet nicht einmal den Installer.

Kann es sein, dass X99 LGA-2011-v3 und die Heswell CPUs nicht mehr vom aktuellen Kernel unterstützt werden?

Laut Deinem Beitrag #1 hattest Du aber openSUSE Tumbleweed bereits einmal installiert (konntest es aber nach der Installation nicht starten). Und in Beitrag #19 hast Du berichtet, dass Du das RescueSystem von diesem Installationsmedium nicht starten kannst.

Einerseits ist es also möglich auf Deinem Rechner das Installationssystem zu starten und sogar einen Installation erfolgreich (d.h. bis zum Neustart) abzuwickeln (Hardware-Probleme erscheinen damit relativ unwahrscheinlich).

Andererseits lässt sich aber das Rescuesystem vom identischen Medium nicht starten (obwohl dem RescueSystem die selben Resourcen zur Verfügung stehen, wie dem Installationssystem).

Diesen Sachverhalt habe ich so noch nie gesehen und habe im Moment auch keine Erklärung dafür.

@susejunky

Laut Deinem Beitrag #1 hattest Du aber openSUSE Tumbleweed bereits einmal installiert (konntest es aber nach der Installation nicht starten). Und in Beitrag #19 hast Du berichtet, dass Du das RescueSystem von diesem Installationsmedium nicht starten kannst.

Das ist richtig. Allerdings wird, wie Du weißt, wird für Tumbleweed alle paar Tage ein neues Image bereitgestellt und in den 2-3 Wochen in denen ich vergeblich versuche, Tumbleweed zum Laufen zu bekommen, gab es zum Beispiel mindestens 3 kleinere Kernel updates: 6.5.8-1, 6.5.9-1, und nun 6.6.1. Bei Suse ist das nicht unüblich, daß Kernels nicht gleich auf jeder Hardware laufen und daher habe ich mit jedem kleinen Update die Hoffnung, dass dies meine Schwierigkeiten behebt. Das Rescue System konnte ich vom Tumbleweed Installationsmedium nie starten. Deshalb hatte ich dann mal Leap 15.5 probiert; dort läßt sich zumindest das Rescue System booten. Ich nehme übrigens immer den gleichen USB Stick und “brenne” quasi jedes Mal ein frisches image. Beim Tumbleweed Snapshot vom 17.11.23 (Kernel 6.6.1), läuft nicht einmal der Installer durch. Kurz vor Schluss erfolgt ein automatisches Reset und dann geht nicht mal grub2, da die Installation noch nicht abgeschlossen war. Sehr merkwürdig.

Da auch Leap 15.5 “nach” erfolgreicher Installation, d.h. Partitionen sind angelegt und die Software installiert, beim ersten automatischen Reboot hängen bleibt, hatte ich dann zunächst Leap 15.4 und, da das auch nicht lief, Leap 15.3 frisch installiert. Leap 15.3 läuft ohne Probleme. Ich habe jedes Mal die gleichen Filesysteme und Partitionen angelegt. Dann habe ich auch vergeblich versucht, von 15.3 auf 15.4 per zypper dup zu gelangen, was ich eigentlich immer benutze, aber auf dem Rechner nicht mehr konnte, da ich ürsprünglich eine selbst gebraute, über die Jahre chaotisch gewordene Mixture aus 15.1 und 15.2 auf einer zu kleinen und inzwischen recht alten Intel 750 nvme SSD (400GB) am Laufen hatte.

Was ich auch eigenartig finde, ist das die Installer von Tumbleweed und auch Leap 15.5 ewig brauchen, in die grafische Oberfläche zu booten. Sie scheinen eingefroren zu sein, sind es aber nicht. Man muß nur sehr sehr lange warten bis die grafische Oberfläche startet. Bei 15.3 geht es im Vergleich relativ schnell.

Ich überlege nun Leap 15.3 zu installieren und mich durch kompilieren neuerer Kernels oder die vorkompilierten rpms an die Problematik von der anderen Seite heranzutasten. Wenn ich wüßte, wann das Problem zum ersten Mal auftritt, kann ich eventuell herausfinden, welches Modul das Problem auslöst.

Alternative Frage: Kann ich einfach den 5.3.18 Kernel, der läuft, einfrieren und ansonsten alles andere updaten oder gibt es dann package dependency Probleme? Ich habe das noch nie von einer Distributionsversion zu nächsten bzw. hier zur über-übernächsten gemacht.

Dabei handelt es sich aber in aller Regel um “brandneue” Hardware. Soweit ich Dich verstanden habe, ist Dein System, abgesehen von der NVMe, aber bereits mehrere Jahre alt.

Die von Dir verwendete 4TB Samsung 990PRO NVMe ist allerdings wirklich sehr neu und wäre meines Erachtens auch eine potentielle Fehlerquelle aber da nach Deiner Aussage, sogar openSUSE Leap 15.2 mit dieser NVMe umgehen kann, ist es eher unwahrscheinlich, dass openSUSE Tumbleweed ein Problem mit dieser NVMe hat.

Was die Kernel-Version von openSUSE Tumbleweed (aktuell: 6.6.1) anbelangt, so ist diese in aller Regel recht nahe an der offiziellen Linux-Kernel-Version (6.6.1). Wie umfangreich die Abweichungen des openSUSE-Kernels vom offiziellen Kernel sind, kann ich nicht beurteilen, aber man kann jederzeit auch den offiziellen Kernel (Paket kernel-vanilla) unter openSUSE verwenden.

Aus meiner Sicht hast Du nur dann eine Chance das Problem zu lösen, wenn Du Dich auf eine definierte Version (die sich auf Deinem System zumindest installieren lässt, z.B. openSUSE Leap 15.5) festlegst und dann versuchst, für die sich daraus ergebenden Probleme, hier im Forum Unterstützung zu finden.

Und wie ich bereits mehrfach gesagt habe: Sollte bei dieser Version zwar der Installer aber nicht das Rescue-System startbar sein, dann dürfte dieser Sachverhalt ein vielversprechender Ansatzpunkt für die Problemanalyse sein.

@aysCanada :

Im englischsprachigen Forum gibt es einen Beitrag in dem ein ähnliches Problem wie das Deine geschildert wird und im Rahmen dessen ein Fehlerbericht erstellt wurde.

Es hat sich bereits einer der SUSE-Kernel-Entwickler in dem Bericht gemeldet. Du solltest Dich ebenfalls in den Bericht einbringen und insbesondere darauf hinweisen, dass Du zwar das Installationssystem aber nicht das Rescue-System vom Installationsmedium starten kannst.