Bug 1263160 - hosted-engine --deploy silently fails with xfs root partition
hosted-engine --deploy silently fails with xfs root partition
Status: CLOSED DUPLICATE of bug 1255638
Product: otopi
Classification: oVirt
Component: Core (Show other bugs)
master
x86_64 Linux
unspecified Severity urgent (vote)
: ---
: ---
Assigned To: Sandro Bonazzola
Ilanit Stein
infra
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-09-15 04:46 EDT by Ivan Bulatovic
Modified: 2016-02-10 14:33 EST (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-09-15 19:15:56 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Infra
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
ovirt-hosted-engine-setup log (109.50 KB, text/plain)
2015-09-15 08:32 EDT, Ivan Bulatovic
no flags Details

  None (edit)
Description Ivan Bulatovic 2015-09-15 04:46:44 EDT
Description of problem:

On RHEL7 with xfs filesystem on root partition (with default mount options), hosted-engine --deploy exits without any error messages in ovirt-hosted-engine-setup log.

# hosted-engine --deploy
[ INFO  ] Stage: Initializing
[ INFO  ] Generating a temporary VNC password.
[ INFO  ] Stage: Environment setup
          Continuing will configure this host for serving as hypervisor and create a VM where you have to install oVirt Engine afterwards.
          Are you sure you want to continue? (Yes, No)[Yes]: 
          Configuration files: []
          Log file: /var/log/ovirt-hosted-engine-setup/ovirt-hosted-engine-setup-20150915103503-isrltq.log
          Version: otopi-1.4.0_master (otopi-1.4.0-0.0.master.20150910103318.gitdd73099.el7)
          It has been detected that this program is executed through an SSH connection without using screen.
          Continuing with the installation may lead to broken installation if the network connection fails.
          It is highly recommended to abort the installation and run it inside a screen session using command "screen".
          Do you want to continue anyway? (Yes, No)[No]: Yes
[ INFO  ] Hardware supports virtualization
[ INFO  ] Bridge ovirtmgmt already created
[ INFO  ] Stage: Environment packages setup
[ INFO  ] Stage: Programs detection
[ INFO  ] Stage: Environment setup
# _

This is the last message printed in the log:

2015-09-15 10:26:56 DEBUG otopi.plugins.otopi.services.systemd plugin.execute:941 execute-output: ('/bin/systemctl', 'status', 'vdsmd.service') stderr:


2015-09-15 10:26:56 DEBUG otopi.plugins.ovirt_hosted_engine_setup.system.vdsmenv vdsmenv._connect:62 {'status': {'message': 'Done', 'code': 0}, 'info': {'systemProductName': 'xxxxxxxxxx', 'systemUUID': 'xxxxxxxxx', 'systemSerialNumber': 'xxxxxxx', 'systemFamily': 'xxxxxxxxxx', 'systemManufacturer': 'xxxxxx'}}
Version-Release number of selected component (if applicable):

With ext4 filesystem on / - hosted engine deployment executes without any issues, and continues with the following:

2015-09-15 08:26:18 DEBUG otopi.context context.dumpEnvironment:500 ENVIRONMENT DUMP - BEGIN
2015-09-15 08:26:18 DEBUG otopi.context context.dumpEnvironment:510 ENV OVEHOSTED_VDSM/vdscli=instance:'<ServerProxy for 0.0.0.0:54321/RPC2>'
2015-09-15 08:26:18 DEBUG otopi.context context.dumpEnvironment:514 ENVIRONMENT DUMP - END
2015-09-15 08:26:18 DEBUG otopi.context context._executeMethod:142 Stage late_setup METHOD otopi.plugins.ovirt_hosted_engine_setup.pki.vdsmpki.Plugin._late_setup


How reproducible:

Always.

Steps to Reproduce:
1. Install RHEL7 with root xfs filesystem
2. Run hosted-engine --deploy

Additional info:

Versions affected: 3.5.4, 3.6-snapshot
Comment 1 Ivan Bulatovic 2015-09-15 08:32:15 EDT
Created attachment 1073610 [details]
ovirt-hosted-engine-setup log

Just in case, here is the entire log. Bug is reproducible on CentOS 7 also.
Comment 2 Ivan Bulatovic 2015-09-15 19:15:04 EDT
Brain dump, this has nothing to do with the fs, last two commits in otopi fixed the issue. Updating from otopi-1.4.0-0.0.master.20150910103318.gitdd73099 to 20150914 resolved it.

How on earth I was able to reproduce this on 3.5 is beyond me, probably erased everything except otopi from the snapshot and installed everything back from the 3.5 repos. And today, updated otopi came in the middle of the two consecutive reinstalls, one with xfs and one with ext4 fs, hence a rash bz report.

OK, time to close this again by myself. I'm glad that this is sorted out anyway.
Comment 3 Ivan Bulatovic 2015-09-15 19:15:56 EDT

*** This bug has been marked as a duplicate of bug 1255638 ***

Note You need to log in before you can comment on or make changes to this bug.