Delay in FreeBSD 14.0 release schedule

morbit said:
That would be the same as git clone -b main --depth 1? I've read somewhere that if you would include portsnap database disk usage to the downloaded ports tree, total disk space allocation is similar to the git repo.
Click to expand...
Yes, as --depth 1 implies --single-branch (numerous ways to get the same result. Since main is the default branch, git clone --depth 1 […] should achieve the same ends.
 
sidetone said:
It's easy to adjust the packages to latest, but it's something we had to learn and have to remember to do.
Click to expand...
... and it may also be something we don't want to do. On machines other than my main desktop computer, I usually prefer using quarterly.
 
Trying an upgrade here, first time using wifi albeit an old laptop, 13.2 -> 14.0-BETA1

Expecting great things!

24860....24870....24880....24890....24900....24910....24920....24930....24940....24950....24960....24970....24980....24990....25000....25010....25020....25030....25040....25050....25060....25070....25080....25090....25100....25110....25120....25130....25140....25150....25160....25170....25180....25190....25200....25210....25220....25230....25240....25250....25260....25270....25280....25290....25300....25310....25320....25330....25340....25350....25360....25370....25380....25390....25400....25410....25420....2543
 
Laptop has been updated from ALPHA-3 to latest releng/14.0 via source yesterday and poudriere is currently rebuilding ports.

So far with BETAALPHA3 I haven't been able to get i915kms running. Even upgrading graphics/drm-515-kmod to the 5.15.118 tag (=lts branch), which should include all fixes to fully support alder lake didn't yield any results. When loading the i915kms module, the system completely locks up and needs a hard reset. No log entries and no crashdump are created, so I still have no idea where to start or what else to add to the PR.
At least the graphics/gpu-firmware-intel-kmod@alderlake module was able to load on ALPHA3 without a kernel panic (which produced a proper crashdump).
 
Upgraded my 14-ALPHA1 TO 14.0-BETA1. I've been having to build the port of drm-515-kmod to get it to work with my AMD 6750XT, as the prebuilt one seems to always fail on me. I think I've been having hard lockups of the drm-515-kmod but I don't know how to find logs for it yet. Makes my PC unusable and I have to hard reset it, no amount of key presses or combination of key presses will do anything. It can do so from idle, just running an x session with a wm. Launching 3d games sometimes causes it as well, but I haven't tested since upgrading to BETA1. I will report back.
 
i915kms still causes a complete lockup with alderlake on BETA1.
Same failure for the version from official ports/packages as well as the 5.15.118 / 5.15-LTS version that is supposed to have all patches for "stable alder lake support" in place.
 
FreeBSD 14.0-BETA2 Now Available
Code: 
=== Upgrading ===

IMPORTANT IMPORTANT IMPORTANT IMPORTANT IMPORTANT IMPORTANT IMPORTANT

Due to an issue where an existing file had been replaced by a directory
with the same name, binary upgrades from 13.2 and earlier using the 
freebsd-update(8) utility will not work.  The issue is being
investigated.

IMPORTANT IMPORTANT IMPORTANT IMPORTANT IMPORTANT IMPORTANT IMPORTANT
 
Charlie_ said:
FreeBSD 14.0-BETA2 Now Available
Code: 
=== Upgrading ===

IMPORTANT IMPORTANT IMPORTANT IMPORTANT IMPORTANT IMPORTANT IMPORTANT

Due to an issue where an existing file had been replaced by a directory
with the same name, binary upgrades from 13.2 and earlier using the
freebsd-update(8) utility will not work.  The issue is being
investigated.

IMPORTANT IMPORTANT IMPORTANT IMPORTANT IMPORTANT IMPORTANT IMPORTANT
Click to expand...
Well that's a massive issue. Hope it's an easy fix.
 
sko said:
i915kms still causes a complete lockup with alderlake on BETA1.
Same failure for the version from official ports/packages as well as the 5.15.118 / 5.15-LTS version that is supposed to have all patches for "stable alder lake support" in place.
Click to expand...
Last time I tested I had lock up issues with drm kmod 15 with Rx 6400. It could render in frame buffer but any accel resulted in a hard lockup. Haven't tested in a while though.
 
The delay may be due to this: Bug 271607 (14.0r) - 14.0-RELEASE metabug.

I've been working in s/w development for years (decades actually). It's always better to ship code that is relatively free of the nasty kind of bugs. I recall one manager telling me that "we won't fix bug X until 80% of our customers complain about it." Well, that company is out of business. This wasn't the exact cause of that company's demise, there were other, bigger, factors involved, but this attitude certainly didn't help any.

The re@ team work hard to make sure people receive a quality product with few, if any, seriously annoying bugs. There are always bugs but they should be few and as esoteric as possible. I can appreciate the hard work put in by re@ to make sure the upgrade process and the user experience is as positive and enjoyable as possible.
 
So doing a buildworld on stable/14 branch, blows up when trying to compile contrib/sendmail/src/tls.c. Undefined symbol SSL_get1_peer_certificate, linker suggest SSL_get_peer_certificate found in /usr/local/lib/libssl.so (symlink to version 1x). I know there has been difficulties integrating OpenSsl v3x, but did expect buildworld to not reference libraries/header files outside my build sandbox.. Is there a pre-step I have to do, like getting an current version 3.x of openSSL installed in /usr/local/lib?
 
larsf said:
So doing a buildworld on stable/14 branch, blows up when trying to compile contrib/sendmail/src/tls.c. Undefined symbol SSL_get1_peer_certificate, linker suggest SSL_get_peer_certificate found in /usr/local/lib/libssl.so (symlink to version 1x). I know there has been difficulties integrating OpenSsl v3x, but did expect buildworld to not reference libraries/header files outside my build sandbox.. Is there a pre-step I have to do, like getting an current version 3.x of openSSL installed in /usr/local/lib?
Click to expand...
I think I figured it out - I had sasl enabled for sendmail, and src.conf contained SENDMAIL_LDADD=-L/usr/local/lib -lsasl2. Changing it to SENDMAIL_LDADD+=-L/usr/local/lib -lsasl2 didn't help either - both ended up causing the build to pick up /usr/local/lib/libssl.so instead of using the one from the build obj tree. Commenting out the sasl customization for src.conf resulted in a successful buildworld. I guess I simply have to rebuild sendmail after installing everything, and making sure the libssl in /usr/local/lib is the same version as the one in core and rebuilding and reinstalling sendmail again.
 
larsf that's correct. Well, almost, it would be simpler not to have any ssl libs in /usr/local at all, but the issue would remain, this can't work unless you have a libsasl2 there linking against the new OpenSSL version. And IMHO it's a horrible ugly hack allowing base sendmail to link libs from ports at all. It's a circular dependency and upgrade issues like this will be unavoidable.

I still think the only sane way would be to drop sendmail from base, a tiny and simple MTA like dma certainly is enough to make base itself work. Using sendmail from ports, there won't be any such issues.
 
SirDice said:
On 14.0 dma(8) is the default. Sendmail is still included with the base. But if you want to keep using sendmail(8) it's probably best to switch to mail/sendmail anyway.
Click to expand...
It's been a while since I've looked, but I think there used to be a make.conf knob that prevents you from building sendmail in base. If my recollection is not faulty and the knob still exists, maybe flipping it to "don't build sendmail in the base" as default?
 
mer said:
If my recollection is not faulty and the knob still exists, maybe flipping it to "don't build sendmail in the base" as default?
Click to expand...
Yes, it's still there. I think with 15 it'll be removed from the base entirely. When you build from source you can of course use src.conf, but this won't work for those that use binary upgrades/updates.
 
  • Like
Reactions: mer
FreeBSD 14.0-BETA4 Now Available
Code: 
=== Upgrading ===

IMPORTANT IMPORTANT IMPORTANT IMPORTANT IMPORTANT IMPORTANT IMPORTANT

Due to an issue where an existing file had been replaced by a directory
with the same name, binary upgrades from 13.2 and earlier using the 
freebsd-update(8) utility will not work.  A patch is currently in the
main branch, and expected to be included in supported release branches
before the next build.

IMPORTANT IMPORTANT IMPORTANT IMPORTANT IMPORTANT IMPORTANT IMPORTANT

PR 273661
Code: 
 Ed Maste freebsd_committer 2023-09-27 19:35:34 UTC Comment 12

A change to handle the file->directory case is now committed to main. Note that rollback will not yet work because we don't handle the directory->file case, in addition to preexisting issues with rollback (PR256252, PR273950).

You can try fetching freebsd-update from main and using it to upgrade to 14.0-BETA3 with something like:

$ fetch -o freebsd-update https://cgit.freebsd.org/src/plain/usr.sbin/freebsd-update/freebsd-update.sh
$ sha256 freebsd-update
SHA256 (freebsd-update) = cf4f38fb2ccc32236be9ec2300a21dcb02a1520d26f82479355b55508dd8598f
$ chmod a+x freebsd-update

then carry on with usual freebsd-update steps:

# ./freebsd-update -r 14.0-BETA3 upgrade
...
 
You must log in or register to reply here.
Back
Top