beadm in base

Should beadm be included by default in FreeBSD ZFS installs?


  • Total voters
    26
The very first program I install after installing FreeBSD is beadm so that I can manage boot environments. The main reason I use FreeBSD is for its ZFS support and bootenvs are the star feature.

I'm willing to bet a large wodge of cash that I'm not the only person who uses FreeBSD specifically / mainly for its ZFS support and so I think beadm should be installed by default whenever anyone installs FreeBSD to ZFS. It is only about 10KB uncompressed so space can't be a reason for not including it.

Is there a good reason why its not included in a default install or why it couldn't be installed by default for FreeBSD 12?
 
  • Thanks
Reactions: Oko
Why is pkg not included by default?
Mainly because there's still a lot of development happening on it. So if it was part of the base you will have a lot of updates, not all of them possible due to the ABI/API freeze on a -RELEASE.
 
I see what you mean by beadm not quite being ready just yet SirDice.

One of the primary blockers preventing boot envs being a killer feature of FreeBSD right now is that you cannot boot into alternate BEs via the boot menu - you have to switch via
Code:
beadm activate bename
which of course presumes you have a working BE in which you can run that command. BE's will really come into their own when they can be booted directly from the boot menu.

So, to revise my original response to my own question, I'd like to see beadm considered for inclusion in base after the following bug has been fixed:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=208601
 
I see what you mean by beadm not quite being ready just yet SirDice.

One of the primary blockers preventing boot envs being a killer feature of FreeBSD right now is that you cannot boot into alternate BEs via the boot menu - you have to switch via
Code:
beadm activate bename
which of course presumes you have a working BE in which you can run that command. BE's will really come into their own when they can be booted directly from the boot menu.

So, to revise my original response to my own question, I'd like to see beadm considered for inclusion in base after the following bug has been fixed:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=208601

11.1 has rc.d/zfsbe (which was omitted from the upgrade notes) to help out with some of this; I always patch my beadm to set canmount=noauto, not cannount=on, and with this, switching from the boot menu works like a champ. There are likely some use cases where it doesn't work, hence the upstream hesitation, but it works great for me!
 
  • Thanks
Reactions: Jov
Just came across this one... I'm a huge fan of ZFS, started using it when it had just become a thing with the (commercial) Solaris 10 release (in the good ole days when Sun was still Sun) and well, I have to disagree here.

None of my ZFS powered servers use beadm. In fact, none of those even used the default installer because I seriously dislike the way ZFS gets applied onto a new system. In my opinion it's more common for someone to boot using a rescue CD in order to fix something than it is for someone to actively use beadm.

The reason I mention this is because the default installer seriously hinders the import of its ZFS pool due to the specific canmount setting which is only set to cater to beadm. Even when not being used. In other words: the very moment someone uses a rescue CD and then tries # zpool import -aR /mnt then they won't get to access their root filesystem right away because it didn't automatically mount. Which I think is pretty stupid. Surely beadm should be able to handle these settings whenever someone actually wants to change their boot environment? Instead the installer simply assumes that everyone uses beadm and plenty of users ran into problems when trying to access their ZFS root system because of it.

That's the first reason I'm not in favor of adding beadm to the base, I can't help feel it's much too intrusive already. If people who don't use a tool still get negatively affected because of it then it's too intrusive in my opinion. Of course context matters here.

Anyway... second reason I don't agree is because I don't think the base should become too bloated. I mean, following this reasoning we should also add ports-mgmt/portmaster, ports-mgmt/poudiere and ports-mgmt/synth because that's some of the first things people install. # make -C /usr/ports/ports-mgmt/portmaster install clean is pretty much the very first command I use on a new server.

Of course there's a very thin line here and much will be based on personal opinion as to what is bloat and what is a real necessity but yeah.

If any I think the game of Nethack (games/nethack) should be added to the base system first. First because everyone plays games every once in a while, second because it's a classic which can even help you learn the vi movement keys and third because it hardly ever changes. Last time it lasted... 10 or so years before the next update, so very low risk that the base needs updating because of Nethack ;)
 
If you're using ZFS then you should take advantage of BE's. I create a new BE before and after every system update, installing a port or building something from source. If you do that, you will have no need to use a rescue disc.

I have not had any issues accessing my ZFS / beadm / BE drives from a FreeBSD rescue disc. To mount my (unencrypted) pool with multiple BE's from a FreeBSD boot disk, all I need to type is:

Code:
mount -u /

beadm is 10kb uncompressed. You are extremely hard-pushed, even 30 years ago, to call adding 10Kb to base "bloat".


ZFS snapshots are BE's are my favourite features of FreeBSD and it seems 63% of forum members would like to see beadm included by default.

People accuse Linux of being useless for games even with official Steam support, 1000's of commercial games ported and its better GPU support but I realise you are only joking about nethack. :/
 
Back
Top