Issue encountered booting FreeBSD STABLE and CURRENT snapshots with EFI

Fri Mar 23 14:58:33 UTC 2018

> On Fri, Mar 23, 2018 at 3:56 AM, Joe Maloney <jmaloney at ixsystems.com> wrote:
> > We narrowed the issue down to how vm-bhyve attaches a null.iso when starting
> > the VM.
> >
> 
> What exactly are the contents of this null.iso? It sounds like we're

touch "null.iso"
-rw-r--r--  1 root  wheel  0 Dec  3 22:55 /home/vmbhyve/.config/null.iso

It is litterly a 0 byte file.   This is just there to appease windows
installer that you have a cd drive.

You can test with bhyve yourself this problem by adding:
	-s 3:0,ahci-cd,${vm_dir}/.config/null.iso
to your bhyve command.

> just ultimately choosing the wrong partition to boot with the null.iso
> attached. I'd be interested to see if a loader.efi built with D13784
> [1] applied resolves this both replacing /boot/loader.efi initially
> then while installed on the ESP.

I suspect it is new code unable to deal with a 0 byte device.

There are some other test cases to run, like MBR's that have
valid boot code signature but corrupt Partition tables, like especially
they all 0 one, I have seen many bioses that attempt a divide
by 0 when faced with this table, aggrivated if it is not really
all 0, but if the active bit is set in a 0 valued slice.

Robust code should also handle MBR entries that have END < START,
and other nasties.  Never make any assmption about the validity
of the data in a MBR, even if it has a valid 0x55aa signature,
as the partition table can easily be corrupted, some times
intentionally.

These can be hard cases to test for as many tools do not allow you
to intentionally set bad values.

> Do note that I'm pretty sure we still had some small outstanding
> issues with D13784's loader.efi being installed as /boot/loader.efi
> (with console handling), so it may not be a good long-term solution,
> but this should hopefully land in the not-so-distant future.
> 
> [1] https://reviews.freebsd.org/D13784
> 
> > For now a hack like so to vm-bhyve can get around the issue:
> >
> > https://github.com/araujobsd/vm-bhyve/commit/29db2d6c6ec4a29578dc111903107f25a78cdf82
> >
> > This may simply be an issue with vm-bhyve attaching an invalid iso image to
> > the VM, and I would conclude it is odd that it does so.  Or there may still
> > be an issue that affects even the latest 03-22-18 snapshots for example if
> > other media is present when booting with bhyve, or natively.  I would need
> > to do some more testing at a later date to confirm but just wanted to pass
> > along what was discovered to be the root cause thus far.
> >
> > On Friday, March 16, 2018, Marcelo Araujo <araujobsdport at gmail.com> wrote:
> >>
> >> 2018-03-16 9:55 GMT+08:00 Kyle Evans <kevans at freebsd.org>:
> >>
> >> > 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.
> >> >
> >>
> >> Hi,
> >>
> >> I think we had two bad snapshots!
> >>
> >> I just finished the tests with HEAD and 11-STABLE latest snapshots:
> >> 1) HEAD: FreeBSD-12.0-CURRENT-amd64-20180315-r331001-disc1.iso
> >> 2) Stable: FreeBSD-11.1-STABLE-amd64-20180315-r330998-bootonly.iso
> >>
> >> I have installed it using ZFS and tested using AHCI and virtio-blk.
> >>
> >> So everything worked fine.
> >> Seems those broken snapshots have missed some commits related with EFI.
> >>
> >>
> >> Thank you all.
> >> --
> >>
> >> --
> >> Marcelo Araujo            (__)araujo at FreeBSD.org
> >> \\\'',)http://www.FreeBSD.org <http://www.freebsd.org/>   \/  \ ^
> >> Power To Server.         .\. /_)
> >> _______________________________________________
> >> 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"
> >
> >
> >
> > --
> > Joe Maloney
> > QA Manager / iXsystems
> > Enterprise Storage & Servers Driven By Open Source
> >
> _______________________________________________
> 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"
> 

-- 
Rod Grimes                                                 rgrimes at freebsd.org