Oracle MOS wget.sh fails with”Missing token”

While downloading Oracle patches from the new My Oracle Support interface, I generated the wget.sh download script and copied it to the server.

When I tried to run it:

./wget.sh

the download failed immediately with:

INFO: Output dir not specified, defaulting to current directory.
ERROR: Missing token. Provide -t <token> OR -T <token_file>.

The Problem

The generated wget.sh script now expects an Oracle Support download token.
The confusing part is that the patch download page itself may not show an obvious option to generate this token.

The script supports two ways of providing it:

-t <token>

or:

-T <token_file>

Using a token file is preferable because the token does not get stored directly in the shell command history.

Generate the Oracle Support Download Token

First, log in to My Oracle Support in your browser. While the authenticated MOS session is still active, open the Oracle token-generation endpoint: https://updates.oracle.com/Orion/GenToken/get_token

Save the token on the server:

vi /u01/install/patches/mos_token.txt

Paste the generated token into the file as a single line.

Set restrictive permissions:

chmod 600 mos_token.txt

Run wget.sh With the Token

Tun wget with token:

./wget.sh -T /u01/install/patches/mos_token.txt

The download should now start normally.

Alternative: Pass the Token Directly

The script also allows passing the token directly:

./wget2.sh -t '<token>'

However, I prefer using:

-T <token_file>

because putting the token directly on the command line can expose it through shell history or process information.

Remove the Token After the Download

Once the required patches are downloaded, remove the temporary token file:

rm -f /u01/install/patches/mos_token.txt

How to Change the Domain Name of an Oracle RAC Cluster

Changing the domain name of an existing Oracle RAC cluster requires more than changing the hostname at the operating-system level. The old domain may be referenced in DNS, operating-system configuration, Oracle Net files, VIP configuration, and SCAN resources.

This article describes the steps for changing the domain name of a two-node Oracle RAC cluster.

Example

Assume the existing nodes are:

rac1.olddomain.com
rac2.olddomain.com

and they need to be changed to:

rac1.newdomain.com
rac2.newdomain.com

The SCAN name changes from rac-scan.olddomain.com to rac-scan.newdomain.com.


1. Stop the databases

Before making the domain-name changes, stop all database instances running (if any) on the cluster.

For example:

srvctl stop database -d <DB_UNIQUE_NAME>

Verify:

srvctl status database -d <DB_UNIQUE_NAME>

2. Update DNS

Update the DNS records to reflect the new domain name.

Review the records for:

rac1.newdomain.com
rac2.newdomain.com
rac1-vip.newdomain.com
rac2-vip.newdomain.com
rac-scan.newdomain.com

Make sure the IP addresses themselves remain mapped correctly.

For SCAN, verify that the new SCAN name resolves to all configured SCAN IP addresses.

For example:

nslookup rac-scan.newdomain.com

or:

dig rac-scan.newdomain.com

3. Update the operating-system configuration

Review the operating-system files that may contain the old domain.

Depending on the Linux distribution and configuration, this may include:

/etc/hosts
/etc/resolv.conf
/etc/sysconfig/network
/etc/sysctl.conf

For example, /etc/resolv.conf may contain:

search olddomain.com

which should be changed to:

search newdomain.com

Similarly, /etc/sysconfig/network may contain:

DOMAINNAME=olddomain.com

and /etc/sysctl.conf may contain:

kernel.domainname=olddomain.com

4. Review Oracle Net configuration

Check the Oracle Grid Infrastructure and Database Oracle homes for references to the old domain.

Review files such as:

<GI_HOME>/network/admin/tnsnames.ora
<DB_HOME>/network/admin/tnsnames.ora
<GI_HOME>/network/admin/listener.ora
<DB_HOME>/network/admin/sqlnet.ora

Search for the old domain:

grep -Ri "olddomain.com" <GI_HOME>/network/admin
grep -Ri "olddomain.com" <DB_HOME>/network/admin

Check for IFILE

tnsnames.ora may not contain the actual entry directly. It can reference another Oracle Net configuration file using IFILE.

For example:

IFILE=/path/to/additional_tnsnames.ora

Check for it with:

grep -i '^[[:space:]]*IFILE' <GI_HOME>/network/admin/tnsnames.ora
grep -i '^[[:space:]]*IFILE' <DB_HOME>/network/admin/tnsnames.ora

If an IFILE is configured, review the referenced file for the old domain as well.


5. Change the operating-system hostname

Check the current hostname:

hostname
hostname -f
hostname -s
hostnamectl

For example:

hostname -f
rac1.olddomain.com
hostname -s
rac1

Change the hostname to the new FQDN:

hostnamectl set-hostname rac1.newdomain.com

