Re: LUA loader: bhyve now doesn't?

On Sun, Aug 19, 2018 at 11:03 AM, Kyle Evans <kevans_at_freebsd.org> wrote:

> On Sun, Aug 19, 2018 at 11:58 AM, John Baldwin <jhb_at_freebsd.org> wrote:
> > On 8/19/18 5:28 PM, Kyle Evans wrote:
> >> On Sun, Aug 19, 2018 at 10:42 AM, Warner Losh <imp_at_bsdimp.com> wrote:
> >>> On Sun, Aug 19, 2018 at 9:35 AM, Larry Rosenman <ler_at_freebsd.org>
> wrote:
> >>>
> >>>> On Sun, Aug 19, 2018 at 09:33:18AM -0600, Warner Losh wrote:
> >>>>> On Sun, Aug 19, 2018 at 9:22 AM, Larry Rosenman <ler_at_freebsd.org>
> wrote:
> >>>>>
> >>>>>> With today's change to LUA as the loader, I seem to have an issue
> with
> >>>>>> bhyhve:
> >>>>>>
> >>>>>> Consoles: userboot
> >>>>>>
> >>>>>> FreeBSD/amd64 User boot, Revision 1.1
> >>>>>> (Thu Nov 16 15:04:02 CST 2017 root_at_borg.lerctr.org)
> >>>>>> Startup error in /boot/lua/loader.lua:
> >>>>>> LUA ERROR: cannot open /boot/lua/loader.lua: no such file or
> directory.
> >>>>>>
> >>>>>> /boot/kernel/kernel text=0x1063d88 data=0x12e930+0x283970
> >>>>>> syms=[0x8+0x14cf28+0x8+0x163e57]
> >>>>>> Hit [Enter] to boot immediately, or any other key for command
> prompt.
> >>>>>> Booting [/boot/kernel/kernel]...
> >>>>>>
> >>>>>> These VM's have been running for MONTHS.
> >>>>>>
> >>>>>> Ideas?
> >>>>>>
> >>>>>
> >>>>> There's no boot/lua/loader.lua.
> >>>>>
> >>>>> You can either fix that, or you can recompile with
> >>>>> LOADER_DEFAULT_INTERP=4th for the moment.
> >>>> actually on the host there is:
> >>>> borg.lerctr.org /home/ler $ ls -l /boot/lua/
> >>>> total 131
> >>>> -r--r--r--  1 root  wheel   3895 Aug 19 09:46 cli.lua
> >>>> -r--r--r--  1 root  wheel   3204 Aug 19 09:46 color.lua
> >>>> -r--r--r--  1 root  wheel  14024 Aug 19 09:46 config.lua
> >>>> -r--r--r--  1 root  wheel  10302 Aug 19 09:46 core.lua
> >>>> -r--r--r--  1 root  wheel   9986 Aug 19 09:46 drawer.lua
> >>>> -r--r--r--  1 root  wheel   3324 Aug 19 09:46 hook.lua
> >>>> -r--r--r--  1 root  wheel   2543 Aug 19 09:46 loader.lua
> >>>> -r--r--r--  1 root  wheel   2431 Aug 19 09:46 logo-beastie.lua
> >>>> -r--r--r--  1 root  wheel   2203 Aug 19 09:46 logo-beastiebw.lua
> >>>> -r--r--r--  1 root  wheel   1958 Aug 19 09:46 logo-fbsdbw.lua
> >>>> -r--r--r--  1 root  wheel   2399 Aug 19 09:46 logo-orb.lua
> >>>> -r--r--r--  1 root  wheel   2119 Aug 19 09:46 logo-orbbw.lua
> >>>> -r--r--r--  1 root  wheel  12010 Aug 19 09:46 menu.lua
> >>>> -r--r--r--  1 root  wheel   3941 Aug 19 09:46 password.lua
> >>>> -r--r--r--  1 root  wheel   2381 Aug 19 09:46 screen.lua
> >>>> borg.lerctr.org /home/ler $
> >>>>
> >>>> This is when booting the vm, and it's not on the vm's disk.
> >>>>
> >>>> So the bhyveload behavior *CHANGED*.
> >>>>
> >>>> POLA?
> >>>>
> >>>
> >>> Unlikely, but a couple of questions. Have you always used the LUA
> loader,
> >>> or is this a change with the recent default switch?
> >>>
> >>> And to be clear, you expect the host's file to be used for this, not
> the VM
> >>> filesystem?
> >>>
> >>
> >> (CC'ing jhb_at_ and tychon_at_, who might have better insight)
> >>
> >> If we can swing it, I think the best model here should have always
> >> been that userboot uses the host's scripts but the guest's
> >> loader.conf. The current model doesn't tolerate any mismatch between
> >> host and guest and looks unsustainable.
> >
> > Err, normally guests read things out of the a guest disk image (think
> most
> > VMs like VirtualBox, etc.).  userboot.so is looking in the guest's disk
> image.
> > Now, userboot isn't memory limited like the BIOS boot, so if it's
> > possible to have userboot just include both lua and forth perhaps with
> > some auto-detection based on what is in /boot/loader.rc to determine
> > which interpreter to use, that is really the best path forward.
> >
>
> Right, but userboot is clearly a special monkey... it seems that it
> would have made a lot more sense to emulate an actual BIOS boot (or
> something) and boot a real boot1/loader from a guest, but instead we
> end up with this host dependency of userboot that's invoking scripts
> from the guest -- which may or may not match.
>

It's special so that bhyve doesn't have to emulate more....


> I think including both loaders in userboot is probably a no-start
> based on the current interface.
>

Yea, it would be a challenge... Sadly, we have POLA violations either way
we jump here.

Warner