I can confirm the new firmware does fix the issue for us. Thanks for the quick resolution. It at least allowed me to script a proper workaround for our automated tests. It turns out my previous vm-bhyve workaround was a bad idea, and broke installs. I would assume vm-bhyve copies the iso to null.iso but I haven't had time to look further so I just reverted that patch, and applied the new firmware instead. Anyways thanks again. Joe Maloney QA Manager / iXsystems Enterprise Storage & Servers Driven By Open Source
On Sat, Mar 24, 2018 at 10:26 AM, Kyle Evans <kev...@freebsd.org> wrote: > On Sat, Mar 24, 2018 at 12:59 AM, Peter Grehan <gre...@freebsd.org> wrote: >> Hi Kyle, >> >>> FYI- I've created PR #2 [1] against the freebsd/uefi-edk2 repository >>> and have confirmed that this fixes the broken-looking firmware along >>> with the booting problem experienced in this thread. >>> >>> [1] https://github.com/freebsd/uefi-edk2/pull/2 >> >> >> Thanks - merged. I've asked Fabian to update the UEFI ports. >> > > Awesome, thanks! =) > > It didn't seem right to hack around the hack around that was > implemented for our formerly bad behavior, but we can look at it again > if we run into further problems with the way we do this. I don't think > our devpath usage is unreasonable, though- we don't expect these > pointers to live forever, just long enough to locate all of the > partitions on it. > > Thanks, > > Kyle Evans > _______________________________________________ > freebsd-virtualization@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization > To unsubscribe, send any mail to > "freebsd-virtualization-unsubscr...@freebsd.org" _______________________________________________ freebsd-virtualization@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to "freebsd-virtualization-unsubscr...@freebsd.org"
