Living on the edge

rbranco

rbranco

I'm using -CURRENT on a VM where I can do snapshots in case something breaks, etc.

I want to know the experience of people using -CURRENT for serious workloads.

Why do you use CURRENT?

How many times it broke?

Do ZFS snapshots help in this case? Which other tools and processes you use to make sure nothing breaks?
 
It allows you to look into the future. That also includes new hardware drivers. Here is a list of things from Netflix. It's not my case. Sorry for going off track.

itsfoss.com

Enjoy Netflix? You Should Thank FreeBSD

Netflix is one of the most popular streaming services in the world. But you already know that. Don’t you? What you probably did not know is that Netflix uses FreeBSD to deliver its content to you. Yes, that’s right. Netflix relies on FreeBSD to build its in-house content
itsfoss.com itsfoss.com
Here are the benefits Netflix sees of tracking FreeBSD:
  • Quicker feature iteration
  • Quicker access to new FreeBSD features
  • Quicker bug fixes
  • Enables collaboration
  • Minimizes merge conflicts
  • Amortizes merge “cost”
Click to expand...
 
I always run -current. Occasionally you have to repair X11 (DRM module or whatever). I like to see unwanted changes as soon as possible. Keep in mind it isn't my main desktop.

The last time I had to roll back a FreeBSD install was a botched 14-release update from source. The last heavy bug I got scared of was the ZFS corruption bug which made it into all stable versions of FreeBSD, Solaris and Linux.

The biggest drawback of running -current is frequent ABI changes, which means you can no longer install new packages until you do a `make world`. Which recommends a reboot.
 
<https://forums.freebsd.org/search/361791/?c[users]=rbranco&o=date> for me to gauge where you're coming from.

I think of FreeBSD-CURRENT as leading edge (not bleeding edge).

Yesterday:

grahamperrin said:
If you make good use of ZFS boot environments, you should have no fear.

A few hours ago in Discord we walked someone through upgrading from 14.0-RELEASE to 15.0-CURRENT. Partly with reference to the wiki, which currently focuses on RELEASE, so some variation was required (plus, we noticed some gaps).
Click to expand...

Production use, for me. CURRENT has been my everyday system (daily driver), on notebooks, for at least eight years. From my profile here:

… switched from OS X 10.9.5 Mavericks to PC-BSD. Then TrueOS, then FreeBSD-CURRENT with KDE Plasma. …
Click to expand...

Context: <https://en.wikipedia.org/wiki/TrueOS#Release_history>, where TrueOS used FreeBSD-CURRENT from the outset. (I did use PC-BSD long before the transition, so I probably used 9.2-CURRENT for a while.)

rbranco said:
… How many times it broke? …
Click to expand...

For me, it's fair to say never. A Startpage search of a freebsd-current archive finds just one post from me, part of a July 2023 thread:
(Off-topic: there may be something wrong with Google's index of FreeBSD's archives. This does not alter the essence of how I feel about CURRENT breaking.)

I have encountered issues whilst using CURRENT, however it's very rare for me to find an issue with CURRENT itself.

I can't recall anything other than occasional build failures. Build failures can be a thing of the past – since pkgbase allows the operating system, and packages of ports, to be updated with ease:

pkg upgrade
 
Last edited:
I had a machine hang on 15-current yesterday when playing with segfault handlers (userland). Might have been a panic, but X11 was up so I wouldn't know. Can't reproduce.
 
rbranco said:
I'm using -CURRENT on a VM where I can do snapshots in case something breaks, etc.

I want to know the experience of people using -CURRENT for serious workloads.

Why do you use CURRENT?

How many times it broke?

Do ZFS snapshots help in this case? Which other tools and processes you use to make sure nothing breaks?
Click to expand...
I'm running a mix of 13.2 and 14. No CURRENT. Too chicken.
 
cracauer@ said:
… The biggest drawback of running -current is frequent ABI changes, which means you can no longer install new packages until you do a `make world`. …
Click to expand...

I never found installation impossible.

cracauer@ said:
Intel DRM kernel modules from packages also don't load today.
Click to expand...

