pkg: repository FreeBSD contains packages for wrong OS version: FreeBSD:12:amd64

I went to upgrade some (12.1p12) pkgs today and got this:

Code:
]# pkg upgrade
Updating FreeBSD repository catalogue...
Fetching packagesite.txz: 100%    6 MiB   6.4MB/s    00:01  
Processing entries:   0%
Newer FreeBSD version for package libxfce4util:
To ignore this error set IGNORE_OSVERSION=yes
- package: 1202000
- running kernel: 1201000
Ignore the mismatch and continue? [y/N]: n
pkg: repository FreeBSD contains packages for wrong OS version: FreeBSD:12:amd64
Processing entries: 100%
Unable to update repository FreeBSD
Error updating repositories

Why? And how is this resolved?
 
At the moment that is not desireable. Is there a repo that contains the last quarterly upgrades for 12.1 before EOL and which I can use in the meantime?
 
The ABI didn't change, so for most packages (excluding some containing kernel modules), *ignoring the error* as hinted in the message should work. (of course NOT tested, UNSUPPORTED!)

But JUST WHY are there always people insisting on running EOL systems? What's the deal? It's not like upgrading hurts or something. Especially talking about *minor* versions.
 
The deal is TIME. There are a lot of demands and system administration is just one of them. It is fine to say that three months is more than adequate to switch over. And that is true, if one has little else of importance to do. However, the current situation does not grant me the luxury of that time.

Having been bitten on several occasions by freebsd updates, I can assure you upgrades can and do hurt on occasion. Going from 11.2 to 11.3 broke something in behyve or zfs or both such that vms that had run without problems since creation on 10.3 began to simply hang. This became so bad that in the end we abandoned behyve altogether. But that migration in itself consumed the better part of a year to complete.

Then there was the move from 10 to 11 where the boot file system was screwed up and it was only pure luck that I did not bring down the system in a state where it could not reboot. And that was after we had trialed the upgrade on a different computer and had no problems.

I can live without access to the binary packages for 12.1. I have poudriere and if push comes to shove then I can build from ports selected by date. As I have had occasion to do.

I think that I need to set up my own repo, fetch pkgs into that, and install from there. It will take about 160G but I have the space.

And, at some point in the not two distant future I will move my development host to 12.2. Maybe I will try beadm again. Although the last time I tried that I ended up having to recover my zfs pool using a recovery CD.

Like the White Rabbit, I am always pressed for time; and I am not looking for additional work.
 
I have poudriere and if push comes to shove then I can build from ports selected by date.
Set this up permanently and always build your own repositories. Create a small script that just kicks off updates and builds during the weekend. Then each Monday morning you have a freshly updated repository. All with your specifically required versions, updates, settings, defaults and whatnot. Have all your servers get their updates from this repository. Now everything will be easily kept in sync and you're guaranteed every server will have the same package versions, defaults, etc.
 
I do not know what it is about freebsd and me. It seems that every time I try to do something some mysterious anomaly surfaces.

Today I decided to give beadm another go. There many examples on on the web, no two of which do things the same way. So, proceeding from one of the examples I started this way.:
Code:
sudo beadm create  12.1-RELEASE-p13
mkdir /mnt/beadm/12.1-RELEASE-p13
beadm mount 12.1-RELEASE-p13 /mnt/beadm/12.1-RELEASE-p13

At which point the instructions said 'start the jail' which was insufficiently explained for my level of expertise. So I went to the man page. And did this instead:
Code:
[root@vhost01 ~ (master)]# beadm list
BE               Active Mountpoint                   Space Created
default          NR     /                            98.7G 2020-05-20 11:25
12.1-RELEASE-p13 -      /mnt/beadm/12.1-RELEASE-p13   3.4M 2021-02-14 12:00

