Issue encountered booting FreeBSD STABLE and CURRENT snapshots with EFI

[Kyle Evans]

On Thu, Mar 15, 2018 at 8:46 PM, Marcelo Araujo <araujobsdport at gmail.com> wrote:
>
>
> 2018-03-16 7:07 GMT+08:00 Kyle Evans <kevans at freebsd.org>:
>>
>> On Thu, Mar 15, 2018 at 5:01 PM, Kyle Evans <kevans at freebsd.org> wrote:
>> > On Thu, Mar 15, 2018 at 4:09 PM, Peter Grehan <grehan at freebsd.org>
>> > wrote:
>> >>> I believe the problem may have been introduced with this commit: > >
>> >>> https://svnweb.freebsd.org/base/stable/?view=log&pathrev=329114
>> >>
>> >>  Any chance of being able to work out where in that list of commits in
>> >> CURRENT the loader stopped working ?
>> >>
>> >
>> > Indeed- if you could work out the exact commit in that range from head
>> > that caused it, I wouldn't think it to be a tough fix. After tonight
>> > I'm out until Sunday, but should have time Sunday or Monday to try and
>> > diagnose it further.
>>
>> Can one of you try this with boot1.efi+loader.efi built from today's
>> head stand/? I'm not sure what I'm expecting here since these are
>> among my first times trying bhyve, but this is what I'm seeing now
>> (vs. from the mentioned head snapshot where I noted similar behavior
>> as originally mentioned):
>>
>> 1.) Get to loader.efi, menu is good
>> 2.) Break into loader prompt
>> 3.) `lsdev`- pager is restricted to the line the prompt is on, so the
>> output is useless
>> 4.) `boot`
>> 5.) "Unhandled ps2 mouse command 0xe1"
>>
>> At this point, the boot looks screwed until I VNC into it- it booted
>> fine here, but the console stopped working after the kernel handoff.
>>
>> Thanks,
>>
>> Kyle Evans
>> _______________________________________________
>> freebsd-virtualization at freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
>> To unsubscribe, send any mail to
>> "freebsd-virtualization-unsubscribe at freebsd.org"
>
>
> Hi Kyle,
>
> I will do that today and report back as soon as I have something.
>

Thanks! If it's still failing, I think capturing the output of "lsdev"
and "show currdev" prior to a failed boot might be most helpful just
to make sure there's not something obviously sketchy happening.