EFI loader not working with Gigabyte's BRIX 4150

English Install/Boot/Login
1

I’m having issues installing leap15 on my new Gigabyte BRIX 4105. After selecting the correct boot device in the bios, I get a froozen screen with a non blinking _
There is no issue booting/installing Win10 nor KUbuntu.
I’ve been able to pin point the problem down to the EFI loader (I think). By extracting the opensuse iso file into a FAT32 formatted boot disk, I replace the opensuse grubx64.efi and bootx64.efi files with those from KUbuntu and then the disks loads. However, It apparently is installing a ‘bad’ efi file on the Harddisk, since after completion of installation and rebooting I again get the screen with the non blinking _.
By using the EFI command line I can boot the MokManagere.efi (no clue what that’s supposed to do), this efi file DOES work.
I’ve tried, the Full, Network, Live and even the 42.3 iso installation disk and all have the same issue: non of the efi files work, accept the MokManager.efi

Anyone has a clue what’s going wrong here?

2

I think you should file a bug report.

I’m not aware of anyone else having such problems. So it might be a peculiarity of your hardware.

3

The iso MUST be an unchanged copy to the device NOT a partition on the device.The iso is a boot ready image.

4

Hi Rickert,
Have filed a bug report meanwhile. Did find a workaround: downloaded the latest Fedora iso and installed this next to OpenSuse to create a dual boot system. This works! (so next to Win10, KUbuntu also the Fedora boot disks are working with the BRIX 4105). Now I’ve to remove the Fedora install (to reclaim the disk space), update the grub loader to load SuSe as default, but keep the Fedora efi files for the chained boot process.
Only worry I now have is that that the efi files might be updated in an automatic update, or are the efi files never updated?
The BRIX 4105 model is new (introduced Apr-2018) and most users will likely install Win10 on it, so I’ll be probably the first person having the problem.

Will report the bug also to Gigabyte, since it’s probably the combination SuSe’s efi and Gigabyte’s BIOS which is causing the problem.

5

The efi files can be updated.

Keep a copy of the ones that work, so that you can restore them if needed.

The efi files will be updated whenever there is an update to the “shim” package and whenever there is an update to “grub2-efi” or other grub2 packages.

These updates are infrequent for Leap 15.0, but quite frequent for Tumbleweed.

6

I have locked to Windows P/C UEFI settings and got round this by copying the opensuse efi file over. Over the last 18 months it has only changed once. Using Tumbleweed.

7

A few hours after my post I did some system updates to a another p/c that I have. This has a similar set-up to my opensuse system but uses KDE Neon (again with the grubx64.efi file copied over to the boot/efi/efi/boot folder and renamed bootx64.efi). Guess what the system updates amended grub files and it would not boot!

8

I am keeping a backup of “/boot/efi/EFI/opensuse”, so that I can restore the previous version of boot files – just in case. I think the last time that I had to use that was 2-3 years ago. But it’s there if I need it.

I just create a subdirectory (“tw” for Tumbleweed or “15_0” for Leap) and copy the files that match . to that subdirectory. Then if an update breaks booting, I can copy them back.

9 
I am keeping a backup of "/boot/efi/EFI/opensuse", so that I can restore  the previous version of boot files -- just in case.  I think the last  time that I had to use that was 2-3 years ago.  But it's there if I need  it.

I do the same. It is always gonna go wrong at the worst possible time!