!!!!WARNING ALL FREEBSD DESKTOP USERS!!!! : Insane pkg's new version upgrade of installed apps

Well, I was just updating a 14.3-RELEASE and just updating any packages that need to be updated. On one machine (my main workstation), I have an NVidia card, which often causes issues with an upgrade, but, even without the various patches, knowing how to fix it makes the fix simple. For example, this upgrade upgraded the nvidia-drm-61-kmod and then removed the nvidia-driver, but while I didn't expect that particular thing to happen, I expected problems with Nvidia. I guess a warning for newer users would be good about that, but there's probably information somewhere. I also have the linux nvidia stuff which adds to things that can go wrong.

I don't know who first said it, but it's true for most things, Everything's easy when you know how to do it.

However, I've learned that the fix is easy, and that if I then install nvidia-drm-kmod from ports, it pulls in any other nvidia and nvidia-linux stuff that I need.
Also, as mentioned above (too lazy to scroll up to give proper credit) there are, for ZFS users, the boot environments where you can go back to a previous boot environment to undo whatever bad changes occured.
 
I've had just the same Problem yesterday.
But: Thanks God I switched me FreeBSD-Boxes to ZFS and pkgbase two weeks ago!!
I just had to use my last BE and everything is fine.
So my recommandation:
Give ZFS a try!!
 
  • Like
Reactions: mro
scottro said:
On one machine (my main workstation), I have an NVidia card, which often causes issues with an upgrade, but, even without the various patches, knowing how to fix it makes the fix simple.
Click to expand...
This would be related with that nvidia things are not in FreeBSD[-pors]-kmods repo and in main FreeBSD[-ports] repo, pkgs are built against 14.2 until the end of September, causing mis-match between kmod and kernel.
See Comment #23 for more details, including ongoing issue on kmod builder.

scottro said:
For example, this upgrade upgraded the nvidia-drm-61-kmod and then removed the nvidia-driver, but while I didn't expect that particular thing to happen, I expected problems with Nvidia.
Click to expand...
This would be because x11/nvidia-driver* are restructured with splititng out kmod parts as corresponding x11/nvidia-kmod*. Have you read UPDATING?

scottro said:
I also have the linux nvidia stuff which adds to things that can go wrong.
Click to expand...
x11/linux-nvidia-libs* must be kept in sync with corresponding x11/nvidia-driver* (now mainly libraries part).

scottro said:
However, I've learned that the fix is easy, and that if I then install nvidia-drm-kmod from ports, it pulls in any other nvidia and nvidia-linux stuff that I need.
Click to expand...
graphics/nvidia-drm-kmod is a metaport to choose proper graphics/nvidia-drm-*-kmod for OSVERSION running, and also pulls in corresponding x11/nvidia-driver*.
Chosen graphics/nvidia-drm-*-kmod (graphics/nvidia-drm-61-kmod for 14.3) pulls in corresponding graphics/drm-*-kmod and x11/nvidia-kmod*.
But they shouldn't pull in corresponding x11/linux-nvidia-libs*, as it is optional (not needed for anyone who don't use nvidia libraries in Linuxulator).

If graphics/nvidia-drm-kmod* pulling in corresponding x11/nvidia-driver* is causing kmod builder doesn't build nvidia things (hope it unlikely), things needs to be changed. See my comment on review D52831 dated Sun, Oct 5 for additional info, if you want.
 
T-Aoki said:
This would be because x11/nvidia-driver* are restructured with splititng out kmod parts as corresponding x11/nvidia-kmod*. Have you read UPDATING?
Click to expand...
That entry in Updating is about as explicit as one could want. I've gotten into the habit of commenting out loading of the drm bits in rc.conf before rebooting into console just in case.
Then when you are around EOL of one version and quarterly updates on the next version, it's best to wait on upgrading until packages are built against the new version
 
mer said:
Then when you are around EOL of one version and quarterly updates on the next version, it's best to wait on upgrading until packages are built against the new version
Click to expand...
I think so.
Full builds from scratch should require a fair amount of times, and some huge ports would likely fail on first run by build timeout (too heavy loaded).
 
  • Like
Reactions: mer
Maturin said:
the update was done before the package repository was finished building
Click to expand...
Now this is kind of a problem, there's a ton of extra work figuring out the schedule. And we all know about the mess that pkg became. Who wants to be beholden to THAT mess? You'd think the issues with pkg would have gotten ironed out by now, and there'd be some discipline in publishing and not releasing an incomplete repo...

Not to mention that GPU drivers are beholden to kernel version.
 
mer said:
I'm starting to think the upgrade issues some have are because of Linux behavior. "OMG an upgrade came out 3 seconds ago I must upgrade" instead of sitting and thinking "should I or should I not"
Click to expand...

I'd rather say the dudes that work on all the ports & packaging process perhaps they don't use packages at all.
 
freezr said:
I'd rather say the dudes that work on all the ports & packaging process perhaps they don't use packages at all.
Click to expand...
If one looks at a lot of the package fallout, builds fail because of resources. A developer will rebuild and verify what he is responsible for, but if he's not working on something that causes libreoffice/chrome/firefox to not build, how is he responsible?
 
