What's happening to FreeBSD?

pkgbase enables binary update of STABLE and CURRENT which was not possible before.
I've ran STABLE at a period with recompiled kernel, for a few years, due to some features. I wouldn't bat an eye if somebody gave me pkgbase back then so I don't have to deal with make buildworld.

pkgbase enables quick patching of a vulnerable component, online. Its quick and lasts seconds.
freebsd-update even if its able to update without reboot, chews the CPU with diffing and stuff. It is not nice running it on a loaded server.

These are futher goals from the wiki :

A wrapper to support the functionality provided by freebsd-update(8) needs to be written, and needs to be 1:1 compatible (manu@ : working on it)

Handbook updates for installation and upgrading
Click to expand...

Besides, without elaborate intervention - which, as written above, will yet again become a freebsd-update run, and not a pkg reconfig and call, the 3rd party pkg cannot really request a bump of a system package. The way I understand now, it is possible from 3rd party or any package to request inside same ABI. In practice this means the system is pending a patchlevel anyhow, and in practice applications do not depend on anything between patchlevels, because they're bugfixing.

In the end I really don't understand what is this lack of isolation people are talking about.
Explain to me how the following Debian scenario plays out : I go apt upgrade something, it pulls in new glibc, that pulls in new linux, that in turn moves my most important OS parts.
 
People do realize that this change happened during many, many, years, right? Not like Windows 7 and the disaster of Windows 8. Yah, changes in FreeBSD aren't common but they do happen over time.

Also important: at its core nothing changed. I'm still using the exact same "boring" methods to keep my servers up to date... Using git to pull new updates, building my OS and everything else using the ports collection.
 
One other thing that pkgbase allows, is downgrades and sidegrades. I.e. from 15-Stable to 15.1. From 15.1 to 15.0, 15.1 to 15-Stable, etc.
It's not perfect but it works. The main bottleneck is the sqlite database which needs to be understood by the source and target versions of pkg.
 
fahrenheit said:
One other thing that pkgbase allows, is downgrades and sidegrades. I.e. from 15-Stable to 15.1. From 15.1 to 15.0, 15.1 to 15-Stable, etc.
It's not perfect but it works. The main bottleneck is the sqlite database which needs to be understood by the source and target versions of pkg.
Click to expand...
It's exactly what pkgb-update does. But, for the moment, I do not allow downgrade. Is downgrade a needed feature? Downgrade from CURRENT version doesn't work (but it's the only one). I didn't dig why.

Upgrade to STABLE or CURRENT has some traps... I speak about that on my git.
 
astyle said:
RTFM: https://docs.freebsd.org/en/books/handbook/cutting-edge/#makeworld (Start there)
Click to expand...

Thank you very much, I know how compile world and kernel, for new users is a good start point

I mean the conflict in pkgbase and install a custom kernel from source, like this:

FreeBSD 15 - now, kernel is a package. How to install my compiled kernel as a package ?

cedric_france discover in 3 steps:

Code: 
make buildkernel
pkg unregister FreeBSD-kernel-generic-15.0
make installkernel DESTDIR=/

for now I use the classic distribution instalation method,but pkgbase seems to be the default and only way in the future
is not bad..can be learned
 
Emrion said:
You think I don't know that and I wrote an utility like pkgb-update?
Thank you! I have some code to rewrite. :eek:

And more seriously, that wasn't my point. It was just to show that with pkgbase all is package and are manipulated the same way with the same commands. So no more isolation.
Click to expand...
Where is pkgb-update? I can't find it in ports.
 
Emrion said:
github.com

GitHub - Emrion/pkgb-update: A tool to make upgrade with pkgbase easy

A tool to make upgrade with pkgbase easy. Contribute to Emrion/pkgb-update development by creating an account on GitHub.
github.com github.com
Click to expand...
In the README you state that pkgbase has many drawbacks and you only mention "the complexity of the commands to type to upgrade".

I think this is way over-engineered because you're trying to support every upgrade scenario like RC, STABLE, CURRENT, etc.

With ZFS boot environments all the fears regarding upgrades should be put to bed because rollbacks and downgrades. I guess you're trying to support both UFS & ZFS then. I think we should all bet on ZFS and let UFS be the filesystem of choice in cloud environments where snapshots are external.
 
pkgb-update does no backup, it's not its job. It's the job of the user who wants to upgrade.
It wasn't a good idea for freebsd-update to support zfs BE, I won't do the same error.

rbranco said:
I think this is way over-engineered because you're trying to support every upgrade scenario like RC, STABLE, CURRENT, etc.
Click to expand...
It all that makes the charm! And almost all the difficulty, I admit.

Anyway, I saw that freebsd-update will support pkgbase. When it will be really the case, without nasty bugs, pkgb-update will be useless. Unless these new upgrades, only possible with pkgbase, be not supported, lol.
 
Emrion said:
pkgb-update does no backup, it's not its job. It's the job of the user who wants to upgrade.
It wasn't a good idea for freebsd-update to support zfs BE, I won't do the same error.
Click to expand...
ZFS snapshots are not backups. ZFS boot environments are the single most important thing to avoid shooting yourself in the foot, and the steps are arguably more complicated, so I don't see the added value.
 
ZFS BE aren't only ZFS snapshot. :sssh:

I don't want to argue to what is really or not a backup, that doesn't matter to me.
I stay under the impression you want to teach me something at each sentence. That's not funny.
 
rbranco said:
In the README you state that pkgbase has many drawbacks and you only mention "the complexity of the commands to type to upgrade".

I think this is way over-engineered because you're trying to support every upgrade scenario like RC, STABLE, CURRENT, etc.

With ZFS boot environments all the fears regarding upgrades should be put to bed because rollbacks and downgrades. I guess you're trying to support both UFS & ZFS then. I think we should all bet on ZFS and let UFS be the filesystem of choice in cloud environments where snapshots are external.
Click to expand...
Not everyone uses ZFS. Personally, I've never used ZFS and don't plan to. But that's not a problem—if pkgbase were to work exclusively with ZFS, I'd have to switch completely to Linux (again).
 
  • Like
Reactions: bjs
Emrion said:
ZFS BE aren't only ZFS snapshot. :sssh:

I don't want to argue to what is really or not a backup, that doesn't matter to me.
I stay under the impression you want to teach me something at each sentence. That's not funny.
Click to expand...
This is a subjective perception.

That ZFS snapshots are not backups is an objective fact.
 
  • Like
Reactions: mer
lanin said:
Not everyone uses ZFS. Personally, I've never used ZFS and don't plan to. But that's not a problem—if pkgbase were to work exclusively with ZFS, I'd have to switch completely to Linux (again).
Click to expand...
This point/aspect is interesting to me. I've been using ZFS on my systems, even on single device, simply because of Boot Environments (easiest rollback to working system on failed upgrade I've ever run across). I recognize the UFS has advantages in some situations, but for me I've thought about pros and cons and wind up ZFS.

