Bug 1700857 - The EVM Service does not start , Failed to detect region_number , uninitialized constant False
Summary: The EVM Service does not start , Failed to detect region_number , uninitializ...
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat CloudForms Management Engine
Classification: Red Hat
Component: Appliance
Version: 5.10.1
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: GA
: 5.10.5
Assignee: Keenan Brock
QA Contact: John Dupuy
Red Hat CloudForms Documentation
URL:
Whiteboard:
Depends On:
Blocks: 1704905
TreeView+ depends on / blocked
 
Reported: 2019-04-17 13:41 UTC by Gellert Kis
Modified: 2019-11-06 20:00 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
5.10.1.2
Last Closed: 2019-05-21 13:58:05 UTC
Category: Bug
Cloudforms Team: ---
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Comment 3 Keenan Brock 2019-04-17 14:46:44 UTC
I have access to the machine and rails console seems to be behaving well (detecting the region and accessing the database well)

I'm digging into the errors

Comment 4 Keenan Brock 2019-04-17 15:56:51 UTC
Unfortunately that appliance is working for me.

I was able to run the status, I was able to run rails console, and able to startup the server
I was also able to properly detect the region

One error from the logs that I read here is: 

[----] E, [2019-04-17T15:09:20.503744 #1024:e08f58] ERROR -- : [MiqPassword::MiqPasswordError]: can not decrypt v2_key encrypted string  Method:[block (2 levels) in <class:LogProxy>]

If that log is present in the customer's site, then that would mean that the v2_key on disk is corrupted.
Copying that file from a working appliance to the non-working appliance should get it running again.
I would backup the current config/v2_key to config/v2_key.old - so you can diff the files and ensure that it was indeed the cause.
full path for the file: /var/www/miq/vmdb/config/v2_key

This would also cause a problem detecting the region (since it would not be able to connect to the database)


But to be honest, if the filesystem is corrupted, then scrapping and rebuilding the broken worker appliance seems like a better approach.
the v2_key file is not changed after initial configuration, so it seems at low odds at getting corrupted.


I'll look back at the logs and look for other issues, including the missing user error, but I'm kinda stuck since this appliance doesn't look like a reproducer.

Comment 10 Keenan Brock 2019-05-21 13:58:05 UTC
case was closed.
please let me know if we need to look further into this


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