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