[root@vhost01 ~ (master)]# beadm activate 12.1-RELEASE-p13
Attempt to unmount boot environment '12.1-RELEASE-p13' mounted at '/mnt/beadm/12.1-RELEASE-p13'
Gracefully unmounted boot environment '12.1-RELEASE-p13' from '/mnt/beadm/12.1-RELEASE-p13' mount point

And that is where things are apparently stopped. At least the terminal session that is being run on has not returned to a prompt. Further, when I do this I also end up with a non-responsive session:
Code:
[root@vhost01 ~ (master)]# ps -auwx | beadm
^C
^C
^C

Nothing I have done here seems to me to be obviously wrong. Mounting the boot environment was ultimately pointless but it is not anything that beadm itself could not handle. And yet I have a system which is now in some sort of indeterminate state.

Now, do I reboot to get out of this? But what will rebooting actually do? Will I end up with an un bootable system? Will I end up reinstalling everything?

So now I am spending time that should be used to complete a project just doing maintenance on a system that was working perfectly well, it was just out of date.

And ostensibly beadm is supposed to protect me from this. I have not even started the upgrade.

I feel like I am on a hamster wheel. An unending cycle of upgrades. I only upgraded to 12.1 last March. That is 11 months ago. That upgrade took place 11 months after 12.0. How does one run a business when you have to update operating systems every year? And in my case the only reason to upgrade is to maintain access to compatible packages. Is this some sort of sysadmin make-work project?

Is it really that burdensome to provide a single archive of older packages somewhere? It need not be mirrored everywhere. Just leave it in some place accessible to pkg manager so that people running EOL freebsd releases can get additional software for their systems that is known to work when they encounter such a need. I will do that for myself in future but it would be a reasonable service to the community if such was provided. One can get older releases from the archives, just not the updated software that was provided up to their EOL.

I just do not know what I am going to do with my dev system. I will have to assume the worst and get everything moved onto another host. JHC this is such pointless waste of time and resources.
 
How does one run a business when you have to update operating systems every year?
Try running Windows with monthly update cycles.

How does one run a business when you have to update operating systems every year?
Better plan ahead. I'll let you in on a little secret, 12.3 is probably going to be released some time in September. And 12.2 will be EoL three months later.

Is it really that burdensome to provide a single archive of older packages somewhere?
You have a working poudriere installation. Why can't you just build and save whatever you need?

One can get older releases from the archives, just not the updated software that was provided up to their EOL.
You really don't understand what "end-of-life" means, do you?

At this stage, a vendor stops the marketing, selling, or provision of parts, services or software updates for the product.

Today I decided to give beadm another go.
Now. Lets give this another go. Unmount and remove the other BEs you created. I would use bectl(8) but this should be the same for beadm(1).

You start off with this:
Code:
root@armitage:~ # bectl list
BE      Active Mountpoint Space Created
default NR     /          6.43G 2014-02-24 23:39
Create a new BE, this will be your backup.
Code:
root@armitage:~ # bectl create before-update
root@armitage:~ # bectl list
BE            Active Mountpoint Space Created
before-update -      -          8K    2021-02-14 21:35
default       NR     /          6.43G 2014-02-24 23:39
Next, run your upgrade, freebsd-update -r 12.2-RELEASE upgrade. Finish the whole upgrade procedure. If anything goes wrong during the upgrade, use the boot menu to select the 'before-update' BE (or use bectl activate before-update). If the upgrade went fine, remove the before-update BE.
 
Try running Windows with monthly update cycles.

The main reason that we never ran our business applications on Windows. We started out with HP-UX, and moved to RH7 something four years later. When RH went to RHEL we tried that for a year and gave up on it. We then went to Whitebox Linux, to CaOS when WBL stopped being supported, to CentOS-5 though 7, which was taken over by RH and has been effectively discontinued after 8., and now to FreeBSD.

Windows is used only for desktop applications. We do not use MS-Office but Libreoffice. There is nothing else of importance running on them.. The primary use of our AD-DC is to simply control access to the local network. The business applications all run on Unix, Linux, or MPE/iX systems.

