From nobody Wed Aug 24 10:04:32 2022 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MCMC75PmHz4Zpyw for ; Wed, 24 Aug 2022 10:04:35 +0000 (UTC) (envelope-from SRS0=Ad7j=Y4=klop.ws=ronald-lists@realworks.nl) Received: from smtp-relay-int.realworks.nl (smtp-relay-int.realworks.nl [194.109.157.24]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4MCMC61T92z3fdr; Wed, 24 Aug 2022 10:04:34 +0000 (UTC) (envelope-from SRS0=Ad7j=Y4=klop.ws=ronald-lists@realworks.nl) Date: Wed, 24 Aug 2022 12:04:32 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=klop.ws; s=rw2; t=1661335472; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=kZJ2h+ttS5oBErysDNjXXa6tElvPFu0DWxnIo1msfiI=; b=vG+V7JpKAuozeia4AEcARrdeQzWebOKdBqZ4zOScbq2NGRnIn+tpsOdOk5P8BjwHpH75oS PNAoL/pLveSiu3gq81pWU0pz3VHq48kxMs7fphnxTVvzEwga2o39f1KXke7IlqHgS3GDad Lb7AJmNDUAahO00H0fTI1vhshg7icxh7+JNoi4w+5NUgMYfsSVTXAhqI7Z41uT8KuNo8AP gpjxHPxS2458Q8k2JFGvlHzy5EqS568AJWcCMwFt7407GDXzJo2EMI83O0dQFnsfjrjrto yw/44itFy7av8ZLcjQpOSooq+KfX29ePraaOGwLn2uxJt7wSQU1ZAroS7LiSbA== From: Ronald Klop To: Peter Jeremy Cc: FreeBSD-STABLE Mailing List , John Kennedy Message-ID: <284888814.115.1661335472728@localhost> In-Reply-To: References: <389080342.286.1661263368708@localhost> Subject: Re: boot environment and /var/db/etcupdate ? List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_114_202692365.1661335472722" X-Mailer: Realworks (620.114) Importance: Normal X-Priority: 3 (Normal) X-Rspamd-Queue-Id: 4MCMC61T92z3fdr X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=klop.ws header.s=rw2 header.b=vG+V7JpK; dmarc=pass (policy=quarantine) header.from=klop.ws; spf=pass (mx1.freebsd.org: domain of "SRS0=Ad7j=Y4=klop.ws=ronald-lists@realworks.nl" designates 194.109.157.24 as permitted sender) smtp.mailfrom="SRS0=Ad7j=Y4=klop.ws=ronald-lists@realworks.nl" X-Spamd-Result: default: False [-2.19 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; NEURAL_HAM_SHORT(-1.00)[-0.998]; NEURAL_HAM_LONG(-1.00)[-0.995]; MID_RHS_NOT_FQDN(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[klop.ws,quarantine]; FORGED_SENDER(0.30)[ronald-lists@klop.ws,SRS0=Ad7j=Y4=klop.ws=ronald-lists@realworks.nl]; R_SPF_ALLOW(-0.20)[+ip4:194.109.157.0/24]; R_DKIM_ALLOW(-0.20)[klop.ws:s=rw2]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCVD_COUNT_ZERO(0.00)[0]; MLMMJ_DEST(0.00)[freebsd-stable@freebsd.org]; MIME_TRACE(0.00)[0:+,1:+,2:~]; HAS_X_PRIO_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; ASN(0.00)[asn:3265, ipnet:194.109.0.0/16, country:NL]; ARC_NA(0.00)[]; DKIM_TRACE(0.00)[klop.ws:+]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; FROM_NEQ_ENVFROM(0.00)[ronald-lists@klop.ws,SRS0=Ad7j=Y4=klop.ws=ronald-lists@realworks.nl] X-ThisMailContainsUnwantedMimeParts: N ------=_Part_114_202692365.1661335472722 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Van: Peter Jeremy Datum: woensdag, 24 augustus 2022 10:46 Aan: John Kennedy CC: Ronald Klop , FreeBSD-STABLE Mailing List Onderwerp: Re: boot environment and /var/db/etcupdate ? > > On 2022-Aug-23 15:52:53 -0700, John Kennedy wrote: > >On Tue, Aug 23, 2022 at 04:02:48PM +0200, Ronald Klop wrote: > >> Hi, > >> > >> I'm running the super duper boot environment using ZFS. [1] > >> > >> I have /var and /usr/local as separate datasets. These do not change when I upgrade the OS and that keeps the backups a lot smaller as the backup sees a new BE as a new dataset and fully zfs sends all the data again. > >> > >> But when I rollback /var/db/etcupdate is not in sync with / anymore. > >> And /var/db/ports and /var/db/pkg should be kept in sync with /usr/local. But I do not need to rollback these if I need to go back to the previous BE. > > Looking in /var, the only thing I can see that needs to track the BE > is /var/db/etcupdate - everything else should preferentially be > outside the BE (and having things like e.g. /var/mail in the BE will > cause problems if you rollback the BE). > > /usr/local and /var/db/pkg need to track to prevent package installation > metadata getting out of step with the actual installed packages. > > > For my part, /var/db/pkg is mostly just a reference to my local > >poudriere package stash and is relevant to the BE (but pretty stagnant > >unless I'm changing major versions between 12/13/14). On my system, > >/var/db is part of /. > > Several database ports default to putting their data under /var/db so > having that in a BE is likely to cause problems if you rollback. > > > I'd be a little leery of having /usr/local decoupled from the BE, > >but that's mostly worried about things like kernel drivers that would > >get out of sync with the kernel in the BE. > > Kernel driver ports should all be in /boot/modules, not /usr/local (this > does mean that rolling back a BE will cause problems with the metadata > associated with those ports, but typically there are relatively few > such ports). I don't believe there are any other ports that are > tightly bound to the actual running kernel (though sysutils/lsof comes > close). > > A downside of putting /usr/local in the BE is that another large > collection of ports default to storing their data under /usr/local > and that should be decoupled from BEs. > > Overall, I don't believe there's a one-size-fits-all solution to > identifying what should be part of the BE. If you are using BEs > to switch between major versions, it probably does make sense to > include /usr/local in the BE - but then you need to extricate all > the application data that needs to not be rolled back. > > -- > Peter Jeremy > > > > Hi, I agree. I think the structure of /var is a bit inconsistent with the recommendation from the BootEnvirtonments wiki page [1] and bsdinstall [2]. AFAIS /var/db/pkg and /var/db/ports could better be in something like /usr/local/var/db. /var/db/portsnap has similar issues to stay in sync with /usr/ports. And when I do a major upgrade of pkgs I find it ok to make a separate snapshot of /usr/local. I use BEs primarily to have predictable OS upgrades. You are right the one size fits all is a hard one. And the current structure of /var makes it hard to customize also. ;-) Regards, Ronald. [1] https://wiki.freebsd.org/BootEnvironments [2] https://www.freebsd.org/cgi/man.cgi?bsdinstall(8) ------=_Part_114_202692365.1661335472722 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit  

Van: Peter Jeremy <peterj@freebsd.org>
Datum: woensdag, 24 augustus 2022 10:46
Aan: John Kennedy <warlock@phouka.net>
CC: Ronald Klop <ronald-lists@klop.ws>, FreeBSD-STABLE Mailing List <freebsd-stable@freebsd.org>
Onderwerp: Re: boot environment and /var/db/etcupdate ?

On 2022-Aug-23 15:52:53 -0700, John Kennedy <warlock@phouka.net> wrote:
>On Tue, Aug 23, 2022 at 04:02:48PM +0200, Ronald Klop wrote:
>> Hi,
>>
>> I'm running the super duper boot environment using ZFS. [1]
>>
>> I have /var and /usr/local as separate datasets. These do not change when I upgrade the OS and that keeps the backups a lot smaller as the backup sees a new BE as a new dataset and fully zfs sends all the data again.
>>
>> But when I rollback /var/db/etcupdate is not in sync with / anymore.
>> And /var/db/ports and /var/db/pkg should be kept in sync with /usr/local. But I do not need to rollback these if I need to go back to the previous BE.

Looking in /var, the only thing I can see that needs to track the BE
is /var/db/etcupdate - everything else should preferentially be
outside the BE (and having things like e.g. /var/mail in the BE will
cause problems if you rollback the BE).

/usr/local and /var/db/pkg need to track to prevent package installation
metadata getting out of step with the actual installed packages.

>  For my part, /var/db/pkg is mostly just a reference to my local
>poudriere package stash and is relevant to the BE (but pretty stagnant
>unless I'm changing major versions between 12/13/14).  On my system,
>/var/db is part of /.

Several database ports default to putting their data under /var/db so
having that in a BE is likely to cause problems if you rollback.

>  I'd be a little leery of having /usr/local decoupled from the BE,
>but that's mostly worried about things like kernel drivers that would
>get out of sync with the kernel in the BE.

Kernel driver ports should all be in /boot/modules, not /usr/local (this
does mean that rolling back a BE will cause problems with the metadata
associated with those ports, but typically there are relatively few
such ports).  I don't believe there are any other ports that are
tightly bound to the actual running kernel (though sysutils/lsof comes
close).

A downside of putting /usr/local in the BE is that another large
collection of ports default to storing their data under /usr/local
and that should be decoupled from BEs.

Overall, I don't believe there's a one-size-fits-all solution to
identifying what should be part of the BE.  If you are using BEs
to switch between major versions, it probably does make sense to
include /usr/local in the BE - but then you need to extricate all
the application data that needs to not be rolled back.

-- 
Peter Jeremy
 


Hi,

I agree. I think the structure of /var is a bit inconsistent with the recommendation from the BootEnvirtonments wiki page [1] and bsdinstall [2].
AFAIS /var/db/pkg and /var/db/ports could better be in something like /usr/local/var/db. /var/db/portsnap has similar issues to stay in sync with /usr/ports.

And when I do a major upgrade of pkgs I find it ok to make a separate snapshot of /usr/local. I use BEs primarily to have predictable OS upgrades.

You are right the one size fits all is a hard one. And the current structure of /var makes it hard to customize also. ;-)

Regards,
Ronald.

[1] https://wiki.freebsd.org/BootEnvironments
[2] https://www.freebsd.org/cgi/man.cgi?bsdinstall(8) ------=_Part_114_202692365.1661335472722--