I am trying to install either Leap 15.5 (kernel 5.14.21-150500.55.31-default) or Tumbleweed (kernel 6.5.8-1-default) as of the versions available for download today (28/10/2023) on a clean NVME M2 SSD (no other OS or previous partitions on that disk). This is a fresh install, no VM and no update, because I am running on said compute system a very stable but severely outdated Leap 15.2. The computer is an I7-5930 with 128GB RAM and NVIDIA 980TI on a Gigabyte X99-SLI; the SSD in question is a 4TB Samsung 990PRO.
While the installation completes without issue, I cannot boot into the system (not even in secure mode). It freezes when grub2 initiates initrd and is supposed to mount the temporary root filesystem. I have played with all of the “usual” kernel boot parameters, with/without secure boot, and I confirmed that the install and the UUIDs in grub.cfg are correct without any success. Even in a more verbose mode nothing is ever printed after “Loading initial ramdisk” and all config files look normal to me.
Since this affects two very different kernels, I am wondering if there was something more fundamental that I am missing? I have not done a truly fresh install in at least 2 years on any of my computers, because I am usually just using the zypper -dup distribution updates when really necessary to not unnecessarily break heavily utilized compute systems after Opensuse became so unstable and buggy over the last decade, i.e. I am quite rusty with the sensitivities of grub2 / initrd or initramfs.
Any ideas are truly appreciated. As it stands right now I can neither install Leap 15.5 nor Tumbleweed using the installers available on opensuse.org today. I do have a working Leap 15.2
It’s entirely unclear to me where this 15.2 lives. Are both unbootable attempts on the same 4TB Samsung as 15.2? Same PC? How about showing us the current state of things from booting 15.2, unless 15.2 is in some computer other than the target of the new installation:
Please run sudo inxi -U to update 15.2’s ancient and broken inxi first. If there are two NVMEs or NVME + SSD or HDD in a single i7-5930, include all above commands from a boot that includes both/all installed in the PC at once.
I was probably not clear enough. 15.2 lives on a completely different drive and is physically disconnected (as in unplugged) from the system and hence also not mounted at all or in any form listed as a potential boot device in the BIOS. The new install gets its own fresh drive; I am, for the time being also not mounting any of my purely XFS data disks. You can think of the problem as a completely isolated fresh Tumbleweed or 15.5 install on a vanilla computer with a single unshared SSD. I am doing a simple partitioning with
nvme0n1p1 is /boot/efi (FAT32), nvme0n1p2 is / (btrfs), nvme0n1p3 is /home (XFS), and nvme0n1p4 is /swap; everything lives on the same drive (see parted below).
I am not sure how I can get into the system to run efibootmgr? The grub.cfg references the correct UUID.
Partition Table (note I am obtaining this after booting into the rescue system; see above for the mount points in the actual system).
parted -l
Model: (scsi)
Disk /dev/sdd: 63.3GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:
Number Start End Size Type File system Flags
1 141kB 3883kB 3742kB primary fat16 esp
2 3883kB 213MB 209MB primary boot, hidden
Model: Samsung SSD 990 PRO 4TB (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
lsblk – not sure how this adds knowledge from the rescue system; I culled the other sdX devices which are not mounted as long as I am trying to get a plain install booting. The mount points and filesystems I listed above.
inxi – I ran the one that came with the install, i.e. likely rather new. Please note that the listed kernel is from the rescue system! The Leap 15.5 kernel that is installed from the repositories is 5.14.21.-150500.55.31-default and for Tumbleweed it is 6.5.8-1-default. I have currently tried to install Tumbleweed, that’s why inxi lists that. Tumbleweed does not even boot into rescue mode with the installer USB stick and freezes in the same way during the “initial ramdisk” loading. I am not exactly sure if this makes a difference, but the Leap 15.5 installer rescue systems runs a slightly older kernel than what is actually installed from the repositories. I am not sure why the graphics card would matter at this point because the freeze happens long before initializing runlevel 5. I usually avoid wayland like the plague due to massive issues over Xorg, but it comes now as default. Not sure if that could be a cause, but the entire freeze looks more like some files not being found correctly prior to the actual boot.
I have confirmed that the bootloader (grub2) references the correct UUID. I haven’t used anything but grub since the days Suse defaulted to LILO, but I am wondering if trying systemd would be something? Anyway the correct ROOT dir for /dev/nvme0n1p2 is set in grub2 as far as I can tell from the grub.cfg and from actually double checking in grub’s edit mode.
Is there a way to get initrd into a more verbose mode to see when it actually freezes?
I am not sure why anything from the unplugged 15.2 would matter? I only have one NVME M2 slot and can literally only have one OS live at the time. I am not using multiple OS in parallel.
Efibootmgr without any options simply fetches information from NVRAM. Any Gnu/Linux distro you can boot into UEFI mode can fetch and report the same information.
I suppose that may be true for Gnome users, and in Fedora possibly others, but I don’t think any other DE uses it by default unless Plasma, but at least with Plasma usually comes SDDM, which allows X selection type at login screen, and remembers it for subsequent logins. I don’t have Gnome installed anywhere, or any DM that is compatible with Wayland except for a small and dwindling number of SDDMs.
Inxi releases average about 6 week intervals. TW more or less keeps up. Leap does not. Any time forum help from running it is sought, Leap users should have run inxi -U since it was originally installed, and again any time an rpm update was applied. Also it lacks sometimes important data that it cannot acquire when it is run outside of X.
To my knowledge ‘lsblk -f’ only includes mount points on a system that is actually installed, running, and has devices mounted. Again, the system always freezes during the installation and when “Loading initial ramdisk” is prompted during the very first reboot after the installer completes formatting and partitioning the SSD and does the first reboot following the pure package installation. The output I posted is indeed from running ‘lsblk -f’ after booting into rescue mode, mounting the installed and not booting OS’ root partition, and chrooting to it. It’s empty. No mount points are listed! Sure, when I run it in rescue mode without chrooting it prints the UUIDs, but only the USB drive used to boot into rescue mode is actually mounted. It seems like the installation process is not even complete, yet. Files like /etc/fstab do not include any of the partitions on the NVME target drive, i.e. the installer has not yet correctly created the final /etc/fstab. When is this supposedly happening? I assumed it would be done when the drive is partitioned according to my initial settings.
I was a bit busy for a few days and could not work on it. Something is not going well with the newer Opensuse distributions. I grabbed a 15.5 KDE Live and made a bootable stick. On this computer not even the Live OS boots. It also freezes at Loading initrd. I have confirmed that the stick really boots on one of my other computers.
Yes, I would love to update the BIOS, however, I am already running the latest version which is 5 years old. Are there some third party BIOS flashes around?
In any case, I don’t think it is the SSD, because I can fully access it with no problems with an older Opensuse distro.
Also, it’s a GA-X99P; no problem with modern M2 SSD in the past. I am always using UEFI-only. I just tried a 16-bit EFI partition with no luck. It again hangs when “Loading initial ramdisk …” during the first reboot.
@aysCanada you have an esp on a msdos disk…that won’t work, then you have an esp on the nvme device which should be the one used… unplug sdd (Or is that the install media?) from power and sata, boot and see what happens…
@malcolmlewis , yes sdd is the USB drive / installer. I don’t have any msdos drive. Indeed I have not used Windows other than in a virtualbox since the early 2000. The board does support the 4TB disk just fine. I just grabbed the newest MX Linux installer and it installed and runs just fine on that very disk. This has something to do with the Opensuse installation process. I would prefer sticking with Suse, as I have been a sole Suse OS user since 7.3 and I am extremely familiar with the unique non-standard flavor.
@aysCanada On the other install, did you capture the kernel version or output from cat /proc/cmdline?
At openSUSE grub, select the boot option and press e to edit grub. Can you add the following two options to the linux/linuxefi line (at the end) nomodeset plymouth.enable=0 and press F10 to boot with those (temporary) options.
Unfortunately, I did not write down the exact kernel version on MX Linux 23.1 but it was a 6.1.xxx, i.e. older than the current Tumbleweed 6.5.9-1 but younger than the current, also defunct Leap 15.5 with 5.14.21-150500.55.31.
I had tried to boot with nomodeset before, but not with disabling plymouth, which unfortunately does not help with the freezing. Is there a way to have a verbose loading of the initial ramdisk? It would help to figure out when exactly the system freezes.
Since MX still uses ext4 and I always have some issues with btrfs on opensuse, but accept the random freezes due to the advantages of snapshots, I even tried installing Tumbleweed solely on an ext4 filesystem. No change.
I should add, I used the latest Tumbleweed installer from yesterday in the hope that the minor kernel update from 6.5.8-1 —> 6.5.9-1 would perhaps make a difference.
@aysCanada, I wonder if it’s the NVMe controller and the kernel… can you add the following to the grub boot options then nvme_core.default_ps_max_latency_us=0 and boot.
With the forum being down yesterday, I tried to go back in releases to identify when the initrd command stopped working out of the box. Leap 15.4 does freeze as well. 15.3 installs just fine on the nvme. I noticed that 15.3 by default uses a legacy /boot instead of an efi boot. Going the zypper dup route without changing the partions from 15.3 to 15.4 (in the hope to then go further) also freezes when loading initrd during the first reboot. It looks like whatever triggers the freeze may originate in a fundamental change from 15.3 to 15.4?
@aysCanada So if UEFI boot doesn’t work then either your hardware does not support UEFI M.2 boot, or the controller…
I had a WD NVMe like that on an Intel board that did not support UEFI boot from NVMe and added a small USB device with both /boot/efi and /boot. It also had a funky controller and had the add that boot option when it was in my HPZ440 which does support NVMe boot…
The GA-X99P is a member of the first generation of Intel chipsets that supports M.2/PCIe booting. Is this device in an adapter in PCIe slot, or in a dedicated motherboard M.2 socket?