Windows updates are applied to all desktop systems at intervals which exceed monthly by a considerable margin. It matters little due to the firewalls, file filters, and proxies used to isolate the work stations from the Internet. We use Samba for our AD-DCs and the users profiles and Document libraries are also kept on a Samba File server.

Running Windows without updates is not completely without risk; what is? None-the-less while we have been connected to the Internet since 1995 we have never had a virus or malware incident. And, because of our industry, we get hammered night and day by brute-force and phishing expeditions.
Better plan ahead. I'll let you in on a little secret, 12.3 is probably going to be released some time in September. And 12.2 will be EoL three months later.

You have a working poudriere installation. Why can't you just build and save whatever you need?
That is what I have done in the past and no doubt will do in future. But first I will take the advice of Phishfry and use pkg fetch -a to create and maintain a complete local repository.
I am not looking for the latest and greatest. I just need to be able to install software whenever I run into the need for it without having to upgrade the underlying system.

On the matter of rebuilding the software every weekend it is to be noted that building the llvm tool chain alone, which appears to be necessary with distressing frequency, takes on the order of 16-20 hours on an otherwise unused system with 64Gb RAM and an 8-core, 16 cpu, processor, running at 3.69 GHz.
You really don't understand what "end-of-life" means, do you?
Do not be silly. I am not asking for support after EOL. I only want access to what software packages that were available immediately before EOL. This is a policy matter that has nothing to do with support or EOL. It is simply a matter of disk space.

I will solve this for myself if not for others by maintaining my own archives. But, I am sure that I am not the only one that keeps systems running on software well past its arbitrary EOL date. It is not as if it all suddenly stops working. And providing this for everyone does not appear to me to pose insurmountable, or even terribly inconvenient, difficulties.

The real question that begs to be answered is: What is the reason the life cycle is so abbreviated to being with? What are we racing? Is this little more than a Chromium/Firefox thing where the goal is to have the highest version numbers?
Now. Lets give this another go. Unmount and remove the other BEs you created. I would use bectl(8) but this should be the same for beadm(1).

You start off with this:
Code:
root@armitage:~ # bectl list
BE      Active Mountpoint Space Created
default NR     /          6.43G 2014-02-24 23:39

In my case I had to restart the system because I could not get anything to work in the state beadm left it in. USB flash memory would not mount. The mouse stopped responding. Fortunately I had an unblocked terminal session running as root and could run shutdown; except that it would not. Eventually I had to cross my fingers, power-cycle the host, and pray that it restarted .

This does not increase my confidence in beadm. It seems to me disconcerting that software designed to protect users from errant updates behaves this way before one even gets to the stage of applying an update. No doubt prior actions on my part set this scenario up to fail. But really, did I do anything that self-evidently should have caused the behavior I experienced? Was there any way for me to reasonably anticipate that this would be the result?

It is one thing to have done something so regularly that its flaws and eccentricities are unconsciously avoided. It is quite another to come at something which one has never successfully attempted before. At least this time I did not have to recover the zpool from a live cd.

Fortunately, there were two BEs present at startup; And the one I had activated was indeed active. SO the system came up, apparently none the worse for wear, in the alternate BE. Even if my heart was in my mouth during the boot.

bectl and beadm show this:
Code:
[root@vhost01 ~ (master)]# bectl list
BE               Active Mountpoint Space Created
12.1-RELEASE-p13 NR     /          4.57M 2021-02-14 12:00
default          -      -          97.9G 2020-05-20 11:25

[root@vhost01 ~ (master)]# beadm list
BE               Active Mountpoint  Space Created
default          -      -           97.9G 2020-05-20 11:25
12.1-RELEASE-p13 NR     /            4.6M 2021-02-14 12:00

