ZFS Boot Environments Are Helping To Improve The Resilience Of FreeBSD Upgrades

[brrrrttttt]

freebsd is developed as complete operating system, user-installed apps are separate from "base" system and are in /usr/local/{bin, etc, ...}, there is no way an upgrade would break a system, meanwhile in GNU/Linux sometimes simple update results in unbootable systems or programs failing to launch due to unresolved .so bumps and unresolved shared libraries, there is way too much fragmentation, too many package mangers, too many meaningless distributions,

Rubbish.

pid_eins's systemd has further divided the userbase, many users are fleeing and seeking refuge in Gentoo with OpenRC.

I'm sure all five of them are really mad about it. The other 99.999% of Linux users carry on with their lives, as systemd actually unifies their Linux systems more than ever.

freebsd still has upper hand when it comes to raw tcp/ip performance, packet filtering, and enterprise level zfs file storage.

Everyone's gotta have at least some strengths. The last one is no longer the case, you must have missed the news where they switched their upstream to ZoL.

[vermaden]

"beadm" is pure joy in Solaris,have no patience to reach home and try it at BSD. I will be very glad if it works like in the sunos. Beadm or similar is a must for every OS pretending to be a "modern".
MS system restore is medieval tool compared to beadm

Mine beadm (available on FreeBSD from Ports/packages as sysutils/beadm) works on FreeBSD the same as it works on Solaris, check the linked presentation - https://is.gd/BECTL - even the FreeBSD bootloader same as on Solaris allows you to select to which BE you would like to boot.

As a FreeBSD user myself... this is false. There are a ton of reasons why an upgraded FreeBSD can fail to boot. And I saw probably all of them myself.

The truth is that if you want to hurt yourself, you will hurt yourself. ZFS Boot Environments will not prevent you from making dd(8) with /dev/zero on entire disk which would make system unbootable. The beadm protects you from FreeBSD base system upgrades and/or ports/packages failure upgrades. Protects from configuration changes or from unbootable system when you mess too much in configuration files.

I wrote beadm for FreeBSD in 2012 and I am using id day by day both on servers and desktops and it never failed me. Before FreeBSD had integration in FreeBSD loader you just needed to type by hand from which dataset (ZFS BE) you will boot, now its just selected from the Loader menu.

But maybe you have other experiences that failed for you.

[-MacNuke-]

But maybe you have other experiences that failed for you.

Well the other person said that it is impossible that a system upgrade can break a system. That has nothing to do with beadm. There are different things that failed for me. One time it was a bug in a kernel driver that resulted in a kernel panic, one time it was the VirtualBox module that killed the system (instead of not loading old modules, FreeBSD just tried it and crashed), one time is still a mystery to me why the system did not boot. It just stopped at the bootloader level. Rolling back and doing the update again fixed it.

Then there are user mistakes for sure.

[vermaden]

One time it was a bug in a kernel driver that resulted in a kernel panic

So you just boot into earlier BE, beadm keeps you safe here.

one time it was the VirtualBox module that killed the system (instead of not loading old modules, FreeBSD just tried it and crashed)

So you just boot into earlier BE, beadm keeps you safe here. Alternatively you can boot into single user mode and disable loading VirtualBox modules from /etc/rc.conf and /boot/loader.conf files

[-MacNuke-]

So you just boot into earlier BE, beadm keeps you safe here.

I did not say that this was unfixable. I said that FreeBSD is not immune to a broken system after an upgrade like someone claimed it to be.

[Edward94]

there is no way an upgrade would break a system, meanwhile in GNU/Linux sometimes simple update results in unbootable systems or programs failing to launch due to unresolved .so bumps and unresolved shared libraries, there is way too much fragmentation, too many package mangers, too many meaningless distributions, pid_eins's systemd has further divided the userbase, many users are fleeing and seeking refuge in Gentoo with OpenRC.

[Edward94]

there is no way an upgrade would break a system, meanwhile in GNU/Linux sometimes simple update results in unbootable systems or programs failing to launch due to unresolved .so bumps and unresolved shared libraries, there is way too much fragmentation, too many package mangers, too many meaningless distributions, pid_eins's systemd has further divided the userbase, many users are fleeing and seeking refuge in Gentoo with OpenRC. dqfanfeedback

many users are fleeing and seeking refuge in Gentoo with OpenRC.