On Tue, 17 Mar 2020 16:17:31 +0200 Toomas Soome tso...@me.com said
> On 17. Mar 2020, at 15:51, Matthew Seaman <matt...@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!
:)
--Chris
_______________________________________________
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"