Date: Tue, 17 Mar 2020 09:02:14 -0700 From: Chris <bsd-lists@BSDforge.com> To: <freebsd-current@freebsd.org> Subject: Re: what 3rd party boot mgr is required to boot multiple freebsd versions? Message-ID: <062e3f0ca7fbb87adc424215b441f897@udns.ultimatedns.net> In-Reply-To: <C8D6AD74-694D-4D3D-AE76-5100E2E2ED14@me.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <matthew@FreeBSD=2Eorg> 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 <sumname> =2E=2E=2E ada0 gpart add -t freebsd-ufs -l workdrive -s <size> ada0 =2E=2E=2E gpart add -t freebsd-ufs -l 11R-rXXXXXX -s <size> ada0 gpart add -t freebsd-usf -l 12S-rXXXXXX -s <size> ada0 gpart add -t freebsd-usf -l 12C-rXXXXXX -s <size> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?062e3f0ca7fbb87adc424215b441f897>