Bugzilla – Bug 1080272
Installation removes other opensuse EFI entries
Last modified: 2018-02-16 10:39:57 UTC
Yesterday I took out the SSD of my laptop and replaced it with another one to do some test of the new Tumbleweed Installation (20180205).
Installation went fine, I could boot from that disk, and play with the installed system w/o issues.
When I swapped my old disk back in again, it would not boot anymore!
It turned out that the Installation had REMOVED the old entry in the EFI boot manager setup, and replaced it with its own information, thus making the old disk unavailable.
I would have expected the installer to create a NEW entry and leave existing ones untouched, just as any other entries there (I had another one for a debian system in the list).
Even if the menu then might contain two entries with identical names - I definitely consider it preferable to have the user scratch his head which of the two entries is which (but both do work if the respective disk is connected), than making one option unusable...
Please attach full yast logs
And apart from the YaST logs, a question:
If I understood properly, the bootloader removed EFI entries for systems that were indeed not there (the disk was not longer in the system) in the moment in which the bootloader was installed. Is that correct? If so, I would label it as feature rather than bug. :-)
I'm not convinced this is a genuine bug.
It is true (as far as I know) that installing boot does remove previous "opensuse" entries from NVRAM.
However: In both of my UEFI boxes, if I remove a physical disk and replace with another, then on next boot the firmware will remove all NVRAM entries that refer to the disk that was removed. So you are wanting to do something that the firmware (at least in my systems) does not support.
The correct way to do this would be to put a boot entry in "\EFI\Boot" in the EFI partition. That's where the firmware looks if there are no NVRAM entries for that disk. And if you put "shim.efi" there but rename it to "bootx64.efi", and if you also put "fallback.efi" there, then on next boot, opensuse will attempt to add back NVRAM entries corresponding to the "boot.csv" files in directories. In my experience, opensuse will actually install the appropriate files in "\EFI\Boot" if that directory is empty.
Created attachment 759668 [details]
requested y2log archive
I don't have that system running, so it's created by mounting the default volume plus the @/var subvolume to /mnt, chroot there and run save_y2logs. Hope that is what you need.
As to your comments/questions:
Yes, the other disk, to which the EFI entry belonged, was not connected when I ran the install.
Neither was the disk with another entry pointing to some debian install. That one did not get removed. Then that would be a bug of the feature? ;^>
And no, my BIOS/Firmware of the laptop does not care about not existing disks in defined entries. It goes through the defined boot order and uses the first one that works, but doesn't remove the other ones.
And even if this would be the case - then there is not much use in doing this via the installer. As I wrote, I think it should not care about other entries, just add a new entry with an unused bootnumber, and put it at the beginning of the bootorder. For systems where the BIOS removes invalid entries the outcome is the same, but for the rest this might save some people from being unpleasantly surprised...
Yes, the newly installed system has bootx64.efi and fallback.efi installed in EFI/boot. The old one not, likely because the partition existed before and had something in it. That old system does have the opensuse/boot.csv file. But of course opensuse could not use it to create NVRAM entries, as it wasn't bootable in first place.
I've read a bit more about bootprocess etc. At least one good outcome of my problems :D
Things were partially caused by the setup of the old disk. As I wrote, it had an older debian entry, too, which had set up the EFI/boot, so my TW setup had not touched it. As I understand the re-setup using boot.csv would have been done by fallback.efi - but that did not exist, as the debian install had used grub(1)
So call it bad luck on my side. Still, it would not have happened if the installer had just created a new bootnumber. So maybe change this topic to
Feature request: Alsways create new bootnumber entries in EFI menu?
Thanks for your help!
(In reply to Peter Sütterlin from comment #5)
> So call it bad luck on my side. Still, it would not have happened if the
> installer had just created a new bootnumber. So maybe change this topic to
> Feature request: Alsways create new bootnumber entries in EFI menu?
> Thanks for your help!
It would be nice if you could create a feature request to :
Perhaps other user which are not so familiar with the booting process like you
could also trap into this problem. Thanks
just wanted to create such a request - but the login doesn't accept my login data. Is this really a different account from this one here? Why? And if I go for 'sign in' I end up at the novell site again. So they are connected? This is confusing...