Now my opinion only, ZFS and pkgbase.
To me this boils down to the tools. Should a tool like freebsd-update or a new "pkgb-update" recognize "I'm running on a ZFS system so I should create a new BE before I do anything?" That is a valid question to ask. Current default behavior of freebsd-update is "create a new BE before I apply any patches". Should that be the default? I don't know.
I think pkgbase in general and any tools created to deal with it can ask the same question.
Most people that are tracking quarterly for applications typically create a new BE before doing pkg upgrade so they can easily fall back to working system.

So my current understanding, pkgbase does not depend on ZFS, it works fine on UFS, but the question comes down to should any pkgbase tools become ZFS aware. Again, I don't know. Left brain says "no, user needs to control" Right Brain says "Maybe tools should because easier on newbies".
 
lanin said:
Not everyone uses ZFS. Personally, I've never used ZFS and don't plan to. But that's not a problem—if pkgbase were to work exclusively with ZFS, I'd have to switch completely to Linux (again).
Click to expand...
First-class ZFS support is the best selling point of FreeBSD.

ZFS is also portable across multiple operating systems: Solaris/Illumos, FreeBSD, NetBSD, Linux, MacOS X, etc. ZFS doesn't need that much memory if you don't enable online deduplication. Just don't use it on devices without wear leveling like SD cards and USB thumb drives because of the high write amplification inherent to CoW filesystems.
 
mer said:
This point/aspect is interesting to me. I've been using ZFS on my systems, even on single device, simply because of Boot Environments (easiest rollback to working system on failed upgrade I've ever run across). I recognize the UFS has advantages in some situations, but for me I've thought about pros and cons and wind up ZFS.

Now my opinion only, ZFS and pkgbase.
To me this boils down to the tools. Should a tool like freebsd-update or a new "pkgb-update" recognize "I'm running on a ZFS system so I should create a new BE before I do anything?" That is a valid question to ask. Current default behavior of freebsd-update is "create a new BE before I apply any patches". Should that be the default? I don't know.
I think pkgbase in general and any tools created to deal with it can ask the same question.
Most people that are tracking quarterly for applications typically create a new BE before doing pkg upgrade so they can easily fall back to working system.

So my current understanding, pkgbase does not depend on ZFS, it works fine on UFS, but the question comes down to should any pkgbase tools become ZFS aware. Again, I don't know. Left brain says "no, user needs to control" Right Brain says "Maybe tools should because easier on newbies".
Click to expand...
I don't use ZFS not because it's worse than UFS, but because I don't need it. I have two dual-processor, not very fast workstations (Xeon 5120 and 5220 Gold), with not very fast WD Enterprise Gold mechanical drives (FRYZ...). These workstations have ECC RAM installed. Each workstation constantly runs three bhyve virtual machines (one with three Debian, the other with three Windows Server 2022). Each VM uses 32 GB of RAM. Each workstation is connected to a UPS (Eaton 9130).
 
  • Like
