what 3rd party boot mgr is required to boot multiple freebsd versions?
bsd-lists at BSDforge.com
Tue Mar 17 16:01:59 UTC 2020
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
> >> interesting.
> >> : 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
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
one *giant* unbootable slice containing all the tarred up revisions I work
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
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! :)
More information about the freebsd-current