From owner-freebsd-current@freebsd.org Mon Dec 18 20:29:45 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7AC24E84DFB for ; Mon, 18 Dec 2017 20:29:45 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (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 3DD646E564 for ; Mon, 18 Dec 2017 20:29:45 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x22b.google.com with SMTP id m11so6318484iti.1 for ; Mon, 18 Dec 2017 12:29:45 -0800 (PST) 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=yaEHgrXy3iLJNWmwfrx9yxkNuU7xhiEfqo38GZyV5tM=; b=nplYDOtTojXKCt+r3EvoiPV00yZDRSAyX05hgfdy3HzuHX6M6KxsyPiPQioMIPDzPT xDLHnUSqk5Luw54XgWyLZDMP4OMmhy0z1nLZ+71VrF3KLi2dUP+IKcr5yHDghtLlz33D Flgw8KuAm2JUWfraXBqR0qKo7PWVRETqYBB5c6g7R4yHp/WqR8rTcrymGduWHrmHep7x 3kIkshnAxNg0EJGyrkZwXhks3M+wZVuz+oDsBfrJqC/iluQ86TDghJj93gJYq6kywldP HzLO0qwdtNDTIGwQtDV19s7CzgiBYbVj6Wuv3Ocl7ZnOmeH244JRvl8ZR/sPLrcV0RQ1 iHMQ== 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=yaEHgrXy3iLJNWmwfrx9yxkNuU7xhiEfqo38GZyV5tM=; b=VvBnS+bfIRBiAuKlT3TYDr2j02V5/pUqT0U5V4I343598cARg9B5uaydGduFJxwxC/ 3DvObSdWn53EhN3S3a1jD/h8bdziB0gx0PXJecxDwhAosmNBqdJaxVjBxv4bXi91KKwU ehfCnuUUdAfwi8CWahy6LZb02/bcTzJjQ8TVWcMpEJ1/KcAGjAxD4fb2TLcKkXEfIkmZ +l/JWZqTojInLDVaUuqB8fSMiwq7qcNwUy9de7xNex7jK9uQhHsJpTK4xZBHj0rjjlv2 DNxAA18/mhy2MWr0w8wE/bDOZFr2Sb5JOxqglGY6RH0HdE4EnO1UhOwmePaQxgfHOn+M AIpQ== X-Gm-Message-State: AKGB3mKMGMmpKhSPo5aQ/sSGGTSZluoxlL4/ReTVE8U8yLBS5wP++14r KqLe6sr0eKXqGpC4X+mpfpuqEnThsTuMhNcJytwJ4A== X-Google-Smtp-Source: ACJfBouMtdDhSuLhqvS+hs+xyYMDPmBeL14Sjwzo0X8cPWN6hGwkUCQVm1W+eOxlnqLg33jgmtNYTb92i8DfeKA+/dk= X-Received: by 10.36.164.13 with SMTP id z13mr427537ite.115.1513628984263; Mon, 18 Dec 2017 12:29:44 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.108.204 with HTTP; Mon, 18 Dec 2017 12:29:43 -0800 (PST) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: References: From: Warner Losh Date: Mon, 18 Dec 2017 13:29:43 -0700 X-Google-Sender-Auth: vCVP4JSnrJNJ6z634rM_ixc5hmE Message-ID: Subject: Re: UEFI booting survey To: Maxim Sobolev Cc: Jakob Alvermark , FreeBSD Current Content-Type: text/plain; charset="UTF-8" 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: Mon, 18 Dec 2017 20:29:45 -0000 On Mon, Dec 18, 2017 at 1:21 PM, Maxim Sobolev wrote: > Not really specific to UEFI, but when ZFS is in use the /boot might be > partially or fully located on the drive that does not correspond to your > boot drive. We've bumped into this issue on AWS recently when our kernel > ended up on second drive after upgrade in a pool that were spanning two EBS > volumes. Now, it does not work with AWS (as boot code only has access to > the boot EBS volume apparently), but according to Alan such scenario is > totally supported on a physical hardware. So I am worried that by not > allowing loader to scan all drives in the system you'd make this scenario > fundamentally impossible. > Let's get one thing clear: nothing in what I've said would make this impossible. The first thing we do is to boot off something specific, no matter what that specific thing might be. If you want to boot a kernel off a floppy after loading /boot/loader.efi from cdrom, I don't care and won't prevent that since you can easily specify that with UEFI paths. For UFS the above scenario wouldn't automatically work, but could easily be made to work. ZFS is a bit special, since it spans multiple drives. I'm not touching the code that hunts for the zpools at all. If we can find them, and they have the right info, we'll still boot. I'm surprised the upgrade didn't work, especially with the code that's gone in to hunt for disks to present as devices in the loader itself. The specific thing we will stop doing is that in the absence of instructions to the contrary, we will no longer search for root on a device other than the one the loader.efi came from. No other boot loader we have does that. No other loader outside of the tree does that to my knowledge. boot1.efi is the only one that did, and it was a bad call to do so. Warner > On Mon, Dec 18, 2017 at 5:50 AM, Jakob Alvermark > wrote: > >> On 12/17/17 20:52, Warner Losh wrote: >> >>> Greetings >>> >>> If you are booting off UEFI and have a bit of an unusual setup, I'd like >>> you to drop me a line. >>> >>> The setup that I'm looking for is any case where you load boot1.efi off >>> one >>> drive (cd, ssd, hdd, nvme, etc), but don't have a FreeBSD system on that >>> drive, but on a different drive on the system. >>> >>> An example of this may be loading boot1.efi off what FreeBSD would call >>> /dev/ada0p1, but having root come from /dev/ada1p1. >>> >>> It's my belief that due to the fragility of this setup, few, if any, >>> people >>> have this setup. If you do, please take a minute to reply to this >>> message. >>> In the coming months, we're looking at dropping boot1.efi and instead >>> installing /boot/loader.efi onto the ESP (most likely as >>> \efi\freebsd\loader.efi). As part of the move to fully support the UEFI >>> Boot Manager, we're dropping the 'search every device in the system' part >>> of the current boot1 algorithm. It will be possible to configure the >>> system >>> to continue booting (either via the new efibootmgr which will allow any >>> imaginable combination, or possibly via a fallback mechanism needed for >>> the >>> embedded EFIs that have poor UEFI Variable support at the moment), but as >>> part of an upgrade to a future FreeBSD 12, some intervention will be >>> necessary. >>> >>> Please let me know if you have an unusual setup like this. >>> >>> Warner >>> >> Hi Warner, >> >> I have what I guess is an unusual setup, not like what you describe >> above, but unusual because I tripple-boot my laptop using only the UEFI >> boot manager to select the OS to boot. >> I have FreeBSD-current, OpenBSD-current and Windows 10 on different >> partitions on one SSD. By default it boots FreeBSD. >> >> This was accomplished with bcdedit.exe in Windows, but now I realize this >> could be done with the new efibootmgr. >> I wanted to try it out, but it panics on my laptop. Sometimes just >> 'kldload efirt' just panics, sometimes it loads but panics as soon as I run >> efibootmgr or efivar. >> How can I help debugging this? >> >> Jakob >> >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org >> " >> >> >