[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