Reactions: mer
lanin said:
I don't use ZFS not because it's worse than UFS, but because I don't need it. I have two dual-processor, not very fast workstations (Xeon 5120 and 5220 Gold), with not very fast WD Enterprise Gold mechanical drives (FRYYZ...). These workstations have ECC RAM installed. Each workstation constantly runs three bhyve virtual machines (one with three Debian, the other with three Windows Server 2022). Each VM uses 32 GB of RAM. Each workstation is connected to a UPS (Eaton 9130).
Click to expand...
As a saying goes:
"Horses for courses"

or as an engineer would say "appropriate tool for the specific circumstance"
:)
 
I guess this may be a controversial opinion, but if FreeBSD upgrades/updates are so "dangerous" that everyone sees the need to have boot environments just to be able to rollback to whatever version one had before the upgrade, maybe what we should be addressing is the "dangerous" upgrades.

And, as a stable and UFS user, I know that there are issues.

Waiting 3 months after each minor release to upgrade should not be a necessity to mitigate the risk of a broken system.
 
fahrenheit said:
I guess this may be a controversial opinion, but if FreeBSD upgrades/updates are so "dangerous" that everyone sees the need to have boot environments just to be able to rollback to whatever version one had before the upgrade, maybe what we should be addressing is the "dangerous" upgrades.

And, as a stable and UFS user, I know that there are issues.

Waiting 3 months after each minor release to upgrade should not be a necessity to mitigate the risk of a broken system.
Click to expand...
ZFS, Boot Environments, dangerous.
I think fundamental misunderstanding.
A BE on ZFS makes it easier to rollback to a working system if something goes wrong. Not because an upgrade is "dangerous" but "if something goes wrong how can I revert and recover"
Anyone that has had a failed Windows upgrade understands the issue: it's about the how do I recover. And honestly? ZFS and BEs make recovery trivial: reboot and select the working BE in the boot loader.
 
rbranco said:
This comment is entirely subjective and lacks objective actionable items one can work on. This is the kind of comments that create tempests in a teapot like a few months ago.

You have to be more specific. pkgng ain't perfect but you can open bugs in their issue tracker on github. pkgng is better than the other BSD options. Only Illumos's pkg is better because it handles ZFS boot environments but it's slow because it's written in Python.
Click to expand...
Sorry, but what you said in the first paragraph also applies to your second paragraph. Some can open bugs for freebsd-update...

It would be helpful if someone could show an URL which explains the drawbacks of freebsd-update and the advantages of pkgng? I’ve only come across discussions about the "Brave New World" and general platitudes, but not a single sentence about the actual background to the story.

By the way, I consider downgrading to be one of the most important tasks for developers and QA staff – though not for production systems. If a developer or QA staff member needs a test environment: use virtual machines, containers and so on. Stay well away from production systems! I say this because QA is part of my job.
 
kirsche said:
Sorry, but what you said in the first paragraph also applies to your second paragraph. Some can open bugs for freebsd-update...
Click to expand...
freebsd-update is a bit redundant with pkgbase now.

kirsche said:
It would be helpful if someone could show an URL which explains the drawbacks of freebsd-update and the advantages of pkgng? I’ve only come across discussions about the "Brave New World" and general platitudes, but not a single sentence about the actual background to the story.
Click to expand...
I find that blog post by Vermaden a bit difficult to read because it contains lots of graphics that are distracting and the sensationalism.

I use only -STABLE & -CURRENT with -latest now. So far the only issues I've encountered with pkgng have been:
- The drm-latest-kmod package sometimes break because there's no coordination and some weirdness in the FreeBSD-ports-kmods repository.
- Duplicate entries with pkg-search because some packages are available in both FreeBSD-ports and FreeBSD-ports-kmods.
- pkg not working with secure_level > -1 and they fixed the breakage when I reported it in https://github.com/freebsd/pkg/issues/2586
 
mer said:
ZFS, Boot Environments, dangerous.
I think fundamental misunderstanding.
A BE on ZFS makes it easier to rollback to a working system if something goes wrong. Not because an upgrade is "dangerous" but "if something goes wrong how can I revert and recover"
Anyone that has had a failed Windows upgrade understands the issue: it's about the how do I recover. And honestly? ZFS and BEs make recovery trivial: reboot and select the working BE in the boot loader.
Click to expand...
I have nothing against ZFS or BEs. What I was saying is that most of the cases where I see BEs (and ZFS usually, but as vermandeen explains on his blog also possible with UFS, or lets be real, with any filesystem, ZFS BEs are just better integrated after all these years) is by users worried, just like you mentioned, that an upgrade breaks their system.
So, in my opinion, what should be solved is the breakage, real or potential, people associate with upgrades.
 
fahrenheit said:
So, in my opinion, what should be solved is the breakage, real or potential, people associate with upgrades.
Click to expand...
This can be due to user error or some driver issue or something going wrong during install. BE protects against all three. Making an installation foolproof takes a lot of time and lot of systems and having to consider a lot of variability. FreeBSD doesn't have the resources for it and most volunteers don't want to spend time on doing this sort of work. Now this may be a good use of AI....
 
You must log in or register to reply here.
Back
Top