Which version?

uname -aKU

x11/nvidia-driver-470 here, so I'm quite complacent about kernel modules in ports. Following a pkgbase update to CURRENT:

Code: 
root@mowa219-gjp4-zbook-freebsd:~ # uname -aKU
FreeBSD mowa219-gjp4-zbook-freebsd 15.0-CURRENT FreeBSD 15.0-CURRENT main-n268036-d682c1eaa598 GENERIC-NODEBUG amd64 1500012
 1500012
root@mowa219-gjp4-zbook-freebsd:~ #
 
cracauer@ said:
… Might have been a panic, but X11 was up so I wouldn't know. …
Click to expand...

I have preferences set for an automated restart, so if a long panic occurs with X11 frozen, waiting long enough will lead to a relatively short dump and then files in /var/crash following the restart.
 
Three pkgbase updates to base over the weekend, the first of which led to long panics. Most noticeable, consistently, very soon after Plasma appeared with restored windows (photograph attached). Nothing obviously relevant on the freebsd-current list for the period <https://mail-archive.freebsd.org/cg...2024/freebsd-current/20240212.freebsd-current>.

Soon enough, I found an almost entirely reliable workaround, continued using the bugged builds for the rest of the weekend. After creation of a thread in Discord, bsdimp there dropped a hint about reviews in Phabricator.

Back to work today, so (for peace of mind) I'm simply using the boot environment that preceded 62d47d73b7eb.

From Discord:

<https://cgit.freebsd.org/src/log/?qt=range&q=eb86c6c5b462..5f7ac491eef4>

