Bugzilla – Bug 1216634
[HPS Bug] Dolomite did not create a UEFI boot menu entry for itself
Last modified: 2024-06-11 06:39:32 UTC
Created attachment 870479 [details] The attached information is collected from the booted sle-micro disk which is enumerated as /dev/sda. Shown also is information about /dev/sdb which has Dolomite milestone 5 installed. Description of problem: I installed Dolomite milestone 5 on a disk I had wiped of previous content. The SUT already had a disk with Sle-Micro 5.5 installed on it, which was the first UEFI boot entry. After installing from the raw image, I booted Dolomite by selecting the physical disk on which I had installed from the UEFI boot menu, and it booted as expected. However there was no new UEFI boot entry created, so the first time Dolomite asked me to reboot after I had run a transactional-update, I booted back into Sle-Micro which was still the first UEFI boot menu entry. Version-Release number of selected component (if applicable): Dolomite milestone 5.0 How reproducible: One of one installs of Dolomite milestone 5 Steps to Reproduce: 1. Install Dolomite raw image 2. Boot by choice from boot menu 3. Expect but do not get a new UEFI boot menu entry for Dolomite Actual results: A reboot from Dolomite goes back to the previous UEFI boot menu first choice Expected results: Dolomite should have created a boot menu entry for itself Additional info: I reported essentially the same problem against sle-micro in bug 1203465. I acknowledge that was resolved as WONTFIX so I won't be surprised if this gets the same treatment. It still seems like a bug to me.
This might be an intended feature, the raw image would be dd to a disk and therefore would be entitled to take control of the default path, /EFI/BOOT/BOOTX64.EFI. This would not require any boot entry as the only thing needed to boot is to choose the disk and it will boot. This might be a preferred way to cloud deployment given the frequent migration to other instances may use a different firmware instance thus all boot entry lost. Anyway let's check with Jiri given this likely to be a feature.
Exactly as Michael wrote; The raw disk image (equally the self-install one) are not expected to modify the uEFI menu. When you (user who deployed) booted it for the first time, one can assume that you already did needed arrangements to boot the image. Creating an uEFI entry can be matter of one command: transactional-update bootloaer which would create the uEFI entry or do any other arrangements on other boot architectures, if needed. Running it automatically on first boot is more like a hack (and in fact enforces that, which may not be wanted if one has already created the entry to boot the image). @Randy: Would documenting that be an option?
Sorry for the delay, US holiday last week etc Yes documenting would work. And/or a brief message from the installer suggesting if you want an explicit boot entry to use transactional-update bootloader. Either gives information to which I can refer if an internal HPE tester encounters a similar issue.
I neglected to clear needinfo when I wrote comment 3.
Any further update for the bug? Thank you.
I think this was more appropriate to re-target to SL-Micro. I checked SL-Micro 6 and it still doesn't create a UEFI boot entry, but we've discussed previously that was going to be documented.
It is reflected in the documentation of Micro 6.0: https://documentation.suse.com/sle-micro/6.0/html/Micro-deployment-selfinstall-images/index.html#deployment-prebuilt-images-efiboot-record Closing this bug as FIXED. I have additionally suggested some improvement to the kiwi developers, no ETA about that.