[Bug 192184] [uefi] fresh install of 2014-07-14 11.0-CURRENT amd64 snapshot doesn't boot

bugzilla-noreply at freebsd.org bugzilla-noreply at freebsd.org
Thu Oct 9 20:52:59 UTC 2014


https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192184

Pablo Olmos de Aguilera C. <bugs at odac.co> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugs at odac.co

--- Comment #14 from Pablo Olmos de Aguilera C. <bugs at odac.co> ---
>> An older FreeBSD boot .img had been dd'd to another disk partition.
>> It turns out that UEFI code will pick up the first available image
>> it recognises and boots from that, and not the loader.efi and
>> loader.conf etc in the same EFI location at boot1.efi or similar.
>> This would be worth addressing.

> Ahh, yes.  Sorry this tripped you up.
>
> boot1.efi finds the first available UFS filesystem and loads loader.efi from 
> here.  You can skip boot1.efi altogether if you like, and just but loader.efi
> and the .4th and config files in your EFI system partition, but you'll then 
> need to explicitly set currdev to load the kernel.

I'm finding a similar issue, but loading boot1.efi just get me:

    >> FreeBSD EFI boot block
       Loader path: /boot/loader.efi
    panic: No bootable partition found

I guess that's because my system doesn't have any UFS partition, because I have
a freebsd-boot partition, and my root is on zfs. I tried to load.efi, but it
says the kernel is wrong and drop me into a loader console that works very
weird (characters get added, if I write "show", sometimes say "sh" not found,
or inserts random characters "shkokw". I tried to copy loader.4th over there,
but still nothing happens... even worse, it seems that after adding .4th not
even the `set` command is being recognized.

-- 
You are receiving this mail because:
You are the assignee for the bug.


More information about the freebsd-bugs mailing list