5 ms·

I really like FreeBSD, and I run it on my home server, but the whole update process really needs a lot of work. The process described in this announcement is a

I really like FreeBSD, and I run it on my home server, but the whole update process really needs a lot of work. The process described in this announcement is accurate in my experience: Run freebsd-update twice, reboot, run freebsd-update again, reinstall or rebuild applications, reboot again, run freebsd-update yet again. The upgrade process works well, but it's much more manual than it is in the Linux world. When PkgBase[0] becomes a thing, I hope that the process will be closer to the Linux world. The other thing that hurts the upgrade process is the lack of packaged software. My big pain point is currently PostgreSQL 12+PostGIS 3.0. This combination in FreeBSD isn't a thing, the packaged/ported PostGIS 3.0[1] is for PostgreSQL 11. My solution has been to build PostgreSQL 12 from ports (because the packaged version doesn't include XML support, which I also want) then build PostGIS 3.0 from source, after installing all its dependencies from packages. I have to rebuild PostGIS after most FreeBSD upgrades since it links against now-changed libraries. If I were doing this in the OpenSuse world I would just use the Applications:Geo repository[2] and be able to install the right combination of software very easily. Because of these issues, I'm slowly moving towards using FreeBSD to host VMs running whatever OS/distribution is most appropriate for the job. Moving PostgreSQL off of FreeBSD will greatly simplify my upgrade process. [0] https://wiki.freebsd.org/PkgBase https://wiki.freebsd.org/PkgBase [1] https://www.freshports.org/databases/postgis30/ https://www.freshports.org/databases/postgis30/ [2] https://build.opensuse.org/project/show/Application:Geo https://build.opensuse.org/project/show/Application:Geo

nix23 6y ago
Why do you not use poudriere? And build automatically everything from ports then install the build-ed packages on you machine's?
- Mister_Snuggles 6y ago
  This is something I've been meaning to look into, but it still doesn't change the postgis30/postgresql11-server dependency in the current ports tree. I'm sure I could work around it, but then I start to ask myself whether I'd rather do FreeBSD software administration or create an OpenSuse VM, install the packaged software (which is already the right version and already has the right config options), and work on my GIS project.
  - nix23 6y ago
    >but it still doesn't change the postgis30/postgresql11-server dependency in the current ports tree If you tell make.conf that postgres12 is the default it will compile postgis for that version, same with php/ruby/mysql and so on.
- asveikau 6y ago
  I feel poudriere takes too much time and disk space building literally everything. I would like it to pick up dependencies from pkg and only build stuff from source when I have options changed. Incidentally I wrote a shell script that does this.
  - nix23 6y ago
    >I feel poudriere takes too much time and disk space building literally everything. No not really just your packages and the dependencies of those.
    - asveikau 6y ago
      Ok, slight exaggeration. The dependencies get quite huge though, especially when you are using something substantial.
      - nix23 6y ago
        Yeah that's true, having 1400 pkg installed needs often ~300 pkg to rebuild...but hey then you know everything is in harmony ;)
        asveikau 6y ago
        Building both gcc and llvm from scratch (which somehow usually ends up happening) is probably more harmony than I need in my life.
        nix23 6y ago
        Both are faster build then chrome or Firefox ;)
asveikau 6y ago
I actually think there is nothing wrong with the upgrade process. What about pkg-style makes it better? On those other systems you still need a reboot for kernel changes to take effect.
- Mister_Snuggles 6y ago
  It's more the number of reboots and invocations of freebsd-update. Since these are all manual steps, you need to keep track of where you are and invoke the next step manually. The current process for upgrading FreeBSD is roughly, assuming that you're just using packages and not ports is: * freebsd-update upgrade * freebsd-update install * reboot * freebsd-update install * pkg upgrade * reboot * freebsd-update install * (optional) reboot In comparison, the process for upgrading OpenSuse Tumbleweed, assuming that you're just using packaged software, is: * zypper dup * reboot If the base system were managed by pkg, the FreeBSD version of the process should probably look a lot like the OpenSuse Tumbleweed version. Condensing upgrades down to a two-step process seems like it will be a significant quality-of-life improvement to me.
  - asveikau 6y ago
    But if there are ABI breakages in base (say, a new syscall used in libc) you want to boot the new kernel with the old userland, then get the new userland later. At least, I have heard this explanation in the context of OpenBSD, and assume it may also apply to FreeBSD.
    - Mister_Snuggles 6y ago
      I believe that's the same in FreeBSD as well. I also think it's a solved problem in the Linux world - OpenSuse Tumbleweed sometimes rebuilds every package because they've changed libc. Apart from watching 2000+ packages get updated, there's really no impact when this happens. To solve this, the updater could create a new boot environment[0], install everything in that boot environment using as many passes as required, then reboot into that environment. OpenSuse already does a similar thing[1], though I don't know how well it works. [0] https://www.freebsd.org/cgi/man.cgi?beadm https://www.freebsd.org/cgi/man.cgi?beadm [1] https://news.opensuse.org/2018/05/15/transactional-updates-in-opensuse-leap-15/ https://news.opensuse.org/2018/05/15/transactional-updates-i...
