I’ve created an installation USB stick using Rufus from Windows with the latest Leap 16 Beta and when trying to install it on a ThinkPad T490s, it hangs at “Loading initrd” step before it reboots. I tried in BIOS, UEFI-only and Dual mode, with the same result.
I’ve had a similar situation with an installed Leap 16 Beta on a Dell Optiplex 5080 mini workstation, after a recent “zypper dup” upgrade, but that was temporarily resolved by selecting an older kernel from GRUB menu. However, I’m at a loss about the installer. Is there a known issue with the latest kernel? Should I wait for a future release of a new installer?
I currently have the same problem with the network installer as well as the offline image when trying to install it to a VM. So I don’t think the problem is related to the USB stick, but is a problem with the current images.
I cycled through all the available options available on my system: UEFI only, Legacy (BIOS, both (Legacy first), to no avail. The fact that it happened on an already installed system after an update (same behavior, as stated above, hanging after Loading initrd made me think it’s probably related to how the newly installed kernel is handled?
i have cycled through uefi ( with and without secureboot- from the install menu boot options ) and using bios
the 128 g image that virt-manager makes will not boot
no matter what
on to a test
try 15.6 VM and make a 128 g ext4 drive
then try installing on that
@johnvv when creating the VM did you select customize before install and ensure UEFI was selected, nothing to do with the installer? It should default to secure boot in tiano-core.
as you can see, with UEFI and Secure Boot enabled. From the many, many options I just selected the second “UEFI” when creating the VM. After selecting the image, I choose “Leap 16.0” for the OS. Everything else just default.
One CPU core is at 100% during this phase.
The only difference I see (besides the UUID, memory size and number of cores) is <type arch="x86_64" machine="pc-q35-8.2">hvm</type> while yours is <type arch="x86_64" machine="pc-q35-10.0">hvm</type>. This might be because my host is Leap 15.6 and yours might be TW.
The installation of the above mentioned image was without chipset cahnge. It went through, but just as the original poster, the installed OS could not be booted, and again hang at loading initrd,
I then tried to change the chipset, but then got “Installation konnte nicht fertiggestellt werden: «XML Fehler: The PCI controller with index=‘0’ must be model=‘pci-root’ for this machine type, but model=‘pcie-root’ was found instead»”. Changing to pci-root in the XML got errors about the ports, and I did not do further trial and error in the XML.
Actually I don’t know what useful information to provide in the bug report. I have no logs or whatever and don’t understand qemu deep enough to tell why qemu-ovmf would be the addressee… So I would like somebody with more understanding to open that bug report.