Can't boot installation medium

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?

Try creating the pen drive like this:
Create a FAT32 partition.
Mount the ISO.
Copy all folders and files of the ISO to the pen drive.
Boot it.

Rufus and other “helpers” are not required and modify the install image that can make openSUSE unusable or broken.

To work the ISO need to be binary copied unmodified to the device not a partition on the device.

Did you make sure you used “DD mode” with rufus when making the installation USB?

1 Like

Hmm, I actually used ISO mode. Thanks for the tip, I’ll try dd-mode next.

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.

Hi All
Are your systems configured for UEFI boot, are you booting in UEFI mode?

No issues here, see https://forums.opensuse.org/t/16-will-not-install-in-lib-virt/185864

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.

Went through another install and all good?

Here:


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.

@letsfindaway Hi, just select UEFI not any of the listed options. It should be ovmf-x86_64-smm-ms-vars?

You can edit the xml;

<domain type="kvm">
  <name>opensuse16.0</name>
  <uuid>9e102775-23b6-4f23-b730-41769b08bb78</uuid>
  <metadata>
    <libosinfo:libosinfo xmlns:libosinfo="http://libosinfo.org/xmlns/libvirt/domain/1.0">
      <libosinfo:os id="http://opensuse.org/opensuse/16.0"/>
    </libosinfo:libosinfo>
  </metadata>
  <memory unit="KiB">16777216</memory>
  <currentMemory unit="KiB">16777216</currentMemory>
  <vcpu placement="static">8</vcpu>
  <os firmware="efi">
    <type arch="x86_64" machine="pc-q35-10.0">hvm</type>
    <firmware>
      <feature enabled="yes" name="enrolled-keys"/>
      <feature enabled="yes" name="secure-boot"/>
    </firmware>
    <loader readonly="yes" secure="yes" type="pflash" format="raw">/usr/share/qemu/ovmf-x86_64-smm-ms-code.bin</loader>
    <nvram template="/usr/share/qemu/ovmf-x86_64-smm-ms-vars.bin" templateFormat="raw" format="raw">/var/lib/libvirt/qemu/nvram/opensuse16.0_VARS.fd</nvram>
    <boot dev="hd"/>
  </os>

Thanks, but unfortunately this does not help. My XML now looks as follows:

<domain type="kvm">
  <name>opensuse16.0</name>
  <uuid>1238e093-a5cb-4ff9-b7cf-e81d9c6a3292</uuid>
  <metadata>
    <libosinfo:libosinfo xmlns:libosinfo="http://libosinfo.org/xmlns/libvirt/domain/1.0">
      <libosinfo:os id="http://opensuse.org/opensuse/16.0"/>
    </libosinfo:libosinfo>
  </metadata>
  <memory unit="KiB">8388608</memory>
  <currentMemory unit="KiB">8388608</currentMemory>
  <vcpu placement="static">4</vcpu>
  <os firmware="efi">
    <type arch="x86_64" machine="pc-q35-8.2">hvm</type>
    <firmware>
      <feature enabled="yes" name="enrolled-keys"/>
      <feature enabled="yes" name="secure-boot"/>
    </firmware>
    <loader readonly="yes" secure="yes" type="pflash" format="raw">/usr/share/qemu/ovmf-x86_64-smm-ms-code.bin</loader>
    <nvram template="/usr/share/qemu/ovmf-x86_64-smm-ms-vars.bin">/var/lib/libvirt/qemu/nvram/opensuse16.0_VARS.fd</nvram>
    <boot dev="hd"/>
  </os>

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.

@letsfindaway Yes, I’m on Tumbleweed… I would suggest a bug report against qemu-ovmf, suspect there is some backporting needed…

Ref: https://bugzilla.suse.com/show_bug.cgi?id=1240300

Try switching the chipset to i440FX and see if that makes a difference.

I’m currently trying the newest image from https://download.opensuse.org/repositories/systemsmanagement:/Agama:/Devel/images/iso/agama-installer.x86_64-16.pre.0.0-openSUSE-Build13.4.iso and yes, it boots and the installer is currently running. I will report back after the installation completed.

@letsfindaway with the chipset change?

I used the Leap-16.0-offline-installer-x86_64.install.iso image…

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.

@letsfindaway Just re-open that bug report and say it’s happening with the Agama installer…