Created attachment 684998 [details] log_collector Description of problem: After failed upgrade (see bug 902686) from SI26 to SF3 rollback has following complaints file ovirt-engine-upgrade_2013_01_21_17_08_18.log 2013-01-21 17:09:22::ERROR::rhevm-upgrade::1059::root:: Rolling back update 2013-01-21 17:09:22::ERROR::rhevm-upgrade::562::root:: PKI: cannot remove '/etc/httpd/conf.d/ssl.conf.tmp' 2013-01-21 17:09:22::ERROR::rhevm-upgrade::562::root:: PKI: cannot remove '/etc/pki/ovirt-engine/keys/engine.p12' 2013-01-21 17:09:22::ERROR::rhevm-upgrade::562::root:: PKI: cannot remove '/etc/pki/ovirt-engine/keys/apache.p12' 2013-01-21 17:09:22::ERROR::rhevm-upgrade::562::root:: PKI: cannot remove '/etc/pki/ovirt-engine/apache-ca.pem' 2013-01-21 17:09:22::ERROR::rhevm-upgrade::562::root:: PKI: cannot remove '/etc/pki/ovirt-engine/certs/apache.cer' 2013-01-21 17:09:22::ERROR::rhevm-upgrade::562::root:: PKI: cannot remove '/etc/pki/ovirt-engine/keys/apache.key.nopass' It seems that files actually do not exist in the system Version-Release number of selected component (if applicable): updgrade from SI26 to SF3 How reproducible: 100% Steps to Reproduce: 1. upgrade from si26 to sf3, upgrade will fail on database upgrade (see bug 902686) Actual results: rollback throws errors about files that cannot be removed - it seems that files do not exist in the system Expected results: rollback without errors Additional info:
Martin, any user impact beside ERROR log massages?
I don't think there was some other impact.
In RHEV-3.2, we changed our PKI infrastracture, and separated apache and ca keys. This means that during the upgrade from 3.1, We're creating those files specifically. In any case the 3.1 -> 3.2 upgrade fails, we're removing those files we creating. In this case, we're trying to remove those files, but since the upgrade didn't created them yet, it logs the failure. As those "Errors" in the log are just information for anyone that would like to debug the upgrade/rollback, I see no reason we should change this. I'd recommend closing this issue as not a bug (or, change the log, which I'm not sure is necessary).