Create a new BE, this will be your backup.
Code:
root@armitage:~ # bectl create before-update
root@armitage:~ # bectl list
BE            Active Mountpoint Space Created
before-update -      -          8K    2021-02-14 21:35
default       NR     /          6.43G 2014-02-24 23:39
This evidently has been done.
Next, run your upgrade, freebsd-update -r 12.2-RELEASE upgrade. Finish the whole upgrade procedure. If anything goes wrong during the upgrade, use the boot menu to select the 'before-update' BE (or use bectl activate before-update). If the upgrade went fine, remove the before-update BE.
At the moment my plan of attack is:

First I am going to update my backups, which are done overnight every 24 hours in any case.

Next I am going to restart the host and go back to the original BE just to satisfy myself that it can be done.

Then I will return to the alternate BE, again to satisfy myself that it can be reliably repeated. This no doubt appears amusingly over-cautious but frankly, I have been bitten too many times by assuming that things just work as they are supposed to.

Then I will return to the default BE.

Then, and only then, I will attempt to apply the update.

Fortunately, today is a statutory holiday in my location so I have the time to myself to get this done.

My question is this: If things go badly in the update in the default BE and one re-boots into the backup, what then? Does the alternate BE remain as the default until the next update cycle? Or does one somehow transition the backup BE back to the default? Or what else?

And lest you think otherwise, I appreciate the help that I get here. Not the least from yourself. Thank you.
 
On the matter of rebuilding the software every weekend it is to be noted that building the llvm tool chain alone, which appears to be necessary with distressing frequency, takes on the order of 16-20 hours on an otherwise unused system with 64Gb RAM and an 8-core, 16 cpu, processor, running at 3.69 GHz.
You're doing something wrong here. My lowly Core i5-3470 (4 cores, 4 threads) 3.20GHz with 16GB RAM does this in less than 3 hours. While building 3 of them at the same time (llvm90,llvm10,llvm11). I agree the constant building and rebuilding of the different LLVM versions is annoying, but it's not so bad as you're trying to portray.

The real question that begs to be answered is: What is the reason the life cycle is so abbreviated to being with? What are we racing? Is this little more than a Chromium/Firefox thing where the goal is to have the highest version numbers?
Every major version is supported for no less than 5 years. That's a considerable advantage over the old schedule where even numbered minor versions where supported for 2 years and everything else for only 1. Just keep up with the minor versions, really. The longer you postpone updating the bigger your problems are going to be. If you keep up they're little steps you take. When you keep pushing things forward the steps needed to be taken will get bigger and bigger. Until you get to a point where you have to invest a considerable amount of time trying to figure out everything that's changed.
 
Is it really that burdensome to provide a single archive of older packages somewhere? It need not be mirrored everywhere. Just leave it in some place accessible to pkg manager so that people running EOL freebsd releases can get additional software for their systems that is known to work when they encounter such a need.
Extremely burdensome, in fact. Provide any hint of support and people will demand more free shit on top of that. (There are actually a few release_<minor-number> repos around. Not sure what they are intended for and how long they stay available.)
 
You're doing something wrong here. My lowly Core i5-3470 (4 cores, 4 threads) 3.20GHz with 16GB RAM does this in less than 3 hours. While building 3 of them at the same time (llvm90,llvm10,llvm11). I agree the constant building and rebuilding of the different LLVM versions is annoying, but it's not so bad as you're trying to portray.
I was wrong. It only takes eight hours.

308llvm10-10.0.1_5devel/llvm10success07:57:16


But Libreoffice is still building fifteen hours into the process:
Code:
[10:02:29] [01] [00:00:00] Building editors/libreoffice | libreoffice-7.1.0.3_2

01libreoffice-7.1.0.3_2editors/libreofficebuild05:36:16

This is my general purpose system. I have ccache enabled. And my memory is 32 G, not 64. I had to swap systems last fall and the new one does not have as much memory as the old. Never noticed it before.
 
It only takes eight hours.
Still about 2.5 times slower than mine, while your system should be able to do this in 2-3 hours.

