FreeBSD 12.2-BETA1 | Hacker News Reader

FreeBSD 12.2-BETA1

lists.freebsd.org

70 pointsvermaden53 comments

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

[1] https://www.freshports.org/databases/postgis30/

[2] https://build.opensuse.org/project/show/Application:Geo

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

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.

>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.

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.

>I feel poudriere takes too much time and disk space building literally everything.

No not really just your packages and the dependencies of those.

Ok, slight exaggeration. The dependencies get quite huge though, especially when you are using something substantial.

Yeah that's true, having 1400 pkg installed needs often ~300 pkg to rebuild...but hey then you know everything is in harmony ;)

Building both gcc and llvm from scratch (which somehow usually ends up happening) is probably more harmony than I need in my life.

Both are faster build then chrome or Firefox ;)

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.

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.

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.

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

[1] https://news.opensuse.org/2018/05/15/transactional-updates-i...

The situation on linux is actually different because the kernel and glibc are maintained separately and the syscall ABI is treated as a boundary between components.

Any time a new syscall is wrapped the userland maintainers need to account for what happens when run on an old kernel and typically have some fallback logic.

Sounds like a great yak-shaving opportunity, to write a script that automates it

Which everyone does, if one has more then 2 machines ;)

I absolutely agree. I run FreeBSD on my NAS to take advantage of ZFS but every time I update it I have to Google the process or find my notes since it's incredibly non-intuitive.

I have a detailed set of instructions to follow when I'm upgrading my home server, plus notes from each time I've upgraded it.

At this point, I've only got two services (postgresql and mosquitto) which run on bare metal, everything else is in VMs. Once I move those off of FreeBSD the upgrade process will be greatly simplified (well, as simplified as FreeBSD gets anyway).

freebsd-update prints out what you need to do next at each step though. If it wants you to reboot and run it again it says that.

Or you just read the printout until it says fetch first ;)

I think there's value to having base separate from pkg, too. The way we ran FreeBSD at the two companies I worked where it was used heavily was to manage base and other things separately.

For base updates, we'd usually shut down services, install kernel and userland, and reboot --- I know this isn't the proper order, but most of the time the new userland is compatible enough to reboot (and you can usually power cycle if that doesn't work out). For updates where rebooting would be hard this way, we'd do it the right way, but then you need to add an extra reboot after installing userland, or restart all the services from base. If needed, we'd install the compat packages after the reboot. We would not update ports/pkg/etc at the same time; old binaries are expected to continue to work on a new system (and generally do). In house binaries are either compiled on the system they run, or centrally on a machine (or chroot/jail) running the oldest release on the fleet.

Generally,

When you need to upgrade software not from base, because of security updates or new features or ennui, you do that isolated from base changes. The only complication here is if you haven't updated base recently enough, pkg may provide binaries you can't run, and ports may provide software you can't compile (this one takes longer).

We would generally only update base for exceptional releases, or when it became hard to update non-base software on older releases. However, new machine installs would get the most recent release we had tested.

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.

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.

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.

Really looking forward to tinkering with this. Is it me, or does it seem that the BSDs are really losing more and more mind share as time marches on? I have very few issues with FreeBSD or OpenBSD beyond the occasional incompatibility, and it's always something minor like suspend or sound that can fixed with a few queries.

>Is it me, or does it seem that the BSDs are really losing more and more mind share as time marches on

Well BSD is dying was said already 15 years ago, BUT the project should be more responsive, an example:

You send in a patch with a updated port, and you wait 3 month until it's in the tree, in the meantime already a new version is out. I think if the users make the work and send in patches (just with a changed version-number and zero or nearly zero dependencies) some porters @ freebsd should act much quicker (some are super fast and helpfull but not as many), otherwise they will change the os or make there own fork of the package tree like i do.

I do agree that the BSD ports maintainers are a fair bit slower than their Linux counterparts. Having said this, though, I do admire the way the port maintainers train up their replacements and/or add others with commit access. They mentor them. This does lead to higher code quality in the end. I fully agree with the notion that BSD is engineered whilst Linux is "grown". Good and bad to both approaches.

>I do admire the way the port maintainers train up their replacements and/or add others with commit access

Yes absolutely, and it's no question that packaging is really hard work, i wanna thank everyone that works on my most beloved system, ESPECIALLY the packagers.

I started using FreeBSD on a VPS a couple months ago, and I've moved my home router to be FreeBSD -- PF is /so much better/ than anything else wrt understandability, and putting miscellaneous services the router runs in jails is pretty nice, and feels simpler to set up "right" than the same with Docker (e.g. no messing around with Docker volumes, only to discover you've accidentally deleted years of family photos).