Don't forget that official pkgs (excluding for pkgbase things) are built using ports with default options. pkgs are NOT available if corresponding ports do NOT exist.

Ports are primary, and pkgs are for convenience.

So to avoid fallout issues, doing dry-run by pkg upgrade -n before proceeding to actual upgrade is a good habit.
 
mer said:
I'm starting to think the upgrade issues some have are because of Linux behavior. "OMG an upgrade came out 3 seconds ago I must upgrade" instead of sitting and thinking "should I or should I not"
Click to expand...
If they do then it may be because the upgrades always work, or else like me they want security updates as soon as possible. I don't upgrade for any other reason except end of support.
freezr said:
I'd rather say the dudes that work on all the ports & packaging process perhaps they don't use packages at all.
Click to expand...
They may be focusing their attention on the upcoming 15.0 with pkgbase. I've been testing 15.0-ALPHA on the same PC that I use for testing 14.3-RELEASE, and I haven't had a single problem so far. pkg upgrade has been working perfectly since ALPHA3 (now on ALPHA5 with pkg version 2.3.1). This is with the same nvidia card and UFS.

I was reluctant to accept the change from freebsd-update at first, but now I find using pkgbase is simpler.
 
Haven't seen any problems with pkg here, including a full upgrade from 14.2R to 14.3R. All worked perfectly. I don't have any complex desktops installed though, no gnome or kde, so maybe I've been lucky.

As someone else recommended a while ago I always run 'pkg upgrade -n' so I can see what it's going to do before I do it for real.
 
drhowarddrfine said:
And now you did it again! 😁
Click to expand...
Just following the example of the Patriarchs 😉:
FI-Q1GNXEAUWnNK.jpeg
 
T-Aoki said:
For anyone using quarterly repo (default for *-Release), avoid upgrading in early January, April, July and October.

In these timing, new quarterly (*Q1, *Q2, *Q3 and *Q4) branch is created and all pkgs are build with new quarterly (now 2025Q4) and until the build finishes, some of pkgs should be absent and cause deletion on upgrading.

Significant examples are www/chromium, editors/libreoffice, www/ungoogled-chromium, www/iridium and devel/electron*, which all of them are huge.
Click to expand...
If I understand you correctly, the workflow used by the system that creates packages for RELEASE is the following:
  1. On October 1st, create a new empty package directory for the current quarter.
  2. Begin populating it with newly built packages. This takes several days.
  3. Use the created packages for the remainder of the quarter, unless they need to be regenerated.
And: if anyone runs a "pkg upgrade" command between steps 1 and 2 above (when the new quarterly repo is only partially populated), they will get some of their installed packages deleted. In other words, there is a window of several days every quarter (or roughly several percent probability) where an host is at high risk of having packages wrongly uninstalled.

If true, that would mean that the "pkg upgrade" mechanism has only a reliability of 1-2 nines (about 90% to 99%). That would be insanely bad.
 
ralphbsz said:
If true, that would mean that the "pkg upgrade" mechanism has only a reliability of 1-2 nines (about 90% to 99%). That would be insanely bad.
Click to expand...
Don't sweat it, that's a completely wrong description. Repos only get visible updates once a whole package set is built. Packages might go missing if they failed to build, but at no point in time you'll get a view into a WIP package set.
 
ralphbsz said:
In other words, there is a window of several days every quarter (or roughly several percent probability) where an host is at high risk of having packages wrongly uninstalled.
Click to expand...
Or building errors.

Yep, there is four "holy months" in year, when FreeBSD user try to not do fresh installs of OS or upgrading software. ||irony

Fresh quarterly, for example, dont have chromium.
 
ralphbsz said:
If I understand you correctly, the workflow used by the system that creates packages for RELEASE is the following:
  1. On October 1st, create a new empty package directory for the current quarter.
  2. Begin populating it with newly built packages. This takes several days.
  3. Use the created packages for the remainder of the quarter, unless they need to be regenerated.
Click to expand...
I'm not 100% understanding how pkg build cluster work (I'm not on clusteradm team). Some says they're using poudriere to build, and some says they're using jenkins to build.

So below include "prediction". Using pooudriere. (I've never tried jenkins.)

  1. On Oct.1, 2025Q4 is branched (annoucement here).
  2. At some point after that, build cluster is re-configured to use 2025Q4 instead of 2025Q3 and use 14.3 instead of 14.2 as of EoL
  3. poudriere bulk builder detects OSVERSION upgrade and delete all pkgs before starting actual builder jails, and the repo which builders store their results IS the official pkg repo
  4. builds finish with most succeeds, some ignored, some failures and some skips (as of failures and/or ignores)
  5. ports tree for builder is re-sync'ed with the hope that some of failures are fixed
  6. build updated and nonexistent (former failures, skips and ignores)
Then 5 and 6 are regularly repeated. So someone could be affected until 6 fiishes successfully.

Note that some of ports are restricted (by upstream) not to distribute other than upstream's official builds, so these kind of things are NEVER provided as pkg and mandated to build locally. And some requires sign ups and so on to download source tarballs.
 
You must log in or register to reply here.
Back
Top