Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1263160

Summary: hosted-engine --deploy silently fails with xfs root partition
Product: [oVirt] otopi Reporter: Ivan Bulatovic <combuster>
Component: CoreAssignee: Sandro Bonazzola <sbonazzo>
Status: CLOSED DUPLICATE QA Contact: Ilanit Stein <istein>
Severity: urgent Docs Contact:
Priority: unspecified    
Version: masterCC: alonbl, bazulay, bugs, dougsland, ecohen, gklein, lsurette, rbalakri, yeylon
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard: infra
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-09-15 23:15:56 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:
Attachments:
Description Flags
ovirt-hosted-engine-setup log none

Description Ivan Bulatovic 2015-09-15 08:46:44 UTC
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 12:32:15 UTC
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 23:15:04 UTC
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 23:15:56 UTC

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