Phala-pherry "invalid version"

Hi Phamily,

I thought to have finally configured the miner succesfully, with several issues in between (bad sgx driver, incompatible OS version, kernel, phala pruntime exiting due to dcap not being fetched properly, etc…)

I can see now that the status is running:

" khala-node              running                 176096 / 1257897
        kusama-node             running                 618154 / 11377902
        phala-pruntime          running
        phala-pherry            running                 khala 0 / kusama 0
--------------------------------------------------------------------------
        Status check                                            result
--------------------------------------------------------------------------
        khala chain synchronization status              Synchronizing, please wait, difference is 1081801
        kusama chain synchronization status             Synchronizing, please wait, difference is 10759748
        pherry synchronizes khala chain status          Synchronizing, please wait, difference is 176096
        pherry syncs kusama chain status                Synchronizing, please wait, difference is 618154

However, when i check the logs with docker logs phala-pherry:

Caused by:
        0: Invalid Metadata: Invalid version
        1: Invalid version
[2022-02-12T17:07:15Z INFO  pherry] Restarting...
[2022-02-12T17:07:15Z INFO  jsonrpsee_ws_client::transport] Connection established to target: Target { sockaddrs: [], host: "phala-node", host_header: "phala-node:9945", mode: Plain, path_and_query: "/" }
[2022-02-12T17:07:15Z INFO  pherry] bridge() exited with error: Connect to substrate

The container is restarting every 20 seconds, due to invalid version.

In order to try and solve this, i followed these instructions, found on discord:

1. Before the on-chain upgrade applies, keep the miner running and DO NOT do any operations
2. sudo docker kill phala-pherry
3. sudo docker pull phalanetwork/phala-pherry 
4. sudo phala start
5. Please not that you don't need to stop or restart pruntime. For the instructions in detail, please read the solo mining wiki.

restared the node and pherry, updated the docker to :latest, but issue remains the same.

Tried all the steps here:

Here’s the actual config:

phala sgx-test:


[email protected]:~# phala sgx-test
Sleep 12s
aesm_service[15]: [get_qpl_handle ../qe_logic.cpp:263] Cannot open Quote Provider Library libdcap_quoteprov.so.1 and libdcap_quoteprov.so

aesm_service[15]: The server sock is 0x561d77e71120
Detecting SGX, this may take a minute...
aesm_service[15]: Malformed request received (May be forged for attack)
aesm_service[15]: InKernel LE loaded
aesm_service[15]: InKernel LE loaded
aesm_service[15]: InKernel LE loaded
aesm_service[15]: InKernel LE loaded
aesm_service[15]: InKernel LE loaded
aesm_service[15]: InKernel LE loaded
aesm_service[15]: InKernel LE loaded
aesm_service[15]: InKernel LE loaded
✔  SGX instruction set
  ✔  CPU support
  ✔  CPU configuration
  ✔  Enclave attributes
  ✔  Enclave Page Cache
  SGX features
    ✘  SGX2  ✘  EXINFO  ✘  ENCLV  ✘  OVERSUB  ✘  KSS
    Total EPC size: 93.5MiB
✔  Flexible launch control
  ✔  CPU support
  ? CPU configuration
  ✔  Able to launch production mode enclave
✔  SGX system software
  ✔  SGX kernel device (/dev/sgx_enclave)
  ✔  libsgx_enclave_common
  ✔  AESM service
  ✔  Able to launch enclaves
    ✔  Debug mode
    ✔  Production mode
    ✔  Production mode (Intel whitelisted)

You're all set to start running SGX programs!
Generated machine id:
[207, 202, 231, 12, 167, 218, 156, 187, 15, 134, 218, 35, 23, 172, 167, 202]

CPU Cores:
6

Encoded runtime info:
[1, 0, 0, 0, 207, 202, 231, 12, 167, 218, 156, 187, 15, 134, 218, 35, 23, 172, 167, 202, 2, 33, 186, 112, 4, 134, 200, 75, 160, 7, 232, 131, 226, 187, 16, 65, 247, 102, 180, 37, 105, 104, 37, 230, 28, 186, 135, 221, 147, 117, 230, 63, 220, 8, 6, 0, 0, 0, 1, 0, 0, 0]
Testing RA...
aesm_service[15]: [ADMIN]EPID Provisioning initiated
aesm_service[15]: The Request ID is 12d0d93648734873487ce876384e7733
aesm_service[15]: The Request ID is 49d52bb9b97e409873477298334c8755
aesm_service[15]: [ADMIN]EPID Provisioning successful
isvEnclaveQuoteStatus = SW_HARDENING_NEEDED
advisoryURL = https://security-center.intel.com
advisoryIDs = "INTEL-SA-00334"
confidenceLevel = 2
[email protected]:~#
[email protected]:~# lsb_release -a && uname -r
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 18.04.6 LTS
Release:        18.04
Codename:       bionic
4.15.0-167-generic
[email protected]:~#

/dev# ls /dev | grep sgx
sgx
sgx_enclave
sgx_provision
[email protected]:/dev# ls /dev | grep sgx && ls /dev/sgx
sgx
sgx_enclave
sgx_provision
enclave  provision
[email protected]:/dev#

Looking at docker inspect for the pherry container, i can see this:


     "com.docker.compose.container-number": "1",
                "com.docker.compose.oneoff": "False",
                "com.docker.compose.project": "phala",
                "com.docker.compose.project.config_files": "docker-compose.yml",
                "com.docker.compose.project.working_dir": "/opt/phala",
                "com.docker.compose.service": "phala-pherry",
                "com.docker.compose.version": "1.29.2"

while the docker_compose.yml is at version: “3”

… idk if it’s related or how to properly fix it.

Edit: Modifying the config.v2.json
“com.docker.compose.version”: "1.29.2
"
to version “3” doesn’t 'change anything.

Anyone has encountered anything similar?

Thanks

Hi, I suggest you fill out this form so the technical team will review the ticket and a member will get back to you: https://forms.gle/RVvxoSgLMLVBvnVg6

Thanks Cappex,

Done.

Hi, Minat0ri
I have same issue. Succeeded resolve it?

Hi Ch0no,

Unfortunately not. New machine, different OS and kernel (the ones recommended in the wiki), followed github instructions … sgx-test is giving all tests OK, bios is up to date, secure boot disabled, uefi enabled, sgx enabled… confidence level is 1…i’m out of ideas. :)

Also, i filled in the form, but nobody cared to respond

Hi,
Also did it on all kind of machines, including recommended rented Vultr.
Getting same result. No answer from support. Absolutely unprofessional behavior.
Looks like Ponzi scheme.

Hi,
Try these ways.
One of my servers started to work.