Code: 
root@mowa219-gjp4-zbook-freebsd:~ # bectl list -c creation | tail -n 10
n267824-0dd5a5603e7a-b -      -              530M  2024-01-31 09:25
n267824-0dd5a5603e7a-c -      -              409M  2024-02-04 19:48
1500012-a              -      /tmp/1500012-a 50.1M 2024-02-06 09:32
1500012-b              -      /tmp/1500012-b 122M  2024-02-06 22:31
1500012-c              -      /tmp/1500012-c 2.27G 2024-02-08 01:07
1500013-a              -      /tmp/1500013-a 2.25G 2024-02-08 23:31
1500013-b              NR     /              242G  2024-02-10 07:44
1500013-c              -      /tmp/1500013-c 1.78G 2024-02-10 14:11
1500013-d              -      /tmp/1500013-d 1.97G 2024-02-11 04:59
1500013-e              -      /tmp/1500013-e 5.15G 2024-02-11 13:29
root@mowa219-gjp4-zbook-freebsd:~ # strings /tmp/1500012-a/boot/kernel/kernel | egrep ^FreeBSD\ 15.0
FreeBSD 15.0-CURRENT main-n268036-d682c1eaa598 GENERIC
root@mowa219-gjp4-zbook-freebsd:~ # strings /tmp/1500012-a/usr/include/sys/param.h | grep 15000
#define __FreeBSD_version 1500012
root@mowa219-gjp4-zbook-freebsd:~ # strings /tmp/1500012-b/boot/kernel/kernel | egrep ^FreeBSD\ 15.0
FreeBSD 15.0-CURRENT main-n268036-d682c1eaa598 GENERIC
root@mowa219-gjp4-zbook-freebsd:~ # strings /tmp/1500012-b/usr/include/sys/param.h | grep 15000
#define __FreeBSD_version 1500012
root@mowa219-gjp4-zbook-freebsd:~ # strings /tmp/1500012-c/boot/kernel/kernel | egrep ^FreeBSD\ 15.0
FreeBSD 15.0-CURRENT main-n268079-e4ab361e5394 GENERIC
root@mowa219-gjp4-zbook-freebsd:~ # strings /tmp/1500012-c/usr/include/sys/param.h | grep 15000
#define __FreeBSD_version 1500012
root@mowa219-gjp4-zbook-freebsd:~ # strings /tmp/1500013-a/boot/kernel/kernel | egrep ^FreeBSD\ 15.0
FreeBSD 15.0-CURRENT main-n268104-d04abb05375d GENERIC
root@mowa219-gjp4-zbook-freebsd:~ # strings /tmp/1500013-a/usr/include/sys/param.h | grep 15000
#define __FreeBSD_version 1500013
root@mowa219-gjp4-zbook-freebsd:~ # strings /boot/kernel/kernel | egrep ^FreeBSD\ 15.0
FreeBSD 15.0-CURRENT main-n268149-eb86c6c5b462 GENERIC
root@mowa219-gjp4-zbook-freebsd:~ # strings /usr/include/sys/param.h | grep 15000
#define __FreeBSD_version 1500013
root@mowa219-gjp4-zbook-freebsd:~ # uname -aKU
FreeBSD mowa219-gjp4-zbook-freebsd 15.0-CURRENT FreeBSD 15.0-CURRENT main-n268149-eb86c6c5b462 GENERIC amd64 1500013 1500013
root@mowa219-gjp4-zbook-freebsd:~ # strings /tmp/1500013-c/boot/kernel/kernel | egrep ^FreeBSD\ 15.0
FreeBSD 15.0-CURRENT main-n268154-62d47d73b7eb GENERIC
root@mowa219-gjp4-zbook-freebsd:~ # strings /tmp/1500013-d/boot/kernel/kernel | egrep ^FreeBSD\ 15.0
FreeBSD 15.0-CURRENT main-n268164-c0b8047bdc13 GENERIC
root@mowa219-gjp4-zbook-freebsd:~ # strings /tmp/1500013-e/boot/kernel/kernel | egrep ^FreeBSD\ 15.0
FreeBSD 15.0-CURRENT main-n268174-5f7ac491eef4 GENERIC
root@mowa219-gjp4-zbook-freebsd:~ # bectl umount 1500012-a && bectl umount 1500012-b && bectl umount 1500012-c && bectl umount 1500013-a
root@mowa219-gjp4-zbook-freebsd:~ # bectl umount 1500013-c && bectl umount 1500013-d && bectl umount 1500013-e
root@mowa219-gjp4-zbook-freebsd:~ # bectl list -c creation | tail -n 10
n267824-0dd5a5603e7a-b -      -          530M  2024-01-31 09:25
n267824-0dd5a5603e7a-c -      -          409M  2024-02-04 19:48
1500012-a              -      -          50.1M 2024-02-06 09:32
1500012-b              -      -          122M  2024-02-06 22:31
1500012-c              -      -          2.27G 2024-02-08 01:07
1500013-a              -      -          2.25G 2024-02-08 23:31
1500013-b              NR     /          242G  2024-02-10 07:44
1500013-c              -      -          1.78G 2024-02-10 14:11
1500013-d              -      -          1.97G 2024-02-11 04:59
1500013-e              -      -          5.15G 2024-02-11 13:29
root@mowa219-gjp4-zbook-freebsd:~ #
 

Attachments

  • 1707724805595.png
    1707724805595.png
    1.4 MB · Views: 72

FreeBSD CURRENT stabilization cycle​

… In the last decade quality of FreeBSD CURRENT improved so much, that not only brave developers run it on their laptops, but also large companies use it. Time to bring it to a new level. Every individual or a business that use CURRENT has their own protocol of how to stay up date and avoid disasters. An individual will first update their desktop and only after that will update server(s). A company would run their internal regression test suite or some other validation protocol. Right now we all do that independently from each other having little coordination and providing little help each other. We also do not broadcast to the world that FreeBSD CURRENT is usable. I've seen a lot of people who stay away from CURRENT based on their 20-year old experience with it. …
— glebius@, 2024-02-24
also archived (with clickable links) at <https://mail-archive.freebsd.org/cgi/mid.cgi?ZdlxdKMCfwNq2mVr>​

Related:

forums.freebsd.org

Please create a -current forum

Looks like folks would like to have a place to discuss experiences with the -current branch. Better here than on Reddit. kpedersen convinced me that this is a bad idea here: https://forums.FreeBSD.org/threads/please-create-a-current-forum.79595/post-503475
forums.freebsd.org forums.freebsd.org
 