It's good stuff, but I would also suggest tinkering with OpenBSD and its offerings. A bit simpler, but still fun. It's all good stuff and fun to play with.

> you've accidentally deleted years of family photos

Oof, that hurts.

I'm going to add a check right now to PhotoStructure to assert that people's library is not stored within the container to prevent this from happening to my users.

It unfortunately does. And it's a vicious circle.

Linux has the most mindshare, so most things are built for Linux and don't run (or don't run as well) on FreeBSD. As a result, more people use Linux resulting in increased mindshare, and the process repeats.

It makes me sad because I really like FreeBSD.

I love FreeBSD much more than Linux, and i wish i could use it instead of Linux on my desktop/notebook machines.

But the graphics have to play a catch up game with Linux, and in my experience a couple of drivers were missing or not working properly (like wireless stuff, acpi, etc..)

The performance of the network stack is the best of any OS, and the interface with the OS in general is much more well designed than Linux, giving Linux is more of a Bazar effort with things stitched here and there to make some things works.

It's sad that the amount of man-hours on Linux, make it almost unavoidable and i bet this will be more and more true with time even with Windows and OS X.

As a Linux user, the existence of open-spec boards that I know are supported by it (and a variety of other OSes) actually puts the BSDs more on my radar than they would be otherwise.

You can see the schedule for the release on this page: https://www.freebsd.org/releases/12.2R/schedule.html

Does mount_smbfs support SMB2 at last?

Yes with the latest Sambaserver you have everything Linux has.

As someone who has been using FreeBSD for a long time on various machines of mine, both physical machines in my home and VMs in the cloud, I'm wondering how many people (both in absolute numbers and in percentages) run the beta releases on their hardware.

My general impression, which stems mostly from the description I once read on the FreeBSD downloads page and from elsewhere is that if you want to help find bugs in upcoming releases you run the CURRENT branch and else you run RELEASE. But I expect that there are people running the beta releases as well who make meaningful bug reports that result in fixes prior to release versions being minted – otherwise I think they would not be making beta releases still.

I did used to run CURRENT for a while, but eventually found out that personally I wasn't making any particularly helpful bug reports based on it anyways so I went back to RELEASE.

For the VM server that I have been using for many years now for sending and receiving mail, as well as to host some websites of mine, running FreeBSD RELEASE has been working great for years.

Meanwhile, my desktop computer which is currently running FreeBSD 12.1-RELEASE is having issues where it freezes and requires a hard reboot. But I had this same kind of issue when I was running various Linux distros on this same desktop computer over the past years. I am suspecting that either it is a cause of hardware malfunction or possibly of the Nvidia driver for the graphics card, but I don't really have any way of finding out what the actual problem is. Not the least because of the fact that it will often run for a week of being powered on perfectly fine (both with FreeBSD and Linux distros) until suddenly it just completely freezes. Doesn't react to mouse, doesn't react to keyboard, doesn't respond to ping.

The fact that my desktop computer can run fine for about a week at a time makes it hard to figure out what the actual problem is. Say that I were to pull the graphics card out for example, and it ran fine for two weeks. How do I know at that point that I can really blame the graphics card and it wasn't just random chance that made it run for longer than usual this time around?

I think in order to isolate the problem I would have to build like 8 different physical machines all with the same hardware, and then say ok four of the machines I will initially run like I do with my current desktop, and four of them I will pull the graphics card out of and then have them running 24x7 for a month or until at least two of the machines with Nvidia graphics cards crashed if sooner. At that point I might conclusively say there is strong evidence of problems with the Nvidia graphics cards or with the drivers for said cards.

But if the machines without the Nvidia graphics cards were also crashing then I'd need to swap out for example all of the motherboards and I'd run the experiment for another week. An so on.

On the flip-side, if all of them ran fine for a month with the initial configuration I would conclude that probably some of the hardware in my current machine is just broken, and that there is no bigger issue at play. But all of that would cost not just a lot of time but also a lot of money. And as-is the next thing I can afford to buy is certainly not such an amount of hardware – the next thing I am going to buy when I can afford it is rather a couple of new hard-drives, as the spinning disks that hold most of my data are getting a few years old and I am getting quite nervous about them suddenly going to fail me. I've had hard-disks fail on me in the past. In particular I used to have a machine with 4x 2TB hard-drives in it to provide me with ZFS storage, and then I moved houses and I accidentally dropped my computer from about 1 meter height and last time I tried to see if the drives were working none of them showed up neither after boot nor in BIOS, neither in the original computer that I had dropped nor in the desktop computer that I have now. Well anyways it don't matter too much, none of the data was that important really. And I think said drives were making unusual noises also but I don't quite remember as it was a while ago now. But that kind of experience, along with having had some external hard-drives fail me in the past, does feed into the worry that I have for my current hard-drive as it is getting a few years old now.

