action #36034


action #30649: [tools][openqa] Improve performance by using migrations and external snapshots

action #32968: [kernel][tools] Refactor QEMU backend - Create QEMU process manager and save configuration state

[kernel][tools] QEMU Refactor - Regression, first Grub boot fails after usb-uefi installation

Added by rpalethorpe about 6 years ago. Updated almost 6 years ago.

Feature requests
Target version:
Start date:
Due date:
% Done:


Estimated time:


It appears that some files are missing from there expected location, possibly the disk configuration is not stable. Pinning the drive serial numbers may help.

Actions #1

Updated by rpalethorpe about 6 years ago

  • Status changed from New to In Progress

The missing files exist on the USB stick at the expected location, but they are installed to a different location on the system drive. My guess is that it is booting from the USB Sticks EFI partition, but the USB stick is not mounted. Interestingly, if I remove 'bootindex=0' from the USB drive then it displays the same behaviour on the first boot at the beginning of the installation (the grub menu is displayed, but the theme files are missing).

If I remove the USB storage device after installation, I am dumped into the EFI shell. This should not happen, the installation should write to the UEFI vars that it should now boot from the system drive. It seems that if I manually run the EFI boot program from the EFI shell then it boots OK and if the system is restarted then it goes directly to GRUB instead of the shell (this probably needs confirming because I also temporarily set the bootindex which may have effected the vars). I guess this means the vars are updated by SUSE's efi boot program.

The behaviour seems to be the same on both SLE and Tumbleweed, but I haven't thoroughly tested it.

I am not sure what I have changed to cause this new behaviour. It happened before I introduced the new pflash vars drive which would otherwise be the obvious thing to blame. The QEMU command line is different, because I am using a combination of '-blockdev' and '-device' parameters instead of '-drive' and '-device', but they should be functionally equivalent.

This is probably irrelevant, but for some reason the SUT thinks there is a floppy disk drive, even though I removed the floppy controller.

I think there is a product bug, but this could also be worked around with a new needle and softfail if necessary.

Actions #2

Updated by rpalethorpe about 6 years ago

  • Status changed from In Progress to Workable


Actions #3

Updated by rpalethorpe almost 6 years ago

  • Status changed from Workable to Rejected

It appears that it was a product bug and is now fix, if not then this can be reopened.


Also available in: Atom PDF