In /usr/local/etc/poudriere.conf, set ALLOW_MAKE_JOBS_PACKAGES, that should improve build times.
Code:
ALLOW_MAKE_JOBS_PACKAGES="pkg llvm* gcc*"
In your case you might want to add openjdk* and libreoffice to that list too.
And my memory is 32 G, not 64. I had to swap systems last fall and the new one does not have as much memory as the old.
I do this with 16GB, so 32 should be fine. 64 would be nicer of course. More is always better with this kind of load.
 
… There many examples on on the web, no two of which do things the same way. So, proceeding from one of the examples I started this way.:
Code:
sudo beadm create  12.1-RELEASE-p13
mkdir /mnt/beadm/12.1-RELEASE-p13
beadm mount 12.1-RELEASE-p13 /mnt/beadm/12.1-RELEASE-p13
Seeing use of a temporary mount point, for the boot environment that was to be upgraded, makes me wonder whether the followed example was one that intended to streamline things – through not requiring a restart at the stage when (according to the FreeBSD handbook) a restart is customary.

If so: please beware of shooting oneself in the foot when there's on-screen direction to fetch updates. The direction may be inappropriate (as a result of your skipping the restart); if you proceed to install what's fetched, the resulting boot environment might be a horrible mash.
 
The ABI didn't change, so for most packages (excluding some containing kernel modules), *ignoring the error* as hinted in the message should work. (of course NOT tested, UNSUPPORTED!)

But JUST WHY are there always people insisting on running EOL systems? What's the deal? It's not like upgrading hurts or something. Especially talking about *minor* versions.
Why do developers insist on not understanding that users want to *use* our software and to continue using it once it's working. We don't necessarily need the newest and the fanciest features. The system not breaking is almost always more important and sometimes, the system just *must*not* break. And upgrades always break things.

People still use COBOL and floppy disks, because they have systems that solve a problem. We're *not*interested* in upgrading.

I'm having the exact same issue as the O.P. - Googling my problem brought me to this page. The system I need to install a new package on is located remotely and there is no way to get to it physically in the foreseeable future (as in, months to years). If I try to upgrade the system and the upgrade fails (as upgrades often do), the machine will become inaccessible via the network and there will be no way of resetting it - it will become a brick and there will be no way to unbrick it.

Why is it not possible to keep the packages that have already previously been made available still available, just because the system has been EOL'd?
 
A minor upgrade will not break things. It does deliver a few features where it won't hurt, but in general, keeping your system up to date is about keeping it secure.

For major upgrades, support cycles are really long enough, so you can prepare as long as you need.

And sure, you can always mess up something yourself. That's why for remote systems, you need remote access to the serial console as well. Anything else is just unprofessional.
 
You can, of course, assume you know everything and call your users "unprofessional" when you don't know how things are deployed, why they were deployed the way they were, and what is possible and what is not. As an alternative, I would encourage you to try listening to what people are telling you. It seems from your post that what you are frustrated by what many people are telling you but unwilling to contemplate the possibility that all these people may have a point.

My remote system is inaccessible. There is ssh access - but that depends on the system being bootable. There isn't (and never was) a way to add a remotely accessible serial console. It does not matter how long I had to prepare. At the time of deployment, it was not foreseeable that the system would ever be inaccessible for this length of time, but due to changed circumstances, this is how things turned out to be.

"This *minor* upgrade will not break things, honest". "Just add this little tweak to the code, it can't break anything, there is no need to redo the Q&A, honest." Famous last words. I've seen that go wrong more times than I care to remember. Very cheap for you to say, very expensive for me to fix when it goes wrong.

When a system deployed in the field that's been designed for reliability & redundancy because it breaking would be expensive or even catastrophic, the last thing you want to do is a pointless software upgrade which adds no value but could break the system.