Repeat the operation on the second node:

hostnamectl set-hostname rac2.newdomain.com

Verify:

hostname
hostname -f
hostname -s

The expected result should be similar to:

hostname -f
rac1.newdomain.com
hostname -s
rac1

The FQDN changes, while the RAC node short name remains the same.


6. Check the VIP configuration before modifying it

Oracle’s procedure includes changing the VIP when the VIP resource itself contains the old domain name.

However, this step may not be necessary in every RAC configuration.

Check the existing VIP configuration first:

<GI_HOME>/bin/srvctl config vip -node rac1
<GI_HOME>/bin/srvctl config vip -node rac2

For example, if the output is:

VIP exists: network number 1, hosting node rac1
VIP Name: rac1-vip
VIP IPv4 Address: 192.168.1.101

Then Clusterware stores only the short VIP name. In this case, there is no old domain name stored in the VIP resource, and the VIP modification step can be skipped.

However, if the configuration shows:

VIP Name: rac1-vip.olddomain.com

stop the VIP and modify it to use the new domain:

# As GI owner
<GI_HOME>/bin/srvctl stop vip -node rac1 -force
# As root
<GI_HOME>/bin/srvctl modify vip \
-node rac1 \
-address rac1-vip.newdomain.com/255.255.255.0/<public_interface> \
-netnum 1

Then start and verify the VIP:

# As GI owner
<GI_HOME>/bin/srvctl start vip -node rac1
<GI_HOME>/bin/srvctl config vip -node rac1
<GI_HOME>/bin/srvctl status vip -node rac1

Repeat the same steps for the second node:

# As GI owner
<GI_HOME>/bin/srvctl stop vip -node rac2 -force
# As root
<GI_HOME>/bin/srvctl modify vip \
-node rac2 \
-address rac2-vip.newdomain.com/255.255.255.0/<public_interface> \
-netnum 1
# As GI owner
<GI_HOME>/bin/srvctl start vip -node rac2
<GI_HOME>/bin/srvctl config vip -node rac2
<GI_HOME>/bin/srvctl status vip -node rac2

The important point is: do not modify the VIP blindly. First check whether the Clusterware VIP resource actually contains the old domain name.


7. Check the current SCAN configuration

Check SCAN:

<GI_HOME>/bin/srvctl config scan

For example:

SCAN name: rac-scan.olddomain.com, Network: 1

Unlike the VIP configuration, SCAN commonly contains the full domain name.


8. Stop the SCAN listeners and SCAN

As the Grid Infrastructure owner:

<GI_HOME>/bin/srvctl stop scan_listener
<GI_HOME>/bin/srvctl stop scan

Verify that the resources are stopped if necessary:

<GI_HOME>/bin/srvctl status scan
<GI_HOME>/bin/srvctl status scan_listener

9. Change the SCAN name

After the DNS records for the new SCAN name are configured, modify SCAN.

Run the modification from root user:

<GI_HOME>/bin/srvctl modify scan -n rac-scan.newdomain.com

Verify the new configuration:

<GI_HOME>/bin/srvctl config scan

Expected:

SCAN name: rac-scan.newdomain.com, Network: 1

10. Update the SCAN listeners

Update the SCAN listener configuration:

<GI_HOME>/bin/srvctl modify scan_listener -u

Start the SCAN listeners:

<GI_HOME>/bin/srvctl start scan_listener

Then verify:

<GI_HOME>/bin/srvctl status scan
<GI_HOME>/bin/srvctl status scan_listener

All SCAN VIPs and SCAN listeners should be online.


11. Stop Oracle Clusterware

Once the required changes have been completed, stop Clusterware on all nodes:

# As root
<GI_HOME>/bin/crsctl stop cluster -all

Verify that Clusterware shuts down cleanly.


12. Restart the RAC nodes

Restart all RAC nodes using the normal operating-system procedure:

reboot

After the nodes return, verify the hostname:

hostname
hostname -f

Expected:

rac1.newdomain.com

Repeat the validation on every RAC node.


13. Validate node name resolution

Check the node names:

getent hosts rac1
getent hosts rac2

Expected:

192.168.1.1 rac1.newdomain.com
192.168.1.2 rac2.newdomain.com

14. Validate VIP resolution

Check the VIP names:

getent hosts rac1-vip
getent hosts rac2-vip

Expected:

192.168.1.101 rac1-vip.newdomain.com
192.168.1.102 rac2-vip.newdomain.com

Even when Clusterware stores the VIP as only rac1-vip, the operating system should resolve that short name correctly.


15. Validate SCAN resolution

First retrieve the exact SCAN configured in Clusterware:

