> cat ~slawomir/hash-ubuntu-kernel
1965034fae9a83d108554b530c3d9e9bb159b14288e19f3449e8ac008d24e226
> mokutil --import-hash `cat ~slawomir/hash-ubuntu-kernel` -P
Failed to enroll new keys
So this method probably won’t works.
It fails to set EFI variable with enroll request.
Can you access EFI boot menu? You have removable media in EFI boot manager list - can you (attempt to) boot from DVD/USB?
Hopefully not - the obviously defeats the very idea of having secure boot.
I remember Linux Foundation created own bootloader.
They verify binaries by using hashes. I cannot find sources of PreLoader (so much about “open source” …) but they must store hashes somewhere and this most likely is EFI variables as well.
Anyway you can try it: https://blog.hansenpartnership.com/linux-foundation-secure-boot-system-released/
Just use “chainloader” in GRUB CLI to load PreLoader.efi.
Hurrah!!
GRUB2 loads Preloader.efi without problem (I only copy it onto /boot/efi/EFI/opensuse) and restart my system, ran grub2 console and use chainloader!
… But it complains about missing loader.efi. Maybe I’m stupid. My family always told me - if you had to be programmer, you must learn English well. I will read page you suggest me to visit carefully, but I think I have to download usb stick image and use loader from it.
Yes, it is what it wants to run. PeLoader itself is not bootloader - it simply overrides security checks and launches loader.efi. You need to select suitable bootloader and copy it under name loader.efi in the same directory.
Can I simply copy grub2 loader from OpenSuSE or it will still validate checksums?
Yes, but I do not see the point - it is loaded by default anyway.
PeLoader itself is not bootloader - it simply overrides security checks and launches loader.efi.
I understood this sentence as preloader does disable some memory address, which decide bootloader should check control sum/hash/etc. In this case I can load any bootloader, which look at this memory address to run unsigned kernel.
In such cases I just boot from my openSUSE Live DVD (steellinux), chrooting in root partition and remaking the bootloader with yast …
I try starting Ubuntu’s kernel with linux instead of linuxefi and initrd instead of initrdefi and have message “You may load kernel first” message (That’s similar message - I’m using Polish language in OpenSuSE).
As you found, that won’t work unless secure-boot is disabled.
However, it does work with the shim from Ubuntu (acthually it is “shimx64.efi”). And it probably works with the “shim.efi” from opensuse 12.3 if you can get hold of that. But mixing different versions can be tricky.
Someone in this thread, suggested to use OpenSuSE 12.3. I thought: It was signed probably with the same key as OpenSuSE Tumbleweed, but have older grub2, so maybe there’s a way to disable signature checking (set check_signatures=no or smthg). There’s one problem: I cannot locate grub2 or another efi-capable bootloader.
That was me.
I thought: It was signed probably with the same key as OpenSuSE Tumbleweed, but have older grub2, so maybe there’s a way to disable signature checking (set check_signatures=no or smthg).
With 12.3, it checked signatures if you used “linuxefi”/“initrdefi”. But it did not check signatures if you use “linux” and “initrd”.
Starting with 13.1, the use of “linuxefi” and “initrdefi” was enforced if secure-boot is enabled.
There’s one problem: I cannot locate grub2 or another efi-capable bootloader.
If you can find the installer for 12.3, then grub is on the DVD (to boot the installer). On the other hand, the Microsoft signature on that “shim.efi” might have expired by now. So it still might not work.
Previously I burn Ubuntu Image using K3B twice and twice time K3B reports not whole image was burned. There was error, while chainloading bootx64.efi. I thought image was not wrote correctly. Today I installed brasero on my system, burn image with it. Brasero tells me image was successfully wrote. I decided to test this image. The error still occurs.
When I type
set root=(cd0)
chainloader /BOOT/EFI/BOOTX64.efi
or
set root=(cd0,apple2)
chainloader /boot/efi/bootx64.efi
Error was:
“Unable to found fs: undefined”
That means grub from OpenSuSE properly loads boot64.efi, but this part of system loading program have trouble with loading continuing. What I’m doing wrong?
As I’m remember, MS-DOS partition table allows to set current operating system partition.
Because I’m long living OpenSuSE user, I decided to found OpenSuSE 12.3. I found installation CD. There’s no efi executable on it! I found instead old Grub2 package, but decided do not install it, because evolution of software stack can be too big. I have also found OpenSuSE 12.1 Live KDE, but without efi loader too.
I’m not sure about 12.1. They may have been using “elilo” to boot EFI. However, 12.3 did have efi loaders. If you are looking at the live image, then I think there should be a directory “EFI” (or maybe “efi”) at the top level with the efi loader.
Hmm, it did have to be the 64-bit installer or live media. The 32-bit media didn’t do EFI.
Ok.
I have downloaded ISO from https://ftp5.gwdg.de/pub/opensuse/discontinued/distribution/12.3/iso/ . File is called openSUSE-12.3-KDE-Live-x86_64.iso . I ran GRUB2 from CD! There’s no way to execute linux or initrd (tab completion fill command to linuxefi and initrdefi). Maybe should I set some variable, like PATH? Maybe should I use map command (to set order of partition/drive)
Strange… I have filtered /run/media/slawomir/openSUSE 12.3 KDE Live/boot/grub2-efi/x86_64-efi/ for linux word and got
> cd /run/media/slawomir/openSUSE 12.3 KDE Live/boot/grub2-efi/x86_64-efi/
> ls *linux*
linuxefi.mod linuxefi.module linux.mod linux.module
I have started a download. Expected time is over 5 hours. That’s a slow site.
I’ll comment again when the download is complete and I can look it over.
The download completed.
I tried a UEFI boot on a KVM virtual machine. It would not boot.
I had that running as a UEFI system on this same computer (the real computer, not under KVM). But that was back several years ago (2013, which was when I purchased this computer).
My best guess is that the microsoft signature on “shim.efi” has expired by now.