Bug 1290750
Summary: | [vdsm] [RHEL6 -> RHEL7 upgrade] failed vdsmd - Modules sebool are not configured | ||
---|---|---|---|
Product: | [oVirt] vdsm | Reporter: | Jiri Belka <jbelka> |
Component: | General | Assignee: | Yaniv Bronhaim <ybronhei> |
Status: | CLOSED WONTFIX | QA Contact: | Aharon Canan <acanan> |
Severity: | high | Docs Contact: | |
Priority: | unspecified | ||
Version: | 4.17.11 | CC: | bugs, danken, dfediuck, jbelka, oourfali, pstehlik, ybronhei |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | infra | ||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2015-12-31 11:17:16 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | Infra | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Jiri Belka
2015-12-11 10:25:08 UTC
Isn't the bug about el6->el7 upgrade, and unrelated to (live) VM migration? Prior upgrade: vdsm-4.16.30-0.el6.x86_64 But I cannot see to which version it was upgraded to. Can you specify it, and find yum.log on the host, to see if the upgrade has succeeded? I'm not sure whether we have tried an el6->el7 upgrade of Vdsm before. Bug tickets must have version flags set prior to targeting them to a release. Please ask maintainer to set the correct version flags and only then set the target milestone. (In reply to Dan Kenigsberg from comment #2) > Isn't the bug about el6->el7 upgrade, and unrelated to (live) VM migration? Yes it is el6->el7, corrected. Not related to any migration as vdsmd is not running yet. > Prior upgrade: vdsm-4.16.30-0.el6.x86_64 > But I cannot see to which version it was upgraded to. Can you specify it, > and find yum.log on the host, to see if the upgrade has succeeded? It is written there :) vdsm-4.17.12-11.git263129f.el7.centos.noarch > I'm not sure whether we have tried an el6->el7 upgrade of Vdsm before. We've started this POC migration/upgrade path now as it was requested by a customer. vdsm-4.17.12-11.git263129f.el7.centos.noarch is not mentioned in the attached logs. Can you find yum.log (which should show whether %postun failed to confifure sebool)? Can you share `rpm -qa |grep vdsm` after upgrade? (In reply to Dan Kenigsberg from comment #5) > vdsm-4.17.12-11.git263129f.el7.centos.noarch is not mentioned in the > attached logs. Can you find yum.log (which should show whether %postun > failed to confifure sebool)? Can you share `rpm -qa |grep vdsm` after > upgrade? iiuc postun won't be called as there's only "if [ "$1" -ge 1 ];" and this was upgrade thus it is '2', isn't it (1 for installed one and 1 for newer package). I don't see any '--scripts' related info in yum.log: ~~~ # grep vdsm /var/log/yum.log Dec 09 13:48:30 Installed: vdsm-python-zombiereaper-4.16.30-0.el6.noarch Dec 09 13:48:43 Installed: vdsm-python-4.16.30-0.el6.noarch Dec 09 13:48:43 Installed: vdsm-xmlrpc-4.16.30-0.el6.noarch Dec 09 13:48:49 Installed: vdsm-yajsonrpc-4.16.30-0.el6.noarch Dec 09 13:48:50 Installed: vdsm-jsonrpc-4.16.30-0.el6.noarch Dec 09 13:50:51 Installed: vdsm-4.16.30-0.el6.x86_64 Dec 09 13:50:51 Installed: vdsm-cli-4.16.30-0.el6.noarch Dec 11 12:36:01 Installed: vdsm-infra-4.17.12-11.git263129f.el7.centos.noarch Dec 11 12:36:02 Updated: vdsm-python-4.17.12-11.git263129f.el7.centos.noarch Dec 11 12:36:02 Updated: vdsm-xmlrpc-4.17.12-11.git263129f.el7.centos.noarch Dec 11 12:36:03 Updated: vdsm-yajsonrpc-4.17.12-11.git263129f.el7.centos.noarch Dec 11 12:36:03 Updated: vdsm-jsonrpc-4.17.12-11.git263129f.el7.centos.noarch Dec 11 12:36:53 Updated: vdsm-4.17.12-11.git263129f.el7.centos.noarch Dec 11 12:36:54 Updated: vdsm-cli-4.17.12-11.git263129f.el7.centos.noarch Dec 11 12:37:01 Erased: vdsm-python-zombiereaper-4.16.30-0.el6.noarch ~~~ ~~~ # rpm -qa vdsm\* vdsm-4.17.12-11.git263129f.el7.centos.noarch vdsm-infra-4.17.12-11.git263129f.el7.centos.noarch vdsm-yajsonrpc-4.17.12-11.git263129f.el7.centos.noarch vdsm-python-4.17.12-11.git263129f.el7.centos.noarch vdsm-jsonrpc-4.17.12-11.git263129f.el7.centos.noarch vdsm-xmlrpc-4.17.12-11.git263129f.el7.centos.noarch vdsm-cli-4.17.12-11.git263129f.el7.centos.noarch ~~~ ybronhei@ was part of discussion about this issue, please if needed consult with him. our chat about that issue was not published anywhere. copying my explanation for that case - ''' It can happen only if just before that upgrade you enabled back selinux. When you install vdsm and selinux is disabled, vdsm can't set selinux booleans - therefore vdsm-tool configure skip that part. next time you will restart vdsmd it will check again the selinux status and then check if the vdsm required booleans are set, if not it will fail to start until you will run vdsm-tool configure or vdsm-tool configure --module=sebool . In our case here I think that just before the upgrade you enabled selinux back and before that it ran when selinux was disabled. ''' In yum log you won't see scripts but the versions you use. During upgrade we do not try to configure selinux booleans. only explicit call to vdsm-tool configure will do that when selinux is enforced. I can configure sebools after upgrade but Im not sure when in the upgrade flow selinux gets enabled. so we might end up again with the same situation if the upgrade is done, then the host is restarted with enforcing but vdsm can't start because it ran the configure while selinux was disabled. this patch will try to reconfigure sebools automatically after upgrade - https://gerrit.ovirt.org/50382 I didn't want to do that because it changes the environment underneath without notifying to the user at all. I also suggest to consider that after rhel6 upgrade to rhel7 we will instruct the users to perform reinstallation for the host Any comments? Pavel/Jiri - I think that if after upgrade of RHEL the selinux status is changing, and not remaining as it was before upgrade, then it is a RHEL bug. If that's the case, please open a RHEL bug, and make this bug a dependency. (In reply to Oved Ourfali from comment #9) > Pavel/Jiri - I think that if after upgrade of RHEL the selinux status is > changing, and not remaining as it was before upgrade, then it is a RHEL bug. > If that's the case, please open a RHEL bug, and make this bug a dependency. dfediuck@ sent recently an email stating that fed-up style migration is abandoned. could you manage with him if this BZ is still relevent? thx. (ad selinux _during_ upgrade - imo they have reason to do this; after upgrade selinux is enforcing as it used to be before upgrade.) (In reply to Jiri Belka from comment #10) > (In reply to Oved Ourfali from comment #9) > > Pavel/Jiri - I think that if after upgrade of RHEL the selinux status is > > changing, and not remaining as it was before upgrade, then it is a RHEL bug. > > If that's the case, please open a RHEL bug, and make this bug a dependency. > > dfediuck@ sent recently an email stating that fed-up style migration is > abandoned. could you manage with him if this BZ is still relevent? thx. > Doron? > (ad selinux _during_ upgrade - imo they have reason to do this; after > upgrade selinux is enforcing as it used to be before upgrade.) Jiri - What do you mean? As far as I understand it was disabled before and enabled after. Am I wrong? > > (ad selinux _during_ upgrade - imo they have reason to do this; after
> > upgrade selinux is enforcing as it used to be before upgrade.)
>
> Jiri - What do you mean?
> As far as I understand it was disabled before and enabled after. Am I wrong?
Yes are probably confused - it was enforcing, during uprade it is disabled as kernel param and after upgrade it is as it used to be originally - ie. enforcing. IMO the upgrade-migration has its own reason why it puts 'enforcing=0' as kernel param (as visible in my above original descr).
(In reply to Jiri Belka from comment #12) > > > (ad selinux _during_ upgrade - imo they have reason to do this; after > > > upgrade selinux is enforcing as it used to be before upgrade.) > > > > Jiri - What do you mean? > > As far as I understand it was disabled before and enabled after. Am I wrong? > > Yes are probably confused - it was enforcing, during uprade it is disabled > as kernel param and after upgrade it is as it used to be originally - ie. > enforcing. IMO the upgrade-migration has its own reason why it puts > 'enforcing=0' as kernel param (as visible in my above original descr). So we might need to "remember" that selinux was enabled, and creating proper rules when upgrading even though selinux is still disabled? Yaniv? the "upgrade/migration" as one-time boot via a kernel/ramdisk generated with redhat-upgrade-tool, only this one-time boot selinux is disabled. i don't know what exactly "vdsm-tool configure --module sebool" does but this solved the issue. maybe it is just an issue of relabeling dirs context? No its not setting any labeling things. it sets selinux booleans that vdsm requires - you can read about it and see the implantation in lib/vdsm/tool/configurators/sebool.py if selinux is disabled this can't be set. but if selinux is enabled and the booleans are not set, vdsm won't start until you'll set it (which you do by using vdsm-tool) so the issue here was that vdsm ran without selinux, and after upgrade failed to run as it didn't trigger vdsm-tool configure for sebool module when selinux turns on. maybe we should keep the consideration of taking https://gerrit.ovirt.org/#/c/50382/1/init/vdsmd_init_common.sh.in |