From owner-freebsd-virtualization@freebsd.org Fri Mar 23 13:06:03 2018 Return-Path: Delivered-To: freebsd-virtualization@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 E5B5FF6AC44 for ; Fri, 23 Mar 2018 13:06:02 +0000 (UTC) (envelope-from byond.lenox@gmail.com) Received: from mail-lf0-f44.google.com (mail-lf0-f44.google.com [209.85.215.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5C7BA73127; Fri, 23 Mar 2018 13:06:02 +0000 (UTC) (envelope-from byond.lenox@gmail.com) Received: by mail-lf0-f44.google.com with SMTP id g203-v6so18164682lfg.11; Fri, 23 Mar 2018 06:06:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=peKdfDljdbsYupwY+o9qGc9rec8oXLIjiviTPJDMQAs=; b=Y2CPe5/cS5qhGV+cG25OCxd0Sc+sfWRaw5I0OydVG0WIo83Bi0U9/ZI1eK4SGtWnos jkdc6VzCOxyWWywBO6ALgvVvcZIuO1XDKxcPOJwGfjSeAasp+wdHq8vxqXssgHWaSTcU QSedW1/Q98MjI6bdAO/Nusxifvt3Id8qNAAF8HnTyA4ZyOx/P/aHwCw6+RgzghCYIAZw 7AAjbRSEvUokXMh8TvYfr1TqhIYjcKRrMT1uyjS1+MOHQ8Uuq1kD4TEVaS03DeMK6+RL LXQ5d6XqyG2gU2lJhhbhv+Mv/xgo20OnPUXZs3JtKW84rqyG3tXJqtuVgFW7ZJ1ogCT8 dZ4Q== X-Gm-Message-State: AElRT7Eo6QcpK8stiNwdNxS7/Oxd+SgjTT5Sd3kXHIgYCV8DH8wb4Ijz hwkRKZqxS/DGeBnR/WnIgwjo8fUGRnA= X-Google-Smtp-Source: AG47ELs0x5ndZNANS6+prU1YIgXmxCQkiX/v6o/NF0E4RoQO/4eJ2WryZF5M3CIChxeKTbxV8Ow8ug== X-Received: by 10.46.134.205 with SMTP id n13mr19071335ljj.17.1521810354548; Fri, 23 Mar 2018 06:05:54 -0700 (PDT) Received: from mail-lf0-f47.google.com (mail-lf0-f47.google.com. [209.85.215.47]) by smtp.gmail.com with ESMTPSA id d2sm1859125lja.43.2018.03.23.06.05.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 23 Mar 2018 06:05:54 -0700 (PDT) Received: by mail-lf0-f47.google.com with SMTP id t132-v6so18202118lfe.2; Fri, 23 Mar 2018 06:05:54 -0700 (PDT) X-Received: by 2002:a19:114f:: with SMTP id g76-v6mr14928374lfi.108.1521810354088; Fri, 23 Mar 2018 06:05:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.129.90 with HTTP; Fri, 23 Mar 2018 06:05:33 -0700 (PDT) In-Reply-To: References: From: Kyle Evans Date: Fri, 23 Mar 2018 08:05:33 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Issue encountered booting FreeBSD STABLE and CURRENT snapshots with EFI To: Joe Maloney Cc: "araujo@freebsd.org" , "freebsd-virtualization@freebsd.org" , Warner Losh Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-virtualization@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Discussion of various virtualization techniques FreeBSD supports." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2018 13:06:03 -0000 On Fri, Mar 23, 2018 at 3:56 AM, Joe Maloney wrote: > We narrowed the issue down to how vm-bhyve attaches a null.iso when starting > the VM. > What exactly are the contents of this null.iso? It sounds like we're just ultimately choosing the wrong partition to boot with the null.iso attached. I'd be interested to see if a loader.efi built with D13784 [1] applied resolves this both replacing /boot/loader.efi initially then while installed on the ESP. Do note that I'm pretty sure we still had some small outstanding issues with D13784's loader.efi being installed as /boot/loader.efi (with console handling), so it may not be a good long-term solution, but this should hopefully land in the not-so-distant future. [1] https://reviews.freebsd.org/D13784 > For now a hack like so to vm-bhyve can get around the issue: > > https://github.com/araujobsd/vm-bhyve/commit/29db2d6c6ec4a29578dc111903107f25a78cdf82 > > This may simply be an issue with vm-bhyve attaching an invalid iso image to > the VM, and I would conclude it is odd that it does so. Or there may still > be an issue that affects even the latest 03-22-18 snapshots for example if > other media is present when booting with bhyve, or natively. I would need > to do some more testing at a later date to confirm but just wanted to pass > along what was discovered to be the root cause thus far. > > On Friday, March 16, 2018, Marcelo Araujo wrote: >> >> 2018-03-16 9:55 GMT+08:00 Kyle Evans : >> >> > On Thu, Mar 15, 2018 at 8:46 PM, Marcelo Araujo >> > >> > wrote: >> > > >> > > >> > > 2018-03-16 7:07 GMT+08:00 Kyle Evans : >> > >> >> > >> On Thu, Mar 15, 2018 at 5:01 PM, Kyle Evans >> > >> wrote: >> > >> > On Thu, Mar 15, 2018 at 4:09 PM, Peter Grehan >> > >> > wrote: >> > >> >>> I believe the problem may have been introduced with this commit: >> > >> >>> > > >> > >> >>> https://svnweb.freebsd.org/base/stable/?view=log&pathrev=329114 >> > >> >> >> > >> >> Any chance of being able to work out where in that list of >> > >> >> commits >> > in >> > >> >> CURRENT the loader stopped working ? >> > >> >> >> > >> > >> > >> > Indeed- if you could work out the exact commit in that range from >> > >> > head >> > >> > that caused it, I wouldn't think it to be a tough fix. After >> > >> > tonight >> > >> > I'm out until Sunday, but should have time Sunday or Monday to try >> > >> > and >> > >> > diagnose it further. >> > >> >> > >> Can one of you try this with boot1.efi+loader.efi built from today's >> > >> head stand/? I'm not sure what I'm expecting here since these are >> > >> among my first times trying bhyve, but this is what I'm seeing now >> > >> (vs. from the mentioned head snapshot where I noted similar behavior >> > >> as originally mentioned): >> > >> >> > >> 1.) Get to loader.efi, menu is good >> > >> 2.) Break into loader prompt >> > >> 3.) `lsdev`- pager is restricted to the line the prompt is on, so the >> > >> output is useless >> > >> 4.) `boot` >> > >> 5.) "Unhandled ps2 mouse command 0xe1" >> > >> >> > >> At this point, the boot looks screwed until I VNC into it- it booted >> > >> fine here, but the console stopped working after the kernel handoff. >> > >> >> > >> 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-unsubscribe@freebsd.org" >> > > >> > > >> > > Hi Kyle, >> > > >> > > I will do that today and report back as soon as I have something. >> > > >> > >> > Thanks! If it's still failing, I think capturing the output of "lsdev" >> > and "show currdev" prior to a failed boot might be most helpful just >> > to make sure there's not something obviously sketchy happening. >> > >> >> Hi, >> >> I think we had two bad snapshots! >> >> I just finished the tests with HEAD and 11-STABLE latest snapshots: >> 1) HEAD: FreeBSD-12.0-CURRENT-amd64-20180315-r331001-disc1.iso >> 2) Stable: FreeBSD-11.1-STABLE-amd64-20180315-r330998-bootonly.iso >> >> I have installed it using ZFS and tested using AHCI and virtio-blk. >> >> So everything worked fine. >> Seems those broken snapshots have missed some commits related with EFI. >> >> >> Thank you all. >> -- >> >> -- >> Marcelo Araujo (__)araujo@FreeBSD.org >> \\\'',)http://www.FreeBSD.org \/ \ ^ >> Power To Server. .\. /_) >> _______________________________________________ >> freebsd-virtualization@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization >> To unsubscribe, send any mail to >> "freebsd-virtualization-unsubscribe@freebsd.org" > > > > -- > Joe Maloney > QA Manager / iXsystems > Enterprise Storage & Servers Driven By Open Source >