Date: Mon, 13 Jul 2020 12:02:24 +0200 (CEST) From: Christian Kratzer <ck-lists@cksoft.de> To: Allan Jude <allanjude@freebsd.org> Cc: freebsd-fs@freebsd.org Subject: Re: gptzfsboot targeting wrong vdev Message-ID: <alpine.BSF.2.22.395.2007131155560.82939@nocfra1.cksoft.de> In-Reply-To: <78024f0d-4889-713e-15a5-56ec6d8d82b3@freebsd.org> References: <alpine.BSF.2.22.395.2007061453250.82939@nocfra1.cksoft.de> <9400f5f0-e267-932c-b1ce-8436748cf2c0@FreeBSD.org> <78024f0d-4889-713e-15a5-56ec6d8d82b3@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, On Tue, 7 Jul 2020, Allan Jude wrote: > On 2020-07-07 02:21, Andriy Gapon wrote: >> On 06/07/2020 16:10, Christian Kratzer wrote: <snipp/> >>> When booting from ada0 I get following: >>> >>> ZFS: i/o error - all block copies unavailable >>> ZFS: can't read MOS of pool zp1 >>> gptzfsboot: failed to mount default pool zp1 >>> >>> FreeBSD/x86 boot >>> > > So, just to be clear, at this point you have not loaded the boot loader > yet. You are in the bootstrap (gptzfsboot), and it is unable to load the > loader. Sorry for the delay in answering. I got around to some testing again. Thanks for clarifying this. It does make a lot more sense now. > I think it just looks at the first 'freebsd-zfs' type'd partition. > However, if zp1 is GELI encrypted, it shouldn't be able to even tell the > name of the pool. That is what I have also been confused about. It should not have access to the zpool.cache and and should have no way of seeing zp1 which is in geli encrypted da0p1 and da1p2. The loader.conf contains the keys to those which come visbile when the kernel starts. So I was pretty confused on where it was getting the name zp1 from which to my undestanding should not be visible anywhere. > You might try changing the partition type of the boots you are not > booting from, to 'freebsd-vinum' or something other than 'freebsd-zfs' > so that gptzfsboot only sees 1 'freebsd-zfs' to boot from. Before trying that I tried setting the bootme property on the root partitions on ada0 and ada1. That did not help either so I proceeded to set all but the zroot partition type to freebsd-vinum root@zfs1:/home/ck # gpart show => 40 7814037088 da0 GPT (3.6T) 40 4056 - free - (2.0M) 4096 7814029312 1 freebsd-vinum (3.6T) 7814033408 3720 - free - (1.8M) => 40 7814037088 da1 GPT (3.6T) 40 4056 - free - (2.0M) 4096 7814029312 1 freebsd-vinum (3.6T) 7814033408 3720 - free - (1.8M) => 40 7814037088 da2 GPT (3.6T) 40 4056 - free - (2.0M) 4096 7814029312 1 freebsd-vinum (3.6T) 7814033408 3720 - free - (1.8M) => 40 7814037088 da3 GPT (3.6T) 40 4056 - free - (2.0M) 4096 7814029312 1 freebsd-vinum (3.6T) 7814033408 3720 - free - (1.8M) => 40 7814037088 da4 GPT (3.6T) 40 4056 - free - (2.0M) 4096 7814029312 1 freebsd-vinum (3.6T) 7814033408 3720 - free - (1.8M) => 40 7814037088 da5 GPT (3.6T) 40 4056 - free - (2.0M) 4096 7814029312 1 freebsd-vinum (3.6T) 7814033408 3720 - free - (1.8M) => 40 7814037088 da6 GPT (3.6T) 40 4056 - free - (2.0M) 4096 7814029312 1 freebsd-vinum (3.6T) 7814033408 3720 - free - (1.8M) => 40 7814037088 da7 GPT (3.6T) 40 4056 - free - (2.0M) 4096 7814029312 1 freebsd-vinum (3.6T) 7814033408 3720 - free - (1.8M) => 40 468862048 ada0 GPT (224G) 40 1024 1 freebsd-boot (512K) 1064 134217728 2 freebsd-swap (64G) 134218792 33554432 3 freebsd-vinum (16G) 167773224 33554432 4 freebsd-vinum (16G) 201327656 267534424 5 freebsd-zfs [bootme] (128G) 468862080 8 - free - (4.0K) => 40 468862048 ada1 GPT (224G) 40 1024 1 freebsd-boot (512K) 1064 134217728 2 freebsd-swap (64G) 134218792 33554432 3 freebsd-vinum (16G) 167773224 33554432 4 freebsd-vinum (16G) 201327656 267534424 5 freebsd-zfs [bootme] (128G) 468862080 8 - free - (4.0K) That helped. The system now finally boots from the mirror on ada0p5 and ada1p5. Unclear why setting the bootme property did not help on its own. Thanks Christian -- Christian Kratzer CK Software GmbH Email: ck@cksoft.de Wildberger Weg 24/2 Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart Mobile: +49 171 1947 843 Geschaeftsfuehrer: Christian Kratzer Web: http://www.cksoft.de/ From owner-freebsd-fs@freebsd.org Mon Jul 13 17:27:20 2020 Return-Path: <owner-freebsd-fs@freebsd.org> Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 2E90C36B038; Mon, 13 Jul 2020 17:27:20 +0000 (UTC) (envelope-from mmacy@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B59ZJ0TtSz4G6Z; Mon, 13 Jul 2020 17:27:20 +0000 (UTC) (envelope-from mmacy@freebsd.org) Received: from mail-lf1-f41.google.com (mail-lf1-f41.google.com [209.85.167.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) (Authenticated sender: mmacy) by smtp.freebsd.org (Postfix) with ESMTPSA id E14BB2FC09; Mon, 13 Jul 2020 17:27:19 +0000 (UTC) (envelope-from mmacy@freebsd.org) Received: by mail-lf1-f41.google.com with SMTP id g139so9540624lfd.10; Mon, 13 Jul 2020 10:27:19 -0700 (PDT) X-Gm-Message-State: AOAM530CBzn5362d8ZkxsvvELYsKWsBX50PZOGery4Z1yoPOYy3iPums r8PZV4bAbh+nVKWCVFSIc5Gxd/2qIfFZmtxim7g= X-Google-Smtp-Source: ABdhPJx27xPiexmBFm2IppULhgxJHDxbmT+4h4zYmbzee1ZEKh1k00d4Va3rPc4oxES60biSZQaQlJa/0PKLXz5muvM= X-Received: by 2002:a19:a8c:: with SMTP id 134mr139172lfk.128.1594661238368; Mon, 13 Jul 2020 10:27:18 -0700 (PDT) MIME-Version: 1.0 From: Matthew Macy <mmacy@freebsd.org> Date: Mon, 13 Jul 2020 10:27:07 -0700 X-Gmail-Original-Message-ID: <CAPrugNq9R4_FSggHpTt0yGaXkeu05suyFGUFKJxF249h0jOAqQ@mail.gmail.com> Message-ID: <CAPrugNq9R4_FSggHpTt0yGaXkeu05suyFGUFKJxF249h0jOAqQ@mail.gmail.com> Subject: CFT for vendor openzfs - week 2 reminder To: freebsd-current <freebsd-current@freebsd.org>, freebsd-fs <freebsd-fs@freebsd.org>, freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Filesystems <freebsd-fs.freebsd.org> List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-fs>, <mailto:freebsd-fs-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/freebsd-fs/>; List-Post: <mailto:freebsd-fs@freebsd.org> List-Help: <mailto:freebsd-fs-request@freebsd.org?subject=help> List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-fs>, <mailto:freebsd-fs-request@freebsd.org?subject=subscribe> X-List-Received-Date: Mon, 13 Jul 2020 17:27:20 -0000 On Wednesday, July 8th I issued the initial call for testing for the update to HEAD to vendored openzfs. We'd like to give users roughly a month to test before merging. The current *tentative* merge date is August 10th. I hope it's not terribly controversial to point out that it really rests with users of non amd64 platforms to test to avoid any unpleasant surprises the next time they update their trees following the merge. ========================================================== NB: Do NOT zpool upgrade unless you are willing to live without the ability to ever rollback to the legacy zfs kmod. Checkout updated HEAD: % git clone https://github.com/mattmacy/networking.git -b projects/openzfs_vendor freebsd Checkout updated openzfs in to sys/contrib: % git clone https://github.com/zfsonfreebsd/ZoF.git -b projects/openzfs_vendor freebsd/sys/contrib/openzfs Build world and kernel with whatever your usual configuration is. Where possible the openzfs kmod is backward compatible with the cmd utils in HEAD so common operations work with existing tools and the new kmod. In the projects/openzfs_vendor branch of ZoF ozfs libraries are backward compatible with the zfs kmod in HEAD. Although ideally one would test this in a separate boot environment, the interoperability should allow one to rollback without too much difficulty. Thanks in advance for your time. -M
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.22.395.2007131155560.82939>