From owner-freebsd-current@freebsd.org Wed Mar 28 19:25:37 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 EC859F70E5E for ; Wed, 28 Mar 2018 19:25:36 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from mail.metricspace.net (mail.metricspace.net [IPv6:2001:470:1f11:617::107]) by mx1.freebsd.org (Postfix) with ESMTP id 89A757EDE8; Wed, 28 Mar 2018 19:25:36 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from [10.82.237.131] (mobile-107-107-61-156.mycingular.net [107.107.61.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id E3F22756B; Wed, 28 Mar 2018 19:25:29 +0000 (UTC) Date: Wed, 28 Mar 2018 15:25:27 -0400 User-Agent: K-9 Mail for Android In-Reply-To: References: <0e75a2ba-9a59-8301-a678-68a822025bd6@metricspace.net> <9df63df2-9d61-4106-f360-347411869b41@metricspace.net> MIME-Version: 1.0 Subject: Re: GELI with UEFI supporting Boot Environments goes to HEAD when? To: Warner Losh ,Tommi Pernila CC: "[ScaleEngine] Allan Jude" , freebsd-current , imp@freebsd.org From: Eric McCorkle Message-ID: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 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: Wed, 28 Mar 2018 19:25:37 -0000 I'll do another rebase from head just to be sure=20 On March 28, 2018 3:23:23 PM EDT, Warner Losh wrote: >It's on my list for nexr, finally=2E I have an alternate patch for >loader=2Eefi >from ESP, but i don't think it will affect the GELI stuff=2E I have some >time >slotted for integration issues though=2E > >I am quite mindful of the freeze dates=2E=2E=2E=2E I have some uefi boot >loader >protocol changes that I need to get in=2E > >Warner > >On Feb 21, 2018 11:18 PM, "Tommi Pernila" wrot= e: > >> Awesome, thanks for the update and the work that you have done! >> >> Now we just need some more reviewers eyes on the code :) >> >> Br, >> >> Tommi >> >> On Thu, 22 Feb 2018 at 2=2E03, Eric McCorkle >wrote: >> >>> FYI, I just IFC'ed everything, and the current patches are still >fine=2E >>> >>> Also, the full GELI + standalone loader has been deployed on one of >my >>> laptops for some time now=2E >>> >>> On 02/21/2018 18:15, Eric McCorkle wrote: >>> > The GELI work could be merged at this point, though it won't be >usable >>> > without an additional patch to enable loader-only operation=2E The >>> > patches are currently up for review: >>> > >>> > This is the order in which they'd need to be merged: >>> > >>> > >>> > https://reviews=2Efreebsd=2Eorg/D12732 >>> > >>> > This one changes the efipart device=2E Toomas Soome identified some >>> > problems, which I have addressed=2E He has not re-reviewed it, >however=2E >>> > >>> > >>> > https://reviews=2Efreebsd=2Eorg/D12692 >>> > >>> > This adds some crypto code needed for GELI=2E It simply adds new >code, >>> > and doesn't conflict with anything=2E >>> > >>> > >>> > https://reviews=2Efreebsd=2Eorg/D12698 >>> > >>> > This adds the EFI KMS interface code, and has the EFI loader pass >keys >>> > into the keybuf interface=2E >>> > >>> > >>> > I can't post the main GELI driver until those get merged, as it >depends >>> > on them=2E It can be found on the geli branch on my github freebsd >>> > repository, however=2E >>> > >>> > >>> > Additionally, you need this patch, which allows loader=2Eefi to >function >>> > when installed directly to the ESP: >>> > >>> > https://reviews=2Efreebsd=2Eorg/D13497 >>> > >>> > On 02/20/2018 22:56, Tommi Pernila wrote: >>> >> Hi Eric, >>> >> >>> >> could you provide a brief update how the work is going? >>> >> >>> >> >>> >> Br, >>> >> >>> >> Tommi >>> >> >>> >> >>> >> On Nov 16, 2017 04:29, "Eric McCorkle" >> >> > wrote: >>> >> >>> >> Right, so basically, the remaining GELI patches are against >>> loader, and >>> >> most of them can go in independently of the work on removing >boot1=2E >>> >> There's a unanimous consensus on getting rid of boot1 which >>> includes its >>> >> original author, so that's going to happen=2E >>> >> >>> >> >>> >> For GELI, we have the following (not necessarily in order): >>> >> >>> >> a) Adding the KMS interfaces, pseudo-device, and kernel >keybuf >>> >> interactions >>> >> b) Modifications to the efipart driver >>> >> c) boot crypto >>> >> d) GELI partition types (not strictly necessary) >>> >> >>> >> Then there's the GELI driver itself=2E (a) and (c) are good to >>> land, (b) >>> >> needs some more work after Toomas Soome pointed out a >legitimate >>> >> problem, and (d) actually needs a good bit more code (but >again, >>> it's >>> >> more cosmetic)=2E Additionally, the GELI driver will need >further >>> mods to >>> >> efipart to be written (nothing too big)=2E But we could go >ahead >>> with (a) >>> >> and (c), as they've already been proven to work=2E >>> >> >>> >> I'd wanted to have this stuff shaped up sooner, but I'm >>> preoccupied with >>> >> the 7th RISC-V workshop at the end of the month=2E >>> >> >>> >> Once this stuff is all in, loader should handle any GELI >volumes it >>> >> finds, and it should Just Work once boot1 is gone=2E >>> >> >>> >> >>> > _______________________________________________ >>> > freebsd-current@freebsd=2Eorg mailing list >>> > https://lists=2Efreebsd=2Eorg/mailman/listinfo/freebsd-current >>> > To unsubscribe, send any mail to "freebsd-current-unsubscribe@ >>> freebsd=2Eorg" >>> > >>> >> --=20 Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E From owner-freebsd-current@freebsd.org Wed Mar 28 20:11:09 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 E7BB5F71E3E for ; Wed, 28 Mar 2018 20:11:08 +0000 (UTC) (envelope-from byond.lenox@gmail.com) Received: from mail-lf0-f53.google.com (mail-lf0-f53.google.com [209.85.215.53]) (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 3146980B2F; Wed, 28 Mar 2018 20:11:08 +0000 (UTC) (envelope-from byond.lenox@gmail.com) Received: by mail-lf0-f53.google.com with SMTP id m16-v6so5263242lfc.4; Wed, 28 Mar 2018 13:11:08 -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=JkcvS6tlcQeSOT/oE5Yw+hwWWWLDwCrau8qHHKXrl9k=; b=XWcMfX6sS8uMJJ373PPXrxZxctqQ9tsoUybBbLsjvTKoeldOxhErVTNo5msWjkkqk4 3J8uemJXMcqWBkhz87NTyVZtInXgyUONDSi/poR02fCnyvNf4v2D27OuYYCdVpNqyJOp 0WJ9/eAR5GHeTsPaOFpl72lNe78izT9eZJCWqFZNPP6QLXaWSVpLAtoJN7opaw65lICr BwGp2Tkd6sjRL9hvF/pe26eXdu1JkFjOOt7USGUPjhzCrnb5cma43e7BltEZ4EaYwx6H p8FwbwbJqMt7snPVeITfzW4LGzZAwI6gXhLKGdq/ZCdL5DdkjeyEv9l9R1wLTIfp8g3c OsIg== X-Gm-Message-State: AElRT7HZ6BiAcVDihLZgb2jMhMD3b6o/H9d5Jao3ijdbCD9stiFOpUjE jkqZPltB0+v+gsWG66Qc3zuXSgj+ X-Google-Smtp-Source: AIpwx49JnkXqwuAcJJpaE/qNGyShrnIC8RsHh7Qmo6zFRPtctBs0T1SRUihDqwnqshCe7yBGMyJwQA== X-Received: by 2002:a19:e48e:: with SMTP id x14-v6mr3387773lfi.115.1522267860485; Wed, 28 Mar 2018 13:11:00 -0700 (PDT) Received: from mail-lf0-f51.google.com (mail-lf0-f51.google.com. [209.85.215.51]) by smtp.gmail.com with ESMTPSA id d24-v6sm813268lfc.51.2018.03.28.13.11.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Mar 2018 13:11:00 -0700 (PDT) Received: by mail-lf0-f51.google.com with SMTP id v207-v6so5243633lfa.10; Wed, 28 Mar 2018 13:11:00 -0700 (PDT) X-Received: by 10.46.155.204 with SMTP id w12mr3345929ljj.76.1522267859996; Wed, 28 Mar 2018 13:10:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.129.90 with HTTP; Wed, 28 Mar 2018 13:10:39 -0700 (PDT) In-Reply-To: References: <79d2bd72-f8b2-6476-9589-ebad9716698f@freebsd.org> From: Kyle Evans Date: Wed, 28 Mar 2018 15:10:39 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Boot failure: panic: No heap setup To: Stefan Esser Cc: "" , Warner Losh Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 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: Wed, 28 Mar 2018 20:11:09 -0000 On Tue, Mar 27, 2018 at 6:39 PM, Stefan Esser wrote: > Am 27.03.18 um 21:31 schrieb Kyle Evans: >> >> On Tue, Mar 27, 2018 at 11:06 AM, Stefan Esser wrote: >>> >>> A few weeks ago I tried the LUA boot and found, that my kernel did not >>> start >>> (i.e. did not print the initial FreeBSD version line), but instead >>> stopped >>> with: >> >> >> Oy =/ >> >>> panic: No heap setup >>> >>> I recovered by booting from an alternate boot device and kept my system >>> running until today, where I decided to give the LUA boot another try. >>> >>> The boot failure happened again, with identical message: >>> >>> panic: No heap setup >> >> >> Hmm... that's an sbrk panic [1], indicating that setheap hadn't been >> called. zfsgptboot is zfsboot with gpt bits included, so the relevant >> setheap call is [2] I believe. It's not immediately clear to me how >> switching interpreters could actually be breaking it in this way. >> >> At what point are you hitting this panic? After menu, before kernel >> transition? > > > The menu is displayed and I can unload the kernel and load the kernel > and modules from an alternate path. The lua code seems to work just fine, > but as soon as I enter the "boot" command, the panic happens. > > This happens when the loader transfers control to the kernel but before > any other output is generated. I tried booting a GENERIC kernel just to > be sure this is not caused by an out-dated kernel config file. > >>> I tried booting a GENERIC kernel, but only rebuilding the boot loader >>> (gptzfsloader in my case) without LUA support fixed the issue for me ... >>> >>> The system is -CURRENT (built today) on amd64 (not converted to UEFI, >>> yet). > > > Hmmm, the code references point into the boot loader code - I had > expected that there is a problem in the kernel, not the boot loader. > >> [1] >> https://svnweb.freebsd.org/base/head/stand/libsa/sbrk.c?view=markup#l56 > > > Seems that setbase has either not been called or has been called with > base=0. Right, which is odd... >> [2] >> https://svnweb.freebsd.org/base/head/stand/i386/zfsboot/zfsboot.c?view=markup#l688 > > > I had thought, that the zfs boot code has been initialized before the > menu is displayed? Right, all of this should be done looooong before we get to the interpreter. Can you break into the loader prompt and try the `heap` command, see what that outputs? CC'ing imp@ because he actually knows things. > Or do I misunderstand this phase of the boot process??? > > Regards, STefan