From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gentoo-user+bounces-196740-garchives=archives.gentoo.org@lists.gentoo.org>
Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by finch.gentoo.org (Postfix) with ESMTPS id D7D9C1580B9
	for <garchives@archives.gentoo.org>; Mon, 23 Aug 2021 19:50:48 +0000 (UTC)
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
	by pigeon.gentoo.org (Postfix) with SMTP id E8A71E0A6A;
	Mon, 23 Aug 2021 19:50:40 +0000 (UTC)
Received: from mail.teknik.io (mail.teknik.io [5.79.72.163])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(No client certificate requested)
	by pigeon.gentoo.org (Postfix) with ESMTPS id 3A2BFE0A00
	for <gentoo-user@lists.gentoo.org>; Mon, 23 Aug 2021 19:50:40 +0000 (UTC)
dkim-signature: v=1; a=rsa-sha256; d=teknik.io; s=dkim;
	c=relaxed/relaxed; q=dns/txt; h=From:Subject:Date:Message-ID:To:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References;
	bh=As4yZ7QkHbi3dhrPZEFaE/rt8Dqlk3rb7ZfCofRCRSE=;
	b=Rx784vfaQ+6B+Fr/ZPGq6xj3A3eIAFERFDUFLO/rdlBE6mODUFaONs/66ugh1O/dXSQbryImJEbLhZ1lQuQSq2SJQR/aYTgho42lF95usgj2oNy1e7lRKD49Xr8sD9j9R8bKMtPZkzs4yptd/TWoD8jlUlmwx8DHGbk1H03NZC9kkk+FjVokjnCKm2zbsLwx31FLW2Uh27Y3aw0tjLb0of0pZooDemthTg58mfMnOk6buausnR7Nri7fBY
	P+BZOeau/5nKYAGUFeONxcns72kLEw6Y5aSvOZrQAJOVaftaDdMDleI6HMaCQsJ2RT9NzSc55zE/ODZOwOWz9wZmY+ew==
Received: from mail.teknik.io (TEKNIK-SERVER [5.79.72.163])
	by mail.teknik.io with ESMTPSA
	(version=TLSv1.2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128)
	; Mon, 23 Aug 2021 12:50:38 -0700
Precedence: bulk
List-Post: <mailto:gentoo-user@lists.gentoo.org>
List-Help: <mailto:gentoo-user+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-user+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-user+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-user.gentoo.org>
X-BeenThere: gentoo-user@lists.gentoo.org
Reply-to: gentoo-user@lists.gentoo.org
X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply
Mime-Version: 1.0
Date: Mon, 23 Aug 2021 19:50:38 +0000
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: RainLoop/1.11.3
From: "Vitor Hugo Nunes dos Santos" <vitorhugo@teknik.io>
Message-ID: <ca8c2d07f56371f8e1fbcafe2bce3314@teknik.io>
Subject: Re: [gentoo-user] rescue cd for zfs 2.1 or thereabouts
To: gentoo-user@lists.gentoo.org
In-Reply-To: <CAGfcS_ntaE1t9JkyxgrFm6f=RABqHkPr6hFWXX7SV=B17p3DFA@mail.gmail.com>
References: <CAGfcS_ntaE1t9JkyxgrFm6f=RABqHkPr6hFWXX7SV=B17p3DFA@mail.gmail.com>
 <C37CC229-37B6-4FFC-A8A5-926DDE9BFE27@mail.teknik.io>
 <CAGfcS_=78c9LZ-G3ytvz97jqX_WvFFocJ2zwZE2kXJx9zM_-zQ@mail.gmail.com>
 <20210823185739.14936fbb@digimed.co.uk>
 <CAGfcS_noTcvZqJP=zr85ZN0r9XKd3zpnG+r4=2RugJ+MiBtyDw@mail.gmail.com>
 <20210823191330.41fd559a@digimed.co.uk>
X-Archives-Salt: e5eaa4d5-33ee-4907-ba42-1e9d258886ee
X-Archives-Hash: 2fc121872ae7954b286bfd2eb2685317

You set yourself up for failure by sharing the same pool for /boot and ro=
ot.=0AHere's the flags you're meant to use for your boot pool:=0A=0Ahttps=
://openzfs.github.io/openzfs-docs/Getting%20Started/Debian/Debian%20Buste=
r%20Root%20on%20ZFS.html#step-2-disk-formatting=0A=0AUnder "Create boot p=
ool".=0AGRUB purposefully has lacking documentation, as they are not frie=
ndly towards=0AZFS as a whole, and also because most people doing ZFS now=
adays do an EFISTUB=0Asetup with no GRUB, exactly to avoid these issues.=
=0A=0AAugust 23, 2021 3:30 PM, "Rich Freeman" <rich0@gentoo.org> wrote:=
=0A=0A> On Mon, Aug 23, 2021 at 2:13 PM Neil Bothwick <neil@digimed.co.uk=
> wrote:=0A> =0A>> All I could find was this:=0A>> =0A>> http://git.savan=
nah.gnu.org/cgit/grub.git/tree/grub-core/fs/zfs/zfs.c#n276=0A>> =0A>> For=
 a program with so much documentation, GRUB seems sorely lacking in=0A>> =
this respect. It makes me glad I decided to keep /boot off my zpools.=0A>=
 =0A> Even this seems lacking. For example, encryption is not read-only=
=0A> compatible (which seems obvious), and it isn't listed as compatible =
in=0A> the source code you linked. However, grub-mount supposedly uses th=
e=0A> grub drivers and it has a command line option to provide an encrypt=
ion=0A> key. Maybe it is only compatible with the grub-mount command and =
not=0A> at boot time, but if so that seems like something worth pointing =
out=0A> since one of the purposes of grub-mount is to test filesystem=0A>=
 compatibility.=0A> =0A> --=0A> Rich