From owner-freebsd-current@freebsd.org Sun Aug 19 17:10:29 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 DE5CE1070D7F for ; Sun, 19 Aug 2018 17:10:28 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (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)) by mx1.freebsd.org (Postfix) with ESMTPS id 70F29809D8 for ; Sun, 19 Aug 2018 17:10:28 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x233.google.com with SMTP id 139-v6so17668363itf.0 for ; Sun, 19 Aug 2018 10:10:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=EKHf4Pf06C4+5PaarOgohgt5uMoKFhzTVQID7mPReIQ=; b=MkQfxQXe0J0C/Cz8xQJaIRXl6oI6FslUSFAjhGMJxT6v9CpZCnM3Zu2Bnp47LH9gq9 zDa1XP7CyR9euJB3Evp4LVqIVEU+Sh3tCX1/60heCVGf4v1MWH+FTEdfb/BiS/w7fk0Z xHoOL2KhKsnzJ+9ucAhvg3ffJGm9yrVNLpacsMWZceiglCALxA9FzAWaV2sDVsMl/g7D hdkeokUUd4t2n/B9YebmmxZ6Q51LTHnVUKn9YRyFdDEPl8rTIi2DRRkyz+aK10XMX0LJ ujQ+PW17Jr6ZjnIKMWFzJQxRPxC8uUhwxLZldZ890VOYSFyTiWJWIBlGaj1IM1yr7uJu xUXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=EKHf4Pf06C4+5PaarOgohgt5uMoKFhzTVQID7mPReIQ=; b=rWigg9xGM1ZnT+YZ6jbs61+dFo0/9l0h1qJvWBTrYNmxVLLLsqubUrChAFwDPFFuf0 cA+NvnTo0UgOnd5NLs43tBrxjOCszt4lbZSHwlhAqAbxKuPjhXndwQCRh4IxAjgU6cbw iwLXUSBRy/tkFEpTRpuTFxb6wMs49P/VVcvFCUhf2eELvTcbZyT59/BmCinUX0he3979 DtLHDTLghUf94DQhk2Sn+iSNw/A5CMMMKPSCSvmbYZJu3o+gl0Ng8kzadihZbV0ULe89 tNQLz9HFPkpPyY93CId0zHIS3EXsFZ225YjGBW8KBqCXcZZDsPXeszN7ZT1GUocwFz/X 8RXA== X-Gm-Message-State: AOUpUlEqIiTOfbqujWK4u9acdOlp15D8Cwrt9xs1qSs00sHyJzdgGZVY kWvYoDI9wfhEkfskh8wPvqt/s5yFtx7oMn5J1BgKYw== X-Google-Smtp-Source: AA+uWPwovvzI9R1/6EJWCIVqceuKtuqXfDCv6YPojA8wLF1b4K/jd14aDLLQ+lFrEExGdTL+BOmvyXbsZdmTfXAtC0o= X-Received: by 2002:a24:9197:: with SMTP id i145-v6mr9964845ite.39.1534698627437; Sun, 19 Aug 2018 10:10:27 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 2002:a4f:2806:0:0:0:0:0 with HTTP; Sun, 19 Aug 2018 10:10:26 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: References: <20180819152253.bbcrefdvynl7y5ka@ler-imac.local> <20180819153526.7ruovrpmdsimkmfj@ler-imac.local> <167d1cb1-7232-52bb-9a73-6f109c437a63@FreeBSD.org> From: Warner Losh Date: Sun, 19 Aug 2018 11:10:26 -0600 X-Google-Sender-Auth: RtvncAG4LzOpo0jisx4S27AqHkA Message-ID: Subject: Re: LUA loader: bhyve now doesn't? To: Kyle Evans Cc: John Baldwin , FreeBSD Current , Tycho Nightingale Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 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:10:29 -0000 On Sun, Aug 19, 2018 at 11:03 AM, Kyle Evans wrote: > 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. > 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