From owner-freebsd-current@freebsd.org Sun Aug 19 17:03:24 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 58FDC10704A5 for ; Sun, 19 Aug 2018 17:03:24 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0B80980157; Sun, 19 Aug 2018 17:03:24 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-lj1-f178.google.com (mail-lj1-f178.google.com [209.85.208.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id 9C9C41A743; Sun, 19 Aug 2018 17:03:23 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-lj1-f178.google.com with SMTP id s12-v6so9825103ljj.0; Sun, 19 Aug 2018 10:03:23 -0700 (PDT) X-Gm-Message-State: AOUpUlGhS4rjXuPzyIOqD35JiBxoEsb7QJXL/n1TDFI/Z/4i2ALVVqEc J9mTCTi2+oolAUswGmTxV53jyqdPNID5K35Q5Po= X-Google-Smtp-Source: AA+uWPwtgBbAP6llxWR9iR+lmCq10igwkL+xy9Vzywq5Uc+M/QVkduOki6TvSXVbkduHIvyHG2cufQT5h52bgIpk8BE= X-Received: by 2002:a2e:2b0e:: with SMTP id q14-v6mr28277326lje.147.1534698202168; Sun, 19 Aug 2018 10:03:22 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a2e:5742:0:0:0:0:0 with HTTP; Sun, 19 Aug 2018 10:03:01 -0700 (PDT) In-Reply-To: <167d1cb1-7232-52bb-9a73-6f109c437a63@FreeBSD.org> References: <20180819152253.bbcrefdvynl7y5ka@ler-imac.local> <20180819153526.7ruovrpmdsimkmfj@ler-imac.local> <167d1cb1-7232-52bb-9a73-6f109c437a63@FreeBSD.org> From: Kyle Evans Date: Sun, 19 Aug 2018 12:03:01 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: LUA loader: bhyve now doesn't? To: John Baldwin Cc: Warner Losh , FreeBSD Current , tychon@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Aug 2018 17:03:24 -0000 On Sun, Aug 19, 2018 at 11:58 AM, John Baldwin wrote: > On 8/19/18 5:28 PM, Kyle Evans wrote: >> On Sun, Aug 19, 2018 at 10:42 AM, Warner Losh wrote: >>> On Sun, Aug 19, 2018 at 9:35 AM, Larry Rosenman 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 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@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.