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.