srvctl config scan

Then validate that exact name:

getent hosts rac-scan.newdomain.com

or:

dig rac-scan.newdomain.com

For a three-SCAN-VIP configuration, all three expected IP addresses should resolve.

Example:

192.168.1.201 rac-scan.newdomain.com
192.168.1.202 rac-scan.newdomain.com
192.168.1.203 rac-scan.newdomain.com

16. Validate RAC node membership

Run:

olsnodes

The RAC node names should normally remain the same short names:

rac1
rac2

This was also the result after the domain change in the tested cluster.


17. Validate Clusterware resources

Run:

crsctl status resource -t

Verify that the important RAC resources are online, including:

ora.LISTENER.lsnr
ora.asm
ora.rac1.vip
ora.rac2.vip
ora.scan1.vip
ora.scan2.vip
ora.scan3.vip
ora.LISTENER_SCAN1.lsnr
ora.LISTENER_SCAN2.lsnr
ora.LISTENER_SCAN3.lsnr

After the tested domain change and restart, the node VIPs, three SCAN VIPs, SCAN listeners, ASM, and other Clusterware resources returned to ONLINE state.


18. Validate nodeapps and SCAN

Run:

srvctl config nodeapps -a
srvctl config scan

Confirm:

  • the node VIPs have the expected names and IP addresses
  • the SCAN uses the new domain
  • all expected SCAN VIP addresses are present

For example:

VIP Name: rac1-vip
VIP IPv4 Address: 192.168.1.101
VIP Name: rac2-vip
VIP IPv4 Address: 192.168.1.102

and:

SCAN name: rac-scan.newdomain.com

19. Run Cluster Verification Utility

Finally, run the appropriate Cluster Verification Utility checks.

For example:

cluvfy stage -post crsinst -n rac1,rac2

or the appropriate cluvfy command for your Grid Infrastructure version and environment.

Validate:

  • hostname resolution
  • node connectivity
  • public network
  • private interconnect
  • VIPs
  • SCAN
  • SCAN listeners
  • Clusterware
  • ASM
  • database connectivity

Also search the system and Oracle configuration for any remaining references to the old domain:

grep -Ri "olddomain.com" /etc 2>/dev/null
grep -Ri "olddomain.com" <GI_HOME>/network/admin 2>/dev/null
grep -Ri "olddomain.com" <DB_HOME>/network/admin 2>/dev/null

Review the results carefully rather than automatically replacing every occurrence.

Recovering failed GI 19c to 26ai upgrade

During the Oracle Grid Infrastructure upgrade from 19c to 26ai, the upgrade failed on rac1 while running:

/u01/app/23.0.0/grid/rootupgrade.sh

The failure occurred at:

2026/08/14 02:43:14 CLSRSC-595: Executing upgrade step 14 of 16: 'UpgradeCluster'.

After this point, rac1 entered a reboot loop. CRS autostart was disabled to stop the continuous reboots.

Later, starting Clusterware manually failed:

[root@rac1 trace]# crsctl start crs -wait
CRS-6705: Oracle Clusterware Release Version ('19.0.0.0.0') does not match Software Version ('23.0.0.0.0'). Oracle Clusterware cannot be started.
CRS-4000: Command Start failed, or completed with errors.

The cluster was left in a partially upgraded state: the cluster active version was still 19c, while rac1 had already been partially switched to the 26ai software.

1. Verify the cluster upgrade state

On the healthy node, rac2:

/u01/app/19.3.0/grid/bin/crsctl query crs activeversion -f

Output:

Oracle Clusterware active version on the cluster is [19.0.0.0.0].
The cluster upgrade state is [ROLLING UPGRADE].
The cluster active patch level is [1191252804].

This confirmed that the cluster active version had not yet been advanced to 26ai.

2. Restore rac1 configuration in OCR

From rac2, where the 19c Clusterware stack was still running:

/u01/app/19.3.0/grid/bin/clscfg -nodedowngrade-h rac1

Output:

clscfg: -nodedowngrade mode specified
clscfg: EXISTING configuration version 19 detected.
Successfully restored the node specific configuration from backup for host:[rac1]

This restores the pre-upgrade cluster metadata associated with rac1 in OCR as part of terminating the incomplete upgrade.

3. Downgrade the local Clusterware configuration on rac1

On rac1 as root, run the downgrade from the 26ai Grid home:

cd /u01/app/23.0.0/grid/crs/install./rootcrs.sh -downgrade -online

Output:

2026/08/14 04:38:58 CLSRSC-591: successfully downgraded Oracle Clusterware stack on this node
2026/08/14 04:38:59 CLSRSC-592: Run 'crsctl start crs' from home /u01/app/19.3.0/grid on each node to complete downgrade.