bluGill 6y ago
While I mostly agree, you also hit the power of the freebsd system: you can do something different. In linux if you want PostgreSQL 12+PostGIS 3.0 with xml support and the packages deliver PostgreSQL 12+PostGIS 3.0 without xml you are stuck without xml support as the package systems don't make it easy for lay people to select options. With FreeBSD you get that power if you want it. It should be easier though.
dddddaviddddd 6y ago
I usually upgrade by recompiling the OS. Minor updates only take a few minutes to compile using filemon and the WITH_META_MODE=YES environment variable. The advantage is that it's easy to maintain out-of-tree patches to the source.
MrMorden 6y ago
I don't update Linux, FreeBSD, or any other OS in place except on my FreeBSD-CURRENT desktop. The only way to operate in production is to create a new VM from your template, apply the runbook/state/whatever, route everything to the new VM, and drain the old VM. My personal systems aren't where they should be for CM, but I still can't think of a good reason to update in place rather than rebuild and copy over configuration/data. Flavors should make it easier to operate with packages instead of ports, but I don't have any idea what's going on there. If I were supporting a large number of systems, I'd want FreeBSD over Linux any day of the week and twice on Sundays because the ports system doesn't make you choose between a stable OS branch and current software.

nix23 6y ago

Why do you not use poudriere? And build automatically everything from ports then install the build-ed packages on you machine's?

Mister_Snuggles 6y ago
This is something I've been meaning to look into, but it still doesn't change the postgis30/postgresql11-server dependency in the current ports tree. I'm sure I could work around it, but then I start to ask myself whether I'd rather do FreeBSD software administration or create an OpenSuse VM, install the packaged software (which is already the right version and already has the right config options), and work on my GIS project.
- nix23 6y ago
  >but it still doesn't change the postgis30/postgresql11-server dependency in the current ports tree If you tell make.conf that postgres12 is the default it will compile postgis for that version, same with php/ruby/mysql and so on.
asveikau 6y ago
I feel poudriere takes too much time and disk space building literally everything. I would like it to pick up dependencies from pkg and only build stuff from source when I have options changed. Incidentally I wrote a shell script that does this.
- nix23 6y ago
  >I feel poudriere takes too much time and disk space building literally everything. No not really just your packages and the dependencies of those.
  - asveikau 6y ago
    Ok, slight exaggeration. The dependencies get quite huge though, especially when you are using something substantial.
    - nix23 6y ago
      Yeah that's true, having 1400 pkg installed needs often ~300 pkg to rebuild...but hey then you know everything is in harmony ;)
      - asveikau 6y ago
        Building both gcc and llvm from scratch (which somehow usually ends up happening) is probably more harmony than I need in my life.
        nix23 6y ago
        Both are faster build then chrome or Firefox ;)

asveikau 6y ago

I actually think there is nothing wrong with the upgrade process. What about pkg-style makes it better? On those other systems you still need a reboot for kernel changes to take effect.

Mister_Snuggles 6y ago
It's more the number of reboots and invocations of freebsd-update. Since these are all manual steps, you need to keep track of where you are and invoke the next step manually. The current process for upgrading FreeBSD is roughly, assuming that you're just using packages and not ports is: * freebsd-update upgrade * freebsd-update install * reboot * freebsd-update install * pkg upgrade * reboot * freebsd-update install * (optional) reboot In comparison, the process for upgrading OpenSuse Tumbleweed, assuming that you're just using packaged software, is: * zypper dup * reboot If the base system were managed by pkg, the FreeBSD version of the process should probably look a lot like the OpenSuse Tumbleweed version. Condensing upgrades down to a two-step process seems like it will be a significant quality-of-life improvement to me.
- asveikau 6y ago
  But if there are ABI breakages in base (say, a new syscall used in libc) you want to boot the new kernel with the old userland, then get the new userland later. At least, I have heard this explanation in the context of OpenBSD, and assume it may also apply to FreeBSD.
  - Mister_Snuggles 6y ago
    I believe that's the same in FreeBSD as well. I also think it's a solved problem in the Linux world - OpenSuse Tumbleweed sometimes rebuilds every package because they've changed libc. Apart from watching 2000+ packages get updated, there's really no impact when this happens. To solve this, the updater could create a new boot environment[0], install everything in that boot environment using as many passes as required, then reboot into that environment. OpenSuse already does a similar thing[1], though I don't know how well it works. [0] https://www.freebsd.org/cgi/man.cgi?beadm https://www.freebsd.org/cgi/man.cgi?beadm [1] https://news.opensuse.org/2018/05/15/transactional-updates-in-opensuse-leap-15/ https://news.opensuse.org/2018/05/15/transactional-updates-i...

bluGill 6y ago

While I mostly agree, you also hit the power of the freebsd system: you can do something different. In linux if you want PostgreSQL 12+PostGIS 3.0 with xml support and the packages deliver PostgreSQL 12+PostGIS 3.0 without xml you are stuck without xml support as the package systems don't make it easy for lay people to select options. With FreeBSD you get that power if you want it. It should be easier though.

dddddaviddddd 6y ago

I usually upgrade by recompiling the OS. Minor updates only take a few minutes to compile using filemon and the WITH_META_MODE=YES environment variable. The advantage is that it's easy to maintain out-of-tree patches to the source.

MrMorden 6y ago

I don't update Linux, FreeBSD, or any other OS in place except on my FreeBSD-CURRENT desktop. The only way to operate in production is to create a new VM from your template, apply the runbook/state/whatever, route everything to the new VM, and drain the old VM. My personal systems aren't where they should be for CM, but I still can't think of a good reason to update in place rather than rebuild and copy over configuration/data. Flavors should make it easier to operate with packages instead of ports, but I don't have any idea what's going on there. If I were supporting a large number of systems, I'd want FreeBSD over Linux any day of the week and twice on Sundays because the ports system doesn't make you choose between a stable OS branch and current software.