Delay in FreeBSD 14.0 release schedule

[BaronBS]

I have a Ryzen 7 5600 desktop with a fresh install of FREEBSD 14.0-BETA3 and I'm experiencing system freezes and random crash.
I made the update to RC1 still the system is unstable with no progress.
GUI is Plasma5-X11+ sddm.

Can you test it with XFCE, Plasma it is not very much stable on any hardware.

 

[tuxador]

Is it stable if you don't enable X?

when i disable sddm and run a session in a TTY, i had no noticeable bug. But i tried to test the uptime by keeping the computer on overnight (in my office) i found computer turned off, my guess is it crashed already.

 

[astyle]

when i disable sddm and run a session in a TTY, i had no noticeable bug. But i tried to test the uptime by keeping the computer on overnight (in my office) i found computer turned off, my guess is it crashed already.

Nah, I'm guessing someone turned the computer off by pushing the power button on the chassis. It's pretty rare (but not impossible) for a computer to crash so hard it loses power as well. If the power is cut, that can be the cause behind a crash, but usually not the other way around ?

 

[tuxador]

Nah, I'm guessing someone turned the computer off by pushing the power button on the chassis. It's pretty rare (but not impossible) for a computer to crash so hard it loses power as well. If the power is cut, that can be the cause behind a crash, but usually not the other way around ?

i am the unique person to have access to my computer, my office is a medical cabinet, not an IT company

 

[LibreQuest]

I have a Ryzen 7 5600 desktop with a fresh install of FREEBSD 14.0-BETA3 and I'm experiencing system freezes and random crash.
I made the update to RC1 still the system is unstable with no progress.
GUI is Plasma5-X11+ sddm.

What GPU are you using?

 

[bakul]

when i disable sddm and run a session in a TTY, i had no noticeable bug. But i tried to test the uptime by keeping the computer on overnight (in my office) i found computer turned off, my guess is it crashed already.

Does the "last" command report a crash? Could there be a temporary power failure? This sounds more of a power or hardware problem than software but you'd have to do some detective work to find out what is going on!

 

[tuxador]

What GPU are you using?

The integrated CEZANNE GPU. drm-kmod is installed with the correct RC configuration

 

[tuxador]

Does the "last" command report a crash? Could there be a temporary power failure? This sounds more of a power or hardware problem than software but you'd have to do some detective work to find out what is going on!

Didn't have much time to investigate, stuck to the old workstation (Intel i5 3*** CPU).

 

[Charlie_]

Revert "release: force PKGCONFBRANCH to use 'latest' to fix BETA1 builds"

 .endif
-PKGCONFBRANCH=    latest
 PKGCONF?=    FreeBSD.conf.${PKGCONFBRANCH}

release: force PKGCONFBRANCH to use 'latest' to fix BETA1 builds
We do not yet have a 'quarterly' build for amd64, i386, or non-x86,
so use 'latest' in order to get the BETA1 builds to work.

 

[Johannkokos]

Just did `pkg upgrade` and blindly answered yes without looking at the text. It ended up removing `firefox` package.

Installed packages to be REMOVED: firefox: 118.0,2 Installed packages to be UPGRADED: dav1d: 1.2.1_1 -> 1.3.0

Iuckily I can still install the old versions in the cache.

 

[astyle]

Just did `pkg upgrade` and blindly answered yes without looking at the text. It ended up removing `firefox` package.

Installed packages to be REMOVED: firefox: 118.0,2 Installed packages to be UPGRADED: dav1d: 1.2.1_1 -> 1.3.0

Iuckily I can still install the old versions in the cache.

This is why I don't like pkg, and go with ports. Upgrading ports (even with poudriere and git) is still something I'm in the process of ironing out. The nice thing about ports is that you can just replace the folder /usr/ports/www/firefox/ with a fresh copy (one containing the Makefile/distinfo for, say, v. 119), and compile it against the existing stuff. I'm trying to pull that off with KDE, though.

 

[mer]

pkg is a good tool, works exactly as needed. But there is a bit of user attention needed sometimes. If you do not add "-y" the user needs to actively acknowledge "yes do this".
But the way commercial software has gotten over the past years, most automatically hit "y" without even reading the text. It's not good or bad, it just is.
My solution has been to run "pkg upgrade -n" every 2 or 4 weeks and actually read the output, paying attention to the "packages to be removed" bits.

If one has a desire to use non-default options or simply needed more control, then ports is the correct answer if you have the resources.

Above is simply my opinion.

 

[cracauer@]

pkg is a good tool, works exactly as needed. But there is a bit of user attention needed sometimes. If you do not add "-y" the user needs to actively acknowledge "yes do this".
But the way commercial software has gotten over the past years, most automatically hit "y" without even reading the text. It's not good or bad, it just is.
My solution has been to run "pkg upgrade -n" every 2 or 4 weeks and actually read the output, paying attention to the "packages to be removed" bits.

If one has a desire to use non-default options or simply needed more control, then ports is the correct answer if you have the resources.

Above is simply my opinion.

Well, the problems remain:

1) you miss out on security updates that way

2) you can't script/crontab that workflow to automate updates

 

[mer]

Yep, I'm aware of what I'm missing, but I also pay attention to a few different email lists

 

[tuxador]

Just did `pkg upgrade` and blindly answered yes without looking at the text. It ended up removing `firefox` package.

