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

byrnejb

Well-Known Member

Reaction score: 27
Messages: 436

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?
 
OP
B

byrnejb

Well-Known Member

Reaction score: 27
Messages: 436

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?
 

Zirias

Son of Beastie

Reaction score: 1,517
Messages: 2,638

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.
 
OP
B

byrnejb

Well-Known Member

Reaction score: 27
Messages: 436

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.
 

Phishfry

Beastie's Twin

Reaction score: 2,668
Messages: 5,588

It will take about 160G but I have the space.
Code:
pkg fetch -a
Number of packages to be fetched: 30172

The process will require 87 GiB more space.
87 GiB to be downloaded.

Proceed with fetching packages? [y/N]:

So 87 Gibibytes = 95 Gigabytes for all AMD64 packages
 

SirDice

Administrator
Staff member
Administrator
Moderator

Reaction score: 12,298
Messages: 38,811

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.
 
OP
B

byrnejb

Well-Known Member

Reaction score: 27
Messages: 436

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.
 

SirDice

Administrator
Staff member
Administrator
Moderator

Reaction score: 12,298
Messages: 38,811

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.
 
OP
B

byrnejb

Well-Known Member

Reaction score: 27
Messages: 436

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.
 

SirDice

Administrator
Staff member
Administrator
Moderator

Reaction score: 12,298
Messages: 38,811

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.
 

shkhln

Daemon

Reaction score: 964
Messages: 2,217

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.)
 
OP
B

byrnejb

Well-Known Member

Reaction score: 27
Messages: 436

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.
 

SirDice

Administrator
Staff member
Administrator
Moderator

Reaction score: 12,298
Messages: 38,811

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.
 

grahamperrin

Daemon

Reaction score: 675
Messages: 2,144

… 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.
 
Top