I've even upgraded the Linux kernel on my laptop - sitting right in front of me on my desk - before and it broke the system to such a degree that there was no option but to wipe it all out and reinstall - in one case, there was no ZFS on Linux release available yet compatible with the new kernel (rather unhelpful, since all my partitions use ZFS), in another case, there were no nVidia drivers yet compatible with the new kernel, so display was unusable. Much of the upgraded userland was incompatible with the old kernel, the new kernel would not boot, so there was no way to boot the system any more. Which kept me offline for several days while I reinstalled the (old version, of course) operating system, at a time I could ill afford it. If it had been a remote system, the situation would have been impossible.

In many cases, upgrading is just not an option, absolutely and under any circumstances. In others cases, it is a conscious choice. Maybe we just don't like a new release. Maybe it's in an embedded system which is at its limit of storage space, and there just isn't the room for an upgrade. Maybe the installed system has been carefully secured and been security audited - and an upgrade invalidates those efforts - so NOT upgrading is about keeping your system secure. Almost every time with closed source software, but also occasionally with open source software (e.g. Ubuntu) we've seen cases where an upgrade surreptitiously installed new spyware.

Many users want the option of being able to run an installed system - once it's been extensively tested to work and solve a problem - indefinitely, without ever upgrading the operating system. The fact that people are telling you that and that you're frustrated by them is proof of that. That doesn't mean we don't need to be able to install additional software packages which were known to be available for that operating system & which makes it very unhelpful if those packages suddenly disappear. I know of people who are still using NeXT computers from the 1980s to drive manufacturing machinery, there are people still running software written in COBOL and I hear there are still people using 8" floppies. Some people use computers to solve problems - not to play around with fancy new features. If you insist on forcing users to upgrade when we don't want to, many people will just conclude it's not possible to work with you because you try to force your will on other people rather than listen to user requirements.
 
A minor upgrade will not break things. It does deliver a few features where it won't hurt, but in general, keeping your system up to date is about keeping it secure.
This statement is not factual. I have personal experience with so-called minor upgrades that caused previously working software to simply stop working. I am not interested in debating how my empirical observations conflict with theoretical arguments, much less the presumptive arrogance which stoops to name calling.
 
Just because updates are available does not mean one has to actually update. And yes, I've been bitten hard by the failed remote update and heck even a failed local one.

I understand the problem of "I need to add a new package to my EoL system but it wants to update everything", because I've been there. But I never expected the project to keep packages built against my EoL version. Honestly, what should be kept? The packages defined by the state of the ports tree when the base went EoL? The last quarterly set of packages for that EoL release? How far back should the project be expected to keep these packages? It's all disk space, it's all costing someone real money somewhere to do that.

Lets look a MS Windows ecosystem. I've know people that pretty much had a system running Win95 because it worked for what they needed. Web, email, Quicken, a couple other things. It got to the point where their applications got to "If you want to upgrade this application to the latest version, you need to upgrade your system from Win95 to Win-XYZ". So wanting the supported version of the application they were forced into a system upgrade. Not pretty (family so of course the resident "expert" gets voluntold to help), but better in the long run.

I'm telling you that simply because it is similar to what's described here: application driving system upgrade.
 
mer, This reminds me of a story that was relayed to me a number of years ago. A university in Eastern Canada had an IBM mainframe application that that only ran on an ancient version of OS/MVT. (OS/MVT was the predecessor to OS/VS2, which became MVS, ... which became todays z/OS. MVT did not support paging and only operated in 24-bit mode, not 31- [yes, 31, not 32] or 64-bit mode.) They lost source code to their application. And, newer IBM mainframes were incapable of running the old MVS because new mainframes do not support bus and tag (think ISA bus on PCs -- I don't think anything except maybe NetBSD supports ISA anymore) interfaces. They spun up a z/VM (another IBM mainframe O/S) instance to emulate old hardware in order to run the old O/S which could run their old app which they had lost the source code to. These are the lengths to which people go to in order to run old software. This kind of stuff happens more often than we might think.
 
cy@ that tops just about "it does what I want why should I upgrade" stories that I have. Father In Law may have had a Win3.x that just kept on going for longer than it should, but I was the one that had to explain the Win95 to whatever was next.
 
Back
Top