This reverts the local Clusterware configuration on rac1 to the previous GI release.

4. Start CRS from the 19c Grid home

On rac1:

/u01/app/19.3.0/grid/bin/crsctl start crs -wait

Clusterware now started successfully:

CRS-2676: Start of 'ora.cssd' on 'rac1' succeeded
CRS-2676: Start of 'ora.asm' on 'rac1' succeeded
CRS-2676: Start of 'ora.storage' on 'rac1' succeeded
CRS-2676: Start of 'ora.crsd' on 'rac1' succeeded...
CRS-4123: Oracle High Availability Services has been started.

5. Verify both nodes are back on 19c

/u01/app/19.3.0/grid/bin/crsctl check cluster -all
/u01/app/19.3.0/grid/bin/crsctl query crs softwareversion rac1
/u01/app/19.3.0/grid/bin/crsctl query crs softwareversion rac2

Both nodes returned:

19.0.0.0.0

However:

/u01/app/19.3.0/grid/bin/crsctl query crs activeversion -f

still showed:

Oracle Clusterware active version on the cluster is [19.0.0.0.0].
The cluster upgrade state is [ROLLING UPGRADE].

The rollback was therefore not yet complete.

6. Stop ASM rolling migration

As grid, connect to ASM:

sqlplus / as sysasm

Run:

ALTER SYSTEM STOP ROLLING MIGRATION;

7. Start the formal failed-upgrade downgrade

From the 26ai Grid home on rac1, as grid:

/u01/app/23.0.0/grid/gridSetup.sh -silent -downgrade -nodes rac1 -oldHome /u01/app/19.3.0/grid

In this case, gridSetup.sh generated the following root action:

/u01/app/23.0.0/grid/crs/install/rootcrs.sh -downgrade -auto

8. Stop CRS on the other node before the last-node operation

The first attempt at rootcrs.sh -downgrade -auto failed because rac2 was still running:

CRS-4402: The CSS daemon was started in exclusive mode but found an active CSS daemon on node rac2, number 2, and is terminating
CLSRSC-549: The root script cannot downgrade this node rac1 with last node operations because the Grid Infrastructure stack is up on at least one other cluster node.

Because rac1 was the node being processed with last-node downgrade operations, the GI stack on the other node had to be stopped temporarily.

On rac2 as root:

/u01/app/19.3.0/grid/bin/crsctl stop crs

9. Complete the last-node downgrade on rac1

On rac1 as root:

/u01/app/23.0.0/grid/crs/install/rootcrs.sh -downgrade -auto

This time the command can perform the required last-node operations because no other CSS daemon is active in the cluster.

10. Start the 19c Clusterware stack

After the downgrade succeeds, start rac1 explicitly from the 19c Grid home:

/u01/app/19.3.0/grid/bin/crsctl start crs -wait

Then restart the 19c stack on rac2, which was stopped for the last-node downgrade:

/u01/app/19.3.0/grid/bin/crsctl start crs -wait

11. Update Oracle Inventory on a failed node

Run the commands generated by gridSetup.sh as the grid owner.

Mark the failed 26ai Grid home as no longer being the CRS home:

$ /u01/app/23.0.0/grid/oui/bin/runInstaller -nowait -waitforcompletion -ignoreSysPrereqs -updateNodeList -silent CRS=false ORACLE_HOME=/u01/app/23.0.0/grid "CLUSTER_NODES=rac1" -doNotUpdateNodeList

Then register the 19c Grid home as the CRS home again:

$ /u01/app/23.0.0/grid/oui/bin/runInstaller -nowait -waitforcompletion -ignoreSysPrereqs -updateNodeList -silent CRS=true ORACLE_HOME=/u01/app/19.3.0/grid "CLUSTER_NODES=rac1" -doNotUpdateNodeList

These are not manually invented cleanup commands; they are the exact inventory commands produced by gridSetup.sh -downgrade for this failed upgrade.

12. Verify that the rollback is fully complete

Check both nodes:

/u01/app/19.3.0/grid/bin/crsctl check cluster -all

Verify their software versions:

/u01/app/19.3.0/grid/bin/crsctl query crs softwareversion rac1
/u01/app/19.3.0/grid/bin/crsctl query crs softwareversion rac2

Both should report:

19.0.0.0.0

Finally:

/u01/app/19.3.0/grid/bin/crsctl query crs activeversion -f

The rollback is complete when the cluster reports:

Oracle Clusterware active version on the cluster is [19.0.0.0.0].The cluster upgrade state is [NORMAL].

Only after reaching NORMAL should another GI upgrade attempt be started.