User`s guide

• On virtualized systems that are built on Xen version 3, including all releases of Oracle VM 2 including

2.2.2 and 2.2.3, disk synchronization requests for ext3 and ext4 file systems result in journal corruption

with kernel messages similar to the following being logged:

blkfront: barrier: empty write xvda op failed

blkfront: xvda: barrier or flush: disabled

In addition, journal failures such as the following might be reported:

Aborting journal on device xvda1

The workaround is to add the mount option barrier=0 to all ext3 and ext4 file systems in the guest VM

before upgrading to UEK R3. For example, you would change a mount entry such as:

UUID=4e4287b1-87dc-47a8-b69a-075c7579eaf1 / ext3 defaults 1 1

so that it reads:

UUID=4e4287b1-87dc-47a8-b69a-075c7579eaf1 / ext3 defaults,barrier=0 1 1

This issue does not apply to Xen 4 based systems, such as Oracle VM 3. (Bug ID 17310816)

X.509 Certificates for module verification

The system reports a message similar to the following if there is a problem loading an in-kernel X.509

module verification certificate at boot time:

Loading module verification certificates

X.509: Cert 0c21da3d73dcdbaffc799e3d26f3c846a3afdc43 is not yet valid

MODSIGN: Problem loading in-kernel X.509 certificate (-129)

This error occurs because the hardware clock lags behind the system time as shown by hwclock, for

example:

# hwclock

Tue 20 Aug 2013 01:41:40 PM EDT -0.767004 seconds

The solution is to set the hardware clock from the system time by running the following command:

# hwclock --systohc

After correcting the hardware clock, no error should be seen at boot time, for example:

Loading module verification certificates

MODSIGN: Loaded cert 'Slarti: Josteldalsbreen signing key:

0c21da3d73dcdbaffc799e3d26f3c846a3afdc43'

(Bug ID 17346862)