jails Update of 13.2 jail to 14.1 appears stalled

byrnejb

byrnejb

Is there any specific known reason why upgrading a jail from 13.2 to 14.1 on a 14.1 host would take 24+ hours and still not yet be complete? This specific jail is a Postfix MTA and has virtually nothing else running on besides basic services like sshd. All of the upgrades to 14.1 have taken much, much longer than any previous upgrade I have performed. The present one however is something else.
 
Which part is taking so long? The freebsd-update -r 14.1-RELEASE upgrade or the freebsd-update install phases?
 
The host system was updated to 14.1 and its pkgs upgraded before upgrading the jails. The jail was at 13.2.
Code: 
# iocage upgrade mx31-1 -r 14.1-RELEASE
. . .
To install the downloaded upgrades, run 'tmp98cttc0u [options] install'.
Installing updates...

SirDice said:
Which part is taking so long? The freebsd-update -r 14.1-RELEASE upgrade or the freebsd-update install phases?
Click to expand...
The host is not the problem. That was carried out last week and while it took a lot longer than I expected it completed within three or four hours. It is the jails that are taking so long.
 
byrnejb said:
The host is not the problem
Click to expand...
I didn't ask about the host.
byrnejb said:
It is the jails that are taking so long.
Click to expand...
Yes, and I was wondering what phase of the process is taking so long? But looking at the previous post I see you're using iocage, which you didn't mention in the thread starter. So I had no idea how you were upgrading your jails.
 
Ones usual tools often are taken for granted when discussing things. My normal practice to to state that I am working with iocage managed thick jails.
 
There is some sort of problem with freebsd-update on 14.1. I started another
Code: 
iocage upgrade
of a jail, this time to 13.3-RELEASE, and I am getting the same issue:
Code: 
# ps -auwwwx | grep freebsd-update
root    90553   0.0  0.0  12808  2348  6  S+   08:07       0:00.00 grep --color=auto freebsd-update
root    77409   0.0  0.0  13376  3264  9  I+   17:04       0:01.69 /bin/sh /tmp/tmp55b0v2ie -b /zroot/iocage/jails/webmail-1/root -d /zroot/iocage/jails/webmail-1/root/var/db/freebsd-update/ -f /zroot/iocage/jails/webmail-1/root/etc/freebsd-update.conf -r 13.3-RELEASE install
root    92832   0.0  0.0  13376  3256  9  SX+  17:12       0:25.15 /bin/sh /tmp/tmp55b0v2ie -b /zroot/iocage/jails/webmail-1/root -d /zroot/iocage/jails/webmail-1/root/var/db/freebsd-update/ -f /zroot/iocage/jails/webmail-1/root/etc/freebsd-update.conf -r 13.3-RELEASE install

This has been running since 17:00 EDT yesterday and it is now 08:10 EDT.
 
byrnejb said:
The host system was updated to 14.1 just last week. That should incorporate the fix to freebsd-update.
Click to expand...
No. iocell (and hence very likely also iocage) uses freebsd-update from the release dataset from which the jail is cloned: ${iocroot}/releases/${_jail_release}/root/usr/sbin/freebsd-update. So in your case 13.2-RELEASE which very likely wasn't updated to include that patch.


edit:
another thing to consider: do you have /usr/src populated on the host and/or jails and does that system use spinning rust? Updating /src during freebsd-update causes *a lot* of random IO and hence completely chokes spinning disks. I usually nuke /usr/src even on NVME-based systems before upgrading, because it is much faster to just git clone the sources after the upgrade (if needed at all...)
 
sko said:
No. iocell (and hence very likely also iocage) uses freebsd-update from the release dataset from which the jail is cloned: ${iocroot}/releases/${_jail_release}/root/usr/sbin/freebsd-update. So in your case 13.2-RELEASE which very likely wasn't updated to include that patch.


edit:
another thing to consider: do you have /usr/src populated on the host and/or jails and does that system use spinning rust? Updating /src during freebsd-update causes *a lot* of random IO and hence completely chokes spinning disks. I usually nuke /usr/src even on NVME-based systems before upgrading, because it is much faster to just git clone the sources after the upgrade (if needed at all...)
Click to expand...
Wait how do you update that binary then? You need to break the link from the jail to the release dataset somehow? Is that even possible with iocage? Or does iocage expect that I create new jails, migrate and destroy older ones every time I want to upgrade?
 
DaLynX said:
Wait how do you update that binary then?
Click to expand...
freebsd-update fetch install

Or by updating the release dataset and upgrading the jail via iocell fetch. This will update the dataset to the latest patchlevel; basejails will be re-cloned upon restarting them and thus they inherit the update.
But as you usually just iocell fetch a new release and then iocell upgrade <jailname> a jail, which merges /etc and sets its release property to the new release (i.e. cloning the jail from the new release dataset at next start), they will inherit those patches from the newly downloaded release.
Except for fatjails you usually never need/want to update jails via freebsd-update
 
All our jails are thick(fat) jails. I have upgraded one to 13.3 from 13.2 and that also took a very long time.
Code: 
# time iocage upgrade webmail-1 -r 13.3-RELEASE
. . .
webmail-1 successfully upgraded from 13.2-RELEASE-p9 to 14.1-RELEASE-p2!

real    1464m58.690s
user    15m55.012s
sys     33m48.663s
Then upgrading to 14.1 took a lot less time, but still far more than I had come to expect.
Code: 
# time iocage upgrade webmail-1 -r 14.1-RELEASE
. . .
webmail-1 successfully upgraded from 13.3-RELEASE-p4 to 14.1-RELEASE-p2!

real    374m10.425s
user    9m54.061s
sys     21m40.503s
 
byrnejb said:
All our jails are thick(fat) jails. I have upgraded one to 13.3 from 13.2 and that also took a very long time.
Code: 
# time iocage upgrade webmail-1 -r 13.3-RELEASE
. . .
webmail-1 successfully upgraded from 13.2-RELEASE-p9 to 14.1-RELEASE-p2!

real    1464m58.690s
user    15m55.012s
sys     33m48.663s
Then upgrading to 14.1 took a lot less time, but still far more than I had come to expect.
Code: 
# time iocage upgrade webmail-1 -r 14.1-RELEASE
. . .
webmail-1 successfully upgraded from 13.3-RELEASE-p4 to 14.1-RELEASE-p2!

real    374m10.425s
user    9m54.061s
sys     21m40.503s
Click to expand...
But it states "webmail-1 successfully upgraded from 13.2-RELEASE-p9 to 14.1-RELEASE-p2!" not 13.2 to 13.3?
 
Session window has closed and I cannot get the actual screen text. However, one can see that webmail-1 was updated to 13.3 before upgrading to 14.1. All our jails on that system were at 13.2-p12 before any upgrades were done.
 
You must log in or register to reply here.
Back
Top