Re: what 3rd party boot mgr is required to boot multiple freebsd versions?

On Tue, Mar 17, 2020 at 09:02:14AM -0700, Chris wrote:
> On Tue, 17 Mar 2020 16:17:31 +0200 Toomas Soome tsoome_at_me.com said
> 
> > > On 17. Mar 2020, at 15:51, Matthew Seaman <matthew_at_FreeBSD.org> wrote:
> > > > On 17/03/2020 12:58, Florian Limberger wrote:
> > >> On 16.03.20 23:33, Chris wrote:
> > >> >>> For the record. I'm *only* using FreeBSD in this situation. I
> > >>> only mentioned Windows above, for the use of it's boot manager.
> > >> >> If you only use FreeBSD, and also use ZFS, you might find beadm[1]
> > >> interesting.
> > >> >> [1]: https://www.freshports.org/sysutils/beadm
> > >> > > 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:
> > > >    beadm create FOO
> > > > is actually equivalent to
> > > >    bectl create -r FOO
> > > > ie. turning on the recursive functionality in bectl.
> > > > However, this is not really what the OP was asking about.  As I
> > > understand it, they were looking for something that would allow choosing
> > > between several independent installations of different versions of
> > > FreeBSD, rather than having multiple environments in the same
> > > installation.  You can achieve pretty much the same effect though --
> > > there is a boot menu option to switch between BEs.  You would have to
> > > manage any ported software between the different OS versions, perhaps by
> > > including /usr/local and /var/db/pkg are both parts of your BEs.
> > > > 	Cheers,
> > > > 	Matthew
> > >
> > 
> > BE???s can solve some scenarios. However, it is easy to add support for few
> > more. The current BE menu is populated automatically from the zfs. However,
> > 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 way
> > as it is currently done for ???normal??? BE, or entries with chain load).
> > Read this menu file first and zfs BE list after, and you have BE menu with
> > manual and automatic entries. Can be implemented within few hours.
> > 
> A *huge* thanks for all the thoughtful replies!
> In detail. I maintain *many* ports, and it's not always enough to ensure
> that they build properly. In some cases I need to ensure they actually
> operate on FreeBSD/some-version. To test for building; it's been enough for
> me to spin up any number of jails using whatever (fbsd) revision I'm testing
> against. I had/am hoping that I can create a similar environment. That allows
> for pouring a (fbsd) revision on a slice, and actually booting into it *and*
> a DE. This requires (in my mind) the necessity to dedicate a box for that
> task. This is (currently) all on GPT/UFS scheme/slices. I use the pre-created
> revision(s) I already use in my jails, which are all tarballs named after
> the version-revision.
> disk0:
> gpart destroy -F ada0
> gpart create -s GPT ada0
> gpart add -t freebsd-boot -l <sumname> ... ada0
> gpart add -t freebsd-ufs -l workdrive -s <size> ada0
> ...
> 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
> ...
> disk1:
> one *giant* unbootable slice containing all the tarred up revisions I work
> with.
> Boot into workdrive; which also mounts disk1; newfs a slice && unpack
> the appropriate archive onto the newly formatted slice. Then *attempt* to
> boot into it after bouncing the box. The last part is the one I'm asking this
> question for. It seems to me that /boot on any one of the slices should have
> enough in it to be a legal candidate to boot into. It seems that it *should*
> be possible to get there with whats already available on the beginning of the
> drive. I'd use any one of the ZFS suggestions, except the spare I'm working
> with is only a SandyBridge. So probably not powerful enough to manage the
> overhead required.
> 
> I hope this clears things up, and isn't *too* verbose. Thanks for all the
> valuable input I received, and any additional enlightenment that might follow! :)

Hi,

Why not use VirtualBox and different VMs with different versions?  That
would seem to be easier than messing with boot environments, assuming
the hardware has enough RAM to support VBOX.

Gary