Bug 937067 - efi=1 does not seem to work anymore
efi=1 does not seem to work anymore
Status: RESOLVED FIXED
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Installation
Current
Other Other
: P5 - None : Major (vote)
: ---
Assigned To: YaST Team
Jiri Srain
https://trello.com/c/AhwBBa4x
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2015-07-05 10:49 UTC by Thorsten Kukuk
Modified: 2021-12-17 10:42 UTC (History)
4 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Thorsten Kukuk 2015-07-05 10:49:57 UTC
In the past, you could add efi=1 as argument for the installer, and your system was setup for EFI boot, even if the detection fails. This works only partly with Tumbleweed 20150630: the bootloader still installs and configures grub2-x86_64-efi, but the storage proposal does not create a vfat /boot/EFI partition anymore. This works with SLES12, haven't tested openSUSE 13.2.
Comment 1 Arvin Schnell 2015-07-06 09:24:20 UTC
For me passing "efi=1" does not work on SLE12 (and it's also no surprise
since the parameter to force EFI in libstorage is "LIBSTORAGE_EFI=yes").

Maybe it worked in SLE11 with "efi=1" where libstorage used /etc/install.inf
or /etc/sysconfig/bootloader to detect EFI. But in SLE12 it always checks
for /sys/firmware/efi/vars.

Please provide YaST logs from SLE12 installation where this is supposed
to work.
Comment 2 Lukas Ocilka 2015-08-03 09:32:11 UTC
Thorsten, any news about logs?
Comment 3 Thorsten Kukuk 2015-08-17 08:00:33 UTC
(In reply to Lukas Ocilka from comment #2)
> Thorsten, any news about logs?

Sorry, but I was on FTO and ill...
I tried to get the old setup together again to reproduce, but wasn't able to get the same hardware and didn't found a similar machine.

Nevertheless, I think we should use one parameter during installation, not two. Explaining the customer to use "efi=1 LIBSTORAGE_EFI=yes" during installation isn't the best idea.
Comment 4 Arvin Schnell 2015-08-24 07:38:31 UTC
I think we should spend the time instead of fixing auto-detection of EFI.
I'm sure you made bug-reports for that.
Comment 5 Thorsten Kukuk 2015-08-24 07:45:06 UTC
If we have options to override, they should be usefull and consistent. Else we could remove that code, too.

But the real problem is: on 32bit/64bit mix systems, EFI autodetection isn't reliable possible, so we need this options.
Comment 6 Arvin Schnell 2015-09-01 13:00:30 UTC
https://github.com/openSUSE/libstorage/pull/145
Comment 7 Arvin Schnell 2015-09-01 13:23:29 UTC
With libstorage 2.25.30 the user can now override the EFI detection of
libstorage with efi=0/1.

But a test on Tumbleweed shows that the bootloader does not work: In
YaST I get a red error message: "Unsupported combination of hardware
platform x86_64 and bootloader grub2-efi.

Josef, please comment on the bootloader side.
Comment 8 Neil Rickert 2015-09-01 13:52:15 UTC
I did an install in August (using 20150802), with "efi=1".  This was at a time when the installer on a USB did not boot to UEFI.

I used expert partitioning, so I assigned an EFI partition myself.  So I can't comment on that part.

However, grub2-efi was not properly installed.  In particular, the subdirectory "/boot/grub2/x86_64-efi" did not exist.

Incidentally, I did blog about this install, at:
https://nwrickert2.wordpress.com/2015/08/07/my-tumbleweed-install-for-august/

My hope had been that grub2-efi would be installed, except that the NVRAM entry would not be created (due to not booting into UEFI mode for the install).  I would then only have needed to run "efibootmgr" manually to create the boot entry.  Unfortunately, not enough of booting was installed for this.  Instead, I had to boot to rescue mode and run "grub2-install", "shim-install" and "grub2-mkconfig" from a chroot() environment.
Comment 9 Josef Reidinger 2015-09-04 12:52:10 UTC
yes, bootloader for efi try to check efivars. See https://github.com/yast/yast-bootloader/blob/master/src/modules/BootSupportCheck.rb#L222

In general if we want to change detection of efi, I really suggest to place it in one place e.g. Arch module, so we can easily share code as it is maybe used from other places.

Jiri what do you think about it? in general I propose to add it to scrum, as it is not trivial to check all possible places which use efi detection.
Comment 10 Jiri Srain 2015-09-07 10:28:19 UTC
I agree to add it to the SCRUM board. Arch module looks like a good place for keeping this information. Ayway, e.g. bootloader will still need to check the real system (since NVRAM is not accessible if booted legacy).
Comment 12 Steffen Winterfeldt 2021-12-17 10:42:59 UTC
unification (comment 9) finally implemented