Ok, I added a new disk (well old actually, but new for the machine) to my Oracle VM server. It discovered it (or do it manually) and I wanted to create a new repository on it. Unfortunately it came with the following error:
Server error: 'The backing device /dev/mapper/3500a075109146bee is not allowed to contain partitions'
When you run Oracle Grid 12c ‘cluvfy stage -pre crsinst’ on Linux 7 (Oracle Enterprise Linux 7.2 in my case) you will get the following error:
Starting check for /dev/shm mounted as temporary file system ... ERROR: PRVE-0421 : No entry exists in /etc/fstab for mounting /dev/shm PRVE-0421 : No entry exists in /etc/fstab for mounting /dev/shm PRVE-0421 : No entry exists in /etc/fstab for mounting /dev/shm PRVE-0421 : No entry exists in /etc/fstab for mounting /dev/shm Check for /dev/shm mounted as temporary file system failed
When you do a ‘df -h’ you will see that ‘/dev/shm’ actually is mounted:
Filesystem Size Used Avail Use% Mounted on devtmpfs 24G 0 24G 0% /dev tmpfs 24G 0 24G 0% /dev/shm
This is due to a bug (Doc ID 2065603.1) which comes from the case that the cluvfy check does not check the actual mount of the file system, but looks for the persistence line of this mount in ‘/etc/fstab’ like it did in Linux 6. In Linux 7 you get this tmpfs mount by default.
Goal: To add new larger disk to LVM, move data and remove old smaller one
When using Oracle VM in my work, a disk can be enlarged in Oracle VM manager for a virtual machine. But because of an internal loop-mount on the XEN hypervisor level, the disk-file which is presented to the virtual machine as a disk, is not able to ‘pass on’ it’s resize information to the OS. This requires an unmount and mount of the disk-file on hypervisor level, or in simple words: a reboot of the virtual machine… yikes! Continue reading
During the installation of Oracle 12c (12.1) I encountered the following error:
Error in invoking target 'irman ioracle' of makefile
'/u01/app/oracle/product/12.1.0/dbhome_1/rdbms/lib/ins_rdbms.mk'.
See '/u01/app/oraInventory/logs/installActions2015(...).log' for details.
Inside the logfile the following error is encountered:
INFO: collect2: ld terminated with signal 9 [Killed]
According to metalink doc 2040972.1 this is due to less memory available (in a VM environment). Continue reading
Download Reference for Oracle Database/GI PSU, SPU(CPU), Bundle Patches, Patchsets and Base Releases [ID 2118136.2]
https://support.oracle.com/epmos/faces/DocumentDisplay?id=2118136.2
THAT’S IT!
Happy patching!
It seems Oracle VM (<=3.3.1 *) and Oracle Linux (<= 5.10/6.6 *) both install ISOs and installed OS’s are not capable of booting when UEFI on the bare-metal hardware is used. I have seen two configurations now where this happened, one using a USB HDD drive capable providing a ISO to boot from as CD/DVD (Zalman ZM-VE300) and one HP iLO4 (http and local ISO) ‘remote’ booting. Continue reading
Read all about it in:
Oracle’s Security Alert for ShellShock.
It also lists Oracle products that are affected and do not have fixes available at this time…
Next Doc ID provides a listing of Oracle Linux patches (minimal Bash versions) required to resolve security vulnerabilities referenced by CVE-2014-6271 and CVE-2014-7169:
CVE-2014-6271 and CVE-2014-7169 Patch Availability Document for Oracle Linux (Doc ID 1930120.1).
These versions can be found, downloaded and YUM-ed from Oracle’s public yum server:
Happy patching…
When one is looking for the OpenSSL fix 1.0.1g for Oracle (Red Hat) Linux 6, the fixed package version is ‘1.0.1e-16.el6_5.7’. I think this a bit misleading, because OpenSSL 1.0.1e is subject to the bug (CVE-2014-0160). But from the Red Hat site: and Orcale MetaLink (MOS Note 1663998.1): “Version openssl-1.0.1e-16.el6_5.7 included a fix backported from openssl-1.0.1g“.
Some simple OS tests can produce a false-positive to heartbleed tests, becasue it could look only for text other than 1.0.1g.
To update to the ‘latest’ OpenSSL version, enable the [OL6_latest] repository en ‘yum update openssl’:
Setting up Update Process Resolving Dependencies --> Running transaction check ---> Package openssl.x86_64 0:1.0.1e-15.el6 will be updated ---> Package openssl.x86_64 0:1.0.1e-16.el6_5.7 will be an update --> Finished Dependency Resolution (etc...)
One can test if processes are using OpenSSL (not a heartbleed vulnerability test), by issuing one of these two following commands:
$ lsof | awk 'NR==1 || $0~/libssl.so.1.0.1e/' $ grep libssl.so.1.0.1 /proc/*/maps |cut -d/ -f3 |sort -u |xargs -r -- ps uf
OpenSSL Security Bug – Heartbleed / CVE-2014-0160
Document written at April the 18th, 2014…
Happy blee, uh, testing and patching!
Oracle Direct NFS (dNFS for short) is an NFS Client functionality integrated directly in the Oracle database software, optimizing the I/O (multi)path to your NFS storage without the overhead of the OS client/kernel software.
In this blog post I’ll describe network considerations, configurations and problems I have encountered during set-ups I have done.
dNFS uses two kinds of NFS mounts, the OS mount of NFS (also referred to as kernel NFS of kNFS) and, of course, Oracle’s database NFS mount, Direct NFS or dNFS.
According to [Direct NFS: FAQ (Doc ID 954425.1)] and [How to configure DNFS to use multiple IPs (Doc ID 1552831.1)], an kNFS mount is needed, although Oracle also claims it will also work on platforms that don’t natively support NFS, e.g. Windows… [Oracle Database 11g Direct NFS Client White Paper] (I don’t know how yet…).
Because dNFS implements multipath I/O internally, these is no need for bonding the interfaces to storage via active-backup or Link Aggregation. However, it’s good practice to bond the OS kNFS connection:
1 - eth0 -\
- bond0 - OS / kNFS
2 - eth1 -/
3 - eth2 --------- - dNFS path 1
4 - eth3 --------- - dNFS path 2
Above schematic shows [How to configure DNFS to use multiple IPs (Doc ID 1552831.1)]:
“A good solution could be to use bonded NICs (…) to perform the mount and then use unbonded NICs via dNFS for the performance critical path.” Continue reading
After updating Oracle Linux 6.3 to 6.4 or installing 6.4 from scratch will give a corrupt (blank) VNC remote console when launching the console from Oracle VM Manager:
As discussed in https://oss.oracle.com/ol6/docs/RELEASE-NOTES-U4-en.html#idp513536 and Oracle Support note ‘Corrupted VNC console in PVM guests running Oracle Linux 6.4 on Oracle VM’ (Doc ID 1537278.1), this issue is addressed in ‘X Window System Does Not Run in a PVHVM guest’.
If you uninstall the xorg-x11-cirrus driver from the guest OS, it will solve this issue.
# rpm -ev --nodeps xorg-x11-drv-cirrus
Reboot the guest OS after uninstalling.
Happy Launching!