Hide Forgot
Description of problem: Trying to perform an upgrade from RHV 4.1.11 to RHV 4.2.3 which fails due to rh-postgresql95-postgresql unable to create pid file reporting permission denied errors. The RHV manager server runs with selinux in enforcing mode. Version-Release number of selected component (if applicable): ovirt-engine-4.1.11.2-0.1.el7.noarch ovirt-engine-setup-4.2.3.8-0.1.el7.noarch rh-postgresql95-postgresql-server-9.5.9-1.el7.x86_64 How reproducible: Always Steps to Reproduce: 1. yum update ovirt\*setup\* 2. engine-setup fails with below error [ INFO ] Upgrading PostgreSQL [ INFO ] PostgreSQL has been successfully upgraded, starting the new instance (rh-postgresql95-postgresql). [ ERROR ] Failed to execute stage 'Misc configuration': Failed to start service 'rh-postgresql95-postgresql' [ INFO ] Yum Performing yum transaction rollback [ INFO ] Rolling back to the previous PostgreSQL instance (postgresql). [ INFO ] Stage: Clean up Log file is located at /var/log/ovirt-engine/setup/ovirt-engine-setup-20180625105843-tdlb6n.log [ INFO ] Generating answer file '/var/lib/ovirt-engine/setup/answers/20180625110214-setup.conf' [ INFO ] Stage: Pre-termination [ INFO ] Stage: Termination [ ERROR ] Execution of setup failed 3. selinux errors reported due to [2] (check audit.log attachment) 4. Try to add the exception using ausearch -c 'postgres' --raw | audit2allow -M my-postgres semodule -i my-postgres.pp Actual results: Fails with permission denied errors. Expected results: To complete the update to RHV 4.2 Additional info:
This seems similar to bug 1518253. Can you try if running 'yum reinstall rh-postgresql95-runtime' resolves the issue?
(In reply to Ondra Machacek from comment #5) > This seems similar to bug 1518253. Can you try if running 'yum reinstall > rh-postgresql95-runtime' resolves the issue? Hi , It worked for me after doing a reinstall of the package again. Ribu
If it's indeed fully reproducible, might try again to debug this - and open a bug on selinux policy and/or postgresql. At the time, we didn't manage to reproduce, thus made bug 1518253 a known issue. If we fail to reproduce, but still want a workaround, that's an option too. Please see the discussion on bug 1518253 and try to provide as many relevant details as possible, including: What state did you start from? Is this a new system, or upgraded from older ones (seems like < 7.3 seems to be relevant)? Was it rebooted, or not, during an upgrade process? Etc.
(In reply to Yedidyah Bar David from comment #7) > If it's indeed fully reproducible, might try again to debug this - and open > a bug on selinux policy and/or postgresql. > > At the time, we didn't manage to reproduce, thus made bug 1518253 a known > issue. > > If we fail to reproduce, but still want a workaround, that's an option too. > > Please see the discussion on bug 1518253 and try to provide as many relevant > details as possible, including: > > What state did you start from? Is this a new system, or upgraded from older > ones (seems like < 7.3 seems to be relevant)? > > Was it rebooted, or not, during an upgrade process? > > Etc. Based on the requested information. This is a fresh 4.1 install on RHEL 7.4 . The machine didn't require a reboot as there was no kernel update. The error on first try received for selinux has been attached for your information.
Ribu, thanks for the update, but this isn't enough - we already have this information in bug 1518253. "Reproducible" means you can provide this: 1. Cleanly install a machine with RHEL 2. ? 3. ? 4. ? 5. Get this error If you can't, I will sadly have to close this as a duplicate. If you can attach a sosreport, it might help too - although, as I said, we already spent quite some time on a real machine demonstrating this behavior but still failed to reproduce. Thanks.
(In reply to Yedidyah Bar David from comment #10) > Ribu, thanks for the update, but this isn't enough - we already have this > information in bug 1518253. "Reproducible" means you can provide this: > > 1. Cleanly install a machine with RHEL > 2. ? > 3. ? > 4. ? > 5. Get this error > > If you can't, I will sadly have to close this as a duplicate. > > If you can attach a sosreport, it might help too - although, as I said, we > already spent quite some time on a real machine demonstrating this behavior > but still failed to reproduce. Thanks. I have tried to recreate the issue for which it works for me at the moment based on a fresh install of RHEL 7 followed by RHV 4.1 setup and upgrade to 4.2. The issue for Postgres SELinux related errors no longer shows up Ribu
Decided to "fix" by making engine-setup check this and fail, with a message suggesting a workaround. Still not sure how to reproduce. For how I "reproduced" and verified, see my comment starting with "Verified by:" in gerrit: https://gerrit.ovirt.org/93147 If someone does manage to come up with a real reproducer, not involving zeroing out file_contexts.subs , I suggest to reopen bug 1518599, if you want.
Merged on master
ok, ovirt-engine-4.3.0-0.0.master.20180828114844.git0bc18b1.el7.noarch upgraded from ovirt-engine-4.2.5.3-1.el7.noarch to ovirt-engine-4.3.0-0.0.master.20180828114844.git0bc18b1.el7.noarch
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHEA-2019:1085