LUA loader: bhyve now doesn't?

Kyle Evans kevans at freebsd.org
Sun Aug 19 17:03:24 UTC 2018


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@ and tychon@, 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.

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


More information about the freebsd-current mailing list