Installed packages to be REMOVED: firefox: 118.0,2 Installed packages to be UPGRADED: dav1d: 1.2.1_1 -> 1.3.0

Iuckily I can still install the old versions in the cache.

Not only Firefox, but chromium and falkon are not available in the repos.
Luckily Linux-browser-installer allowed me to install Linux/chrome (although brave failed to install)

 

[Charlie_]

update releng/14.0 to -RELEASE

+20231114:
+ FreeBSD 14.0-RELEASE.
+

REVISION="14.0"
-BRANCH="RC4-p1"
+BRANCH="RELEASE"

 

[Cath O'Deray]

14.0: update to reflect 14.0-RELEASE builds started on time · freebsd/freebsd-doc@f70f68b

Sponsored by: GoFundMe https://www.gofundme.com/f/gjbbsd Sponsored by: PayPal https://paypal.me/gjbbsd

github.com

Please show your thanks to Glen by donating:

Sponsored by: GoFundMe https://www.gofundme.com/f/gjbbsd
Sponsored by: PayPal https://paypal.me/gjbbsd

Note, the release is not yet announced. In particular:

• I should discourage upgrades in the absence of installation information.

FreeBSD 14.0 Release Information

FreeBSD is an operating system used to power modern servers, desktops, and embedded platforms.

www.freebsd.org

 

[Charlie_]

This is the change from RC4-p1 to RELEASE.
executables in ZFS VM images have permission issues

14.0-RELEASE metabug
depends on 10 open bugs:

 

[Cath O'Deray]

…

14.0-RELEASE metabug
depends on 10 open bugs:

In Discord, a member of the FreeBSD Core Team noted:

a number of the dependencies of the 14.0 meta bug can be addressed as post-release errata updates; the most important to have fixed are issues that prevent the installer from working at all on various hardware, or that will leave a broken installation behind

 

[marstr]

In Discord, a member of the FreeBSD Core Team noted: here

I completely agree with this statement. It is important that the FreeBSD installer works on a wide range of hardware and that the installation is successful in most cases.

 

[Kai Burghardt]

[…] I think the better question to ask is why some people are being so annoyed about the delay of the 14.0 release. I'd rather have this delayed by another year than doing what most other players in the software industry do and rush something just because it needs to be released. […]

An IT systems administrator working for a company or other institution (e. g. in education or for a NGO) wants to schedule upgrades (e. g. time for possibly dealing with technical issues) and announce downtime to the users. For me at home a delay does not bother me at all, but a business may be less flexible about this. One may argue you get an excellent open-source OS for free, so stop complaining, but it marginally undermines perceived credibility if deadlines are not met. ?​

 

[sko]

An IT systems administrator working for a company or other institution (e. g. in education or for a NGO) wants to schedule upgrades (e. g. time for possibly dealing with technical issues) and announce downtime to the users. For me at home a delay does not bother me at all, but a business may be less flexible about this. One may argue you get an excellent open-source OS for free, so stop complaining, but it marginally undermines perceived credibility if deadlines are not met. ?​

I *am* such an systems administrator for a company. And *the hell* I would schedule upgrades of critical systems either based on some *expected* (it actually says so on the release schedule page!) RELEASE-date and in general never directly after a new major release.

The first systems a new major RELEASE will go on, are e.g. my private desktop or the laptop that isn't terribly critical for me getting work done.
If the 14.x branch has prooven to have worked out the usual small glitches and regressions a new major release often brings with it (this time especially true regarding OpenSSL3), I *may* upgrade my home server and see how it holds up there.
Only then I'd consider moving any production system to a new branch - and only if it brings some real advantages in production. Otherwise: never touch a running system. I have plenty of fires to put out on non-BSD systems every day. The FreeBSD systems are happily chugging along on 13.2-RELEASE and will continue to do so, so why open a new can of worms (unnecessarily)?
The next major upgrades I have to schedule are the remaining 2 hosts running 12.4-RELEASE which will be upgraded to 13.2-RELEASE - and both will be replaced by new systems anyways, so no need to rush there either.

I thoroughly support the statements about releasing *when it's finished*. We all can constantly see what's happening with commercial software (e.g. "triple-A" games) that gets released when the managers and bean-counters dictate it should be, completely ignoring the warnings of everybody who actually *works* on that software.
I consider the FreeBSD developers and release engineers to be sane and competent professionals, which don't have to bow before any PHB. So they will do the only correct thing and release when it is done, not on some artifical deadline.

 

[Cath O'Deray]

Upgrades aside,

… I consider the FreeBSD developers and release engineers to be sane and competent professionals, …

+1

Echoing a privately expressed opinion:

• FreeBSD 14.0-RELEASE will be recommended for new deployments.

 

[astyle]

I *am* such an systems administrator for a company. And *the hell* I would schedule upgrades of critical systems either based on some *expected* (it actually says so on the release schedule page!) RELEASE-date and in general never directly after a new major release.

I work at a big place myself, and while I'm on the sidelines there, I get to watch how the mission-critical UNIX/Linux systems don't get updated at all, and run software way past its EOL - can't run the risk of updates breaking that critical system. The only viable path to updates, it seems, is to re-create the system from scratch, using up-to-date software, validate it, and THEN replace the outdated machine. And nobody has the time or real expertise to do THAT.

 

[Cath O'Deray]

… mission-critical UNIX/Linux systems don't get updated …

Including (UNIX-like) FreeBSD systems? (If you're allowed to say.)