r-xr-xr-x 1 root root 949 Sep 12 18:31 componentmetadata.xml r-xr-xr-x 1 root root 873 Sep 12 18:32 componentmetadata.xml Since the ODA was freshly imaged with 18.7.0.0 there where just 18.7.0.0.0 and 18.6.0.0.0 patches pkgrepos]# ll db/* I tried several different pkgrepos]# odacli cleanup-patchrepo -cl -v pkgrepos]# odacli cleanup-patchrepo -cl -v pkgrepos]# odacli cleanup-patchrepo -cl -comp db -v pkgrepos]# odacli cleanup-patchrepo -cl -v 18.3.16ĭCS-10200:Supplied version: 18.3.0.0 is invalid.Įxcept the last one, all cleanup jobs run successfully, but still there are all pkgrepos]# ll orapkgs/clones/ These are the clones I ~]# cd pkgrepos]# ll orapkgs/clones/ But I did not manage to delete a single DB clone. It states, and the documentation does too, the options are all optional but in fact this isn’t pkgrepos]# odacli cleanup-patchrepoĭCS-10001:Internal error encountered: Invalid Input Parameter to delete the clones and patch component. First, let’s have a look at the ~]# odacli cleanup-patchrepo -hĬomponents: You can have a look at all the other new features in the Realase Notes.įor now, I’ll outline the usage of the cleanup feature. The most useful new feature in my opinion is the “Repository Cleanup”. So in case you own similar systems with disks from newer hardware models, it might be a good idea to modify this metadata file beforehand.Ī couple of days ago, Oracle released version 18.7 for the Oracle Database Appliance. But the metadata does not reflect that compatibility.Īfter making that change to the metadata file, the second run of the “odacli update-storage” went smooth and finally upgraded the firmware of the three remaining disks. At that time, ODA X8 generation was the current model and so the customer got NVMe disks for that generation, which is supported I must say. I could do that because the three disks in question were installed as the last storage upgrade. So I simply added my ODA X7-2 as a supported product by copying the corresponding line from another metadata ~]# cat /opt/oracle/oak/pkgrepos/firmwarecontroller/intel/0x0a54/qdv1rf35/7335940\:icdpc2dd2ora6.4t/metadata.xml Since the output file did not exist, I tried to run the command manually with the following cat /opt/oracle/oak/pkgrepos/firmwarecontroller/intel/0x0a54/vdv1rl05/7361456_icrpc2dd2ora6.4t/metadata.xml So obviously the firmware update went wrong for the disk. 11:00:10,826 ERROR c.o.d.a.r.s.p.PatchingOperations: Error upgrading Controller c7 11:00:10,826 DEBUG c.o.d.c.u.CommonsUtils: Output : EMPTY CONTENT opt/oracle/dcs/log/jobfiles/c7storagecontrollerupgradeoutfile_]' opt/oracle/oak/pkgrepos/firmwarecontroller/intel/0x0a54/vdv1rl05/7361456_icrpc2dd2ora6.4t/metadata.xml, 11:00:08,188 DEBUG c.o.d.a.r.s.p.PatchingOperations: Getting the firmware file->/opt/oracle/oak/pkgrepos/firmwarecontroller/intel/0x0a54/vdv1rl05/7361456_icrpc2dd2ora6.4t/metadata.xml 11:00:08,188 DEBUG c.o.d.a.u.p.PatchingUtils: Patching metadata value for attribute : name is metadata.xml 11:00:08,188 DEBUG c.o.d.c.u.DCSFileUtils: Final filename: /opt/oracle/dcs/log/jobfiles/c7storagecontrollerupgradeoutfile_ 11:00:08,188 DEBUG c.o.d.c.u.DCSFileUtils: Appending id 245 to the file c7storagecontrollerupgradeoutfile 11:00:08,188 DEBUG c.o.d.c.u.f.FileOpsUtils: /opt/oracle/dcs/log/jobfiles already existed, skipping creation and permission setup 11:00:08,188 INFO c.o.d.a.r.s.p.PatchingOperations: Upgrading Controller->c7 So I checked the logfile /opt/oracle/dcs/log/dcs-agent.log which is quite lenghty and found the follwing lines (after several minutes and a couple of search patterns). Component Installed Version Available Version
0 Comments
Leave a Reply. |