From owner-freebsd-stable@FreeBSD.ORG Wed Apr 9 07:08:11 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BF1728C2 for ; Wed, 9 Apr 2014 07:08:11 +0000 (UTC) Received: from isis.morrow.me.uk (isis.morrow.me.uk [204.109.63.142]) by mx1.freebsd.org (Postfix) with ESMTP id 9663B1328 for ; Wed, 9 Apr 2014 07:08:10 +0000 (UTC) Received: from anubis.morrow.me.uk (host86-156-171-72.range86-156.btcentralplus.com [86.156.171.72]) (Authenticated sender: mauzo) by isis.morrow.me.uk (Postfix) with ESMTPSA id C2420450B5 for ; Wed, 9 Apr 2014 07:08:08 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 isis.morrow.me.uk C2420450B5 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=morrow.me.uk; s=dkim201101; t=1397027290; bh=z4HT4AMd07uvu0MhgaopC0nrdSOLq34B7dgF3Vzy8qA=; h=Date:From:To:Subject:References:In-Reply-To; b=1Cuhd8NEbx3KBbjiADfUiZuwQu8/nxuMkctYAK1w1SszXXiRvjGX2nyqJPzwNurB4 LoQFUbLWzaPHRmsu9BqaxRXGHg75pSu+UD5byI+F2SLYiU0Tg+puVHDwV6zNH0c+um Dr6f13FIak+/vwCbnwZ5LbwaWEU8Dpq5gnvbKxag= X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.98.1 at isis.morrow.me.uk Received: by anubis.morrow.me.uk (Postfix, from userid 5001) id 7574A12135; Wed, 9 Apr 2014 08:08:04 +0100 (BST) Date: Wed, 9 Apr 2014 08:08:04 +0100 From: Ben Morrow To: freebsd-stable@freebsd.org Subject: Re: Note for those pulling in new ZFS feature flags Message-ID: <20140409070759.GA14719@anubis.morrow.me.uk> Mail-Followup-To: freebsd-stable@freebsd.org References: <20140407135421.GA16385@behemoth> <20140407145511.GA16747@behemoth> <20140407153040.GA17668@behemoth> <4C688889-96C0-4B8C-82E7-ACC3FB729FAB@gromit.dlib.vt.edu> <5344BEAF.1030206@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140409034636.GC5433@behemoth> X-Newsgroups: gmane.os.freebsd.stable User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 07:08:11 -0000 Quoth Chris Nehren : > > Are you asking, in other words, what problems could come from > fixing the bootcode automatically whenever it's needed? The > immediate, obvious concern is that maybe the bits sourced to do > so aren't valid for the pool in question[0] or don't exist. The > latter is easy to check for of course. I'm afraid I don't know > enough to judge the former. > > [0]: Although I can't imagine a situation when that'd be the > case, that doesn't mean such a sitaution doesn't exist. Upgrading a pool on a disk which happens to be attached to this machine at the moment but which is supposed to boot a different architecture? (Rather obscure, I know.) More generally, is it possible to determine post-boot which disk the bootloader actually ran from, and which of {gpt,}{zfs,}boot it was? It would hardly be helpful to 'upgrade' a /boot-on-UFS machine to a ZFS bootloader. Then there's the question of whether FreeBSD's bootstrap is in use at all, rather than something like GRUB. One possibility might be to put a Makefile in /boot which can be customised as necessary; then zfs upgrade could just run 'make -C /boot install' and assume it would DTRT. Ben