Attached: a transcript of an upgrade from 1500014 to 1500015 – using pkgbase.

NB: repository names are not base and FreeBSD. Both names are too vague.

In retrospect, the bfs commands – seeking .pkgsave files – were probably unnecessary. See the comment from bapt@ at <https://lists.freebsd.org/archives/freebsd-pkgbase/2024-March/000336.html>.

Re: the long list of boot environments, I previously used letters of the alphabet (in names of environments) to help signify order. Now, instead, I'm using numbers:
  • 1500015-01-base represents my first ugprade to base that resulted in version 1500015 of the OS.
A condensed list of commands from the transcript:
  1. pkg update -r FreeBSD-base && pkg update -r FreeBSD-ports ; date
  2. bectl list -c creation
  3. bectl create 1500015-01-base
  4. bectl mount 1500015-01-base /tmp/up
  5. time pkg -r /tmp/up upgrade --yes --quiet --repository FreeBSD-base --fetch-only
  6. time pkg -r /tmp/up upgrade --yes --quiet --repository FreeBSD-base --no-repo-update && grep pkg /var/log/messages | tail -n 1
  7. grep 20758 /var/log/messages
  8. cp /tmp/up/boot/loader.efi /boot/efi/efi/freebsd/loader.efi
  9. du -hs /tmp/up/var/cache/pkg
  10. pkg -r /tmp/up clean -a --quiet --yes && pkg -r /tmp/up autoremove
  11. pkg update -r FreeBSD-base && pkg update -r FreeBSD-ports ; date
  12. history -S
  13. cp /root/.history /tmp/up/root/.history
  14. bectl umount 1500015-01-base
  15. bectl activate 1500015-01-base ; exit
 

Attachments

  • 1710390781604.png
    1710390781604.png
    43.2 KB · Views: 26
  • 1500015-01-base.txt
    38.6 KB · Views: 30
rbranco said:
I'm using -CURRENT on a VM where I can do snapshots in case something breaks, etc.

I want to know the experience of people using -CURRENT for serious workloads.

Why do you use CURRENT?

How many times it broke?

Do ZFS snapshots help in this case? Which other tools and processes you use to make sure nothing breaks?
Click to expand...
I'm running 15-CURRENT in a VBox VM on a 13.2-RELEASE host... My reason for that - I'm trying to compile my way into a KDE6 desktop. Nothing broke so far, but I should probably give the VM more than 8 GB of RAM (host has 40 GB). And the VM does have a serious workload - I already have failed rust and gcc compilations where I had to step in and install packages from latest for those failed compilations. Those failed compilations ran overnight, too.

Playing with ZFS snapshots is probably next on the agenda for that VM.
 
grahamperrin said:
Thanks,



How do your options differ from what's already available as packages?

(In a nutshell.)
Click to expand...
Well, in a nutshell, I try to turn on EVERYTHING in a port when I compile it. Packages usually come with a pretty conservative set of options turned on. For example, I turn on all of the audio options available (SNDIO, Pipewire, PulseAudio, JACK, and ALSA...), because they compile no problem, and it's a way to avoid weird lack of sound later on. I also turn on LTO, and turn off the EXAMPLES options.
 
rbranco said:
Why do you use CURRENT?
Click to expand...
I did use 11-CURRENT for testing on my desktop and notebook, because 10-RELEASE missed GPU drivers.

Since 11-RELEASE, I only use -CURRENT in VMs dedicated to testing ports with poudriere (with jails for -CURRENT and all currently supported -RELEASE versions). Ports explicitly support -CURRENT, so you can't skip testing with it for serious work on ports.

rbranco said:
How many times it broke?
Click to expand...
11-CURRENT kernel-panicked a few times for me ...

None of my port testing VMs ever had issues so far (except for the expectable occassional ABI-breakage like when base OpenSSL was upgraded to 3.x, which is easily fixable by rebuilding some ports locally).
 
You must log in or register to reply here.
Back
Top