From owner-freebsd-current@freebsd.org Tue Mar 17 16:01:59 2020 Return-Path: Delivered-To: freebsd-current@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 83BCE26A5CE for ; Tue, 17 Mar 2020 16:01:59 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "ultimatedns.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48hdGG0fK1z3wlq for ; Tue, 17 Mar 2020 16:01:57 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (localhost [IPv6:0:0:0:0:0:0:0:1]) by udns.ultimatedns.net (8.15.2/8.15.2) with ESMTPS id 02HG2857035591 (version=TLSv1.2 cipher=DHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Tue, 17 Mar 2020 09:02:15 -0700 (PDT) (envelope-from bsd-lists@BSDforge.com) X-Mailer: Cypht MIME-Version: 1.0 In-Reply-To: From: Chris Reply-To: bsd-lists@BSDforge.com To: Subject: Re: what 3rd party boot mgr is required to boot multiple freebsd versions? Date: Tue, 17 Mar 2020 09:02:14 -0700 Message-Id: <062e3f0ca7fbb87adc424215b441f897@udns.ultimatedns.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 48hdGG0fK1z3wlq X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [0.67 / 15.00]; NEURAL_SPAM_MEDIUM(0.97)[0.974,0]; ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US]; local_wl_ip(0.00)[24.113.41.81]; NEURAL_HAM_LONG(-0.30)[-0.302,0] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 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: Tue, 17 Mar 2020 16:01:59 -0000 On Tue, 17 Mar 2020 16:17:31 +0200 Toomas Soome tsoome@me=2Ecom said > > On 17=2E Mar 2020, at 15:51, Matthew Seaman wrote: > >=20 > > On 17/03/2020 12:58, Florian Limberger wrote: > >> On 16=2E03=2E20 23:33, Chris wrote: > >>=20 > >>> For the record=2E I'm *only* using FreeBSD in this situation=2E I > >>> only mentioned Windows above, for the use of it's boot manager=2E > >>=20 > >> If you only use FreeBSD, and also use ZFS, you might find beadm[1] > >> interesting=2E > >>=20 > >> [1]: https://www=2Efreshports=2Eorg/sysutils/beadm > >>=20 > >=20 > > Did you know that the system now comes with bectl(8) which is very > > similar to beadm? As far as I can tell, the biggest difference is that > > if you have more than one ZFS in your boot environment then: > >=20 > > beadm create FOO > >=20 > > is actually equivalent to > >=20 > > bectl create -r FOO > >=20 > > ie=2E turning on the recursive functionality in bectl=2E > >=20 > > However, this is not really what the OP was asking about=2E As I > > understand it, they were looking for something that would allow choosin= g > > between several independent installations of different versions of > > FreeBSD, rather than having multiple environments in the same > > installation=2E You can achieve pretty much the same effect though -- > > there is a boot menu option to switch between BEs=2E You would have to > > manage any ported software between the different OS versions, perhaps b= y > > including /usr/local and /var/db/pkg are both parts of your BEs=2E > >=20 > > =09Cheers, > >=20 > > =09Matthew > >=20 >=20 > BE=E2=80=99s can solve some scenarios=2E However, it is easy to add support= for few > more=2E The current BE menu is populated automatically from the zfs=2E Howeve= r, > it is also simple task to add a file parser to it and read menu file with > entries with different pool (we only need to activate such entries same w= ay > as it is currently done for =E2=80=9Cnormal=E2=80=9D BE, or entries with = chain load)=2E > Read this menu file first and zfs BE list after, and you have BE menu wit= h > manual and automatic entries=2E Can be implemented within few hours=2E=20 >=20 A *huge* thanks for all the thoughtful replies! In detail=2E I maintain *many* ports, and it's not always enough to ensure that they build properly=2E In some cases I need to ensure they actually operate on FreeBSD/some-version=2E To test for building; it's been enough for me to spin up any number of jails using whatever (fbsd) revision I'm testin= g against=2E I had/am hoping that I can create a similar environment=2E That allo= ws for pouring a (fbsd) revision on a slice, and actually booting into it *and= * a DE=2E This requires (in my mind) the necessity to dedicate a box for that task=2E This is (currently) all on GPT/UFS scheme/slices=2E I use the pre-creat= ed revision(s) I already use in my jails, which are all tarballs named after the version-revision=2E disk0: gpart destroy -F ada0 gpart create -s GPT ada0 gpart add -t freebsd-boot -l =2E=2E=2E ada0 gpart add -t freebsd-ufs -l workdrive -s ada0 =2E=2E=2E gpart add -t freebsd-ufs -l 11R-rXXXXXX -s ada0 gpart add -t freebsd-usf -l 12S-rXXXXXX -s ada0 gpart add -t freebsd-usf -l 12C-rXXXXXX -s ada0 =2E=2E=2E disk1: one *giant* unbootable slice containing all the tarred up revisions I work with=2E Boot into workdrive; which also mounts disk1; newfs a slice && unpack the appropriate archive onto the newly formatted slice=2E Then *attempt* to boot into it after bouncing the box=2E The last part is the one I'm asking th= is question for=2E It seems to me that /boot on any one of the slices should hav= e enough in it to be a legal candidate to boot into=2E It seems that it *should= * be possible to get there with whats already available on the beginning of t= he drive=2E I'd use any one of the ZFS suggestions, except the spare I'm working with is only a SandyBridge=2E So probably not powerful enough to manage the overhead required=2E I hope this clears things up, and isn't *too* verbose=2E Thanks for all the valuable input I received, and any additional enlightenment that might foll= ow! :) --Chris