after upgrade config load issue (frm 17.1.2.1 to 17.1.2.2 Hotfix- BIGIP-17.1.2.2.0.259.12-ENG.iso

It was a very interesting situation: the configurations of both devices were identical (I'm not referring to the IP addresses), but only one device encountered a bug. How I solved it: first, I extracted the UCS file I had previously obtained, then I merged and updated the VLAN, partition, route domain, and selfip definitions from the terminal. Then I saved it as UCS. After that, I rebooted by loading UCS.

Translated with DeepL.com (free version)

It seems to be a bug in f5os.

Please check below.

https://techdocs.f5.com/kb/en-us/products/f5os-a/releasenotes/related/relnote-supplement-f5os-a-1-5-0.html

1292541 : Loading saved configuration on BIG-IP fails if host modifications are made after "tmsh save sys config" on R2800/R4800 platforms
Component: F5OS-A

Symptoms:
Loading saved configuration on BIG-IP tenant running on R2800/R4800 fails when host has a different configurations compared to what is being loaded on the tenant.
Fails with an error message similar to below:

01070257:3: Requested VLAN member (1.5) is currently a trunk member
Unexpected Error: Loading configuration process failed.

Conditions:
-- rSeries 4x00 or R2x00 platform
-- Configuration is backed up using tmsh
-- A change is made to one or more VLANs, interfaces, trunks, or type of VLANs on the host
-- The BIG-IP system loads the configuration

Impact:
Configuration load fails, which puts TMM into an inoperative state.

Workaround:
When tenant is in inoperative state because of this issue, the steps below help in recovering the system:

1. Revert the configuration on the platform related to VLANs attached to the tenant moved to INOPERATIVE state.
2. Check if reverted configuration is loaded in tenant.
3. Restart the mcpd service or reboot the tenant to bring back tenant to active state.
4. Once the tenant is back to active state, save the config using "save sys config".
5. Now subsequent reboots will not let tenant to go into INOPERATIVE state