But back to what I was saying about trying to debug the issue with my desktop. In theory I could disconnect basically all but the RAM and the CPU from the motherboard (well, and but the fans of course :P) and boot a minimal kernel from a USB stick and have it run in RAM and let it stay powered on for four weeks and see if it crashed, and then if it doesn't to connect the SSD and the HDD to it and run it for another four weeks and see if it crashes, and then to run the regular RELEASE kernel on it for four weeks and see what happens, and after that with the graphics card connected and see what happens for the next four weeks. But all of those weeks man. I just want my desktop to work, I don't want to spend weeks with it running on its own without being available for my use.

Anyways, that brings me to something else related to the testing that people do and that is the fact that I find it kind of hard to know what hardware to pick for a FreeBSD desktop. There's things like https://www.freebsd.org/releases/12.1R/hardware.html and https://wiki.freebsd.org/Graphics and https://wiki.freebsd.org/Graphics/AMD-GPU-Matrix but they all seem kind of out of date.

If I had the money to buy the hardware for it and to pay the electric bills for it I would gladly be running a bunch of machines in different configurations of current consumer hardware and making notes and filing bug reports and hardware compatibility reports to help other users of FreeBSD and Linux. Maybe someday. Until that day I'll just have to accept that every week or so I might have to hit that hard reset button on my desktop, inconvenient as it might be.

>Until that day I'll just have to accept that every week or so I might have to hit that hard reset button on my desktop

That really must be your Hardware, i have FB12.1-REL and it's rockstable on 5 different Machines from 10yo to 1 two laptops and three Workstations.

And many many VM's and two really big physical servers

A few thoughts that I have about my hardware are:

- I wonder how many other people use Nvidia graphics cards on FreeBSD and on Linux.

- A few years ago I used to mine crypto on my graphics card. I made like $20 from it, so if the graphics card is physically in bad shape and this is what caused it then gg on my part for ruining a ~$390 graphics card in order to make about $20.

- The PSU is probably the oldest component in my computer. In fact I think the store I bought it from has been shut down for many years even; that's how old that PSU is. Could it be supplying my computer with bad quality power? Maybe.

- My RAM is of the non-ECC variant. Could cosmic rays be to blame for the crashes? ¯\_(ツ)_/¯ The BOFH would certainly have said that this was the reason, but even in the real world it could be maybe?

> Nvidia graphics cards on FreeBSD

Many it's official supported

>A few years ago I used to mine crypto on my graphics card

Mining does not damage your card

>My RAM is of the non-ECC variant.

Make a extensive memory check like memcheck+

>The PSU is probably the oldest component in my computer.

Here i would bet is your problem, if the ram is ok, no CAP has a bubble and your computer is dust free then it's to 80% your PSU

A'ight thank you, I will try a memcheck and if the memcheck looks ok I will save up money for a new PSU.

If you have a Friend that is good in electronic he can have a look into your PSU...they have Capacitors too (bulging), but the PSU is really NOT a playground..you don't want to light your house on fire.

> no CAP has a bubble

could you please tell me what that means ? I googled "CAP bubble computer" and the results were unrelated.

They were referring to if there was any bulging on any of the capacitors on any of the components in the computer.

ah thanks I wasn't sure what CAP meant now it's all clear.

Looks like that:

https://www.soundonsound.com/sound-advice/pc-notes-16

>>A few years ago I used to mine crypto on my graphics card

> Mining does not damage your card

Mining certainly does not damage the card, however i'd check the cooling. Overheating might be a problem, and mining means that the card is working at 100% of its capabilities for long times (instead of the usual/occasional gaming session).

You are referring to the 'capacitor plague' as Wikipedia calls it?

Can happen to any capacitor when it's over his lifetime at a certain temperature, but at the capacitor plague time they died much before the expected lifetime.

heres hoping we get ASLR in this release? :)

Well they have ASR, if you want ASLR and much more you probably want to use

https://hardenedbsd.org/content/easy-feature-comparison

Reply on news.ycombinator.com