I'm trying to create a genesis block with the command:
peer channel create -c myc
following the install_instantiate.md file.
However I keep getting an error-message that there is no ordering service endpoint created. Somebody who can help me with this please?
I guess you are working with Fabric 1.0.0-alpha. There
the API has been changed so that you have to pass an orderer now.
peer channel create -o orderer0:7050 -c mychannel
Please have a look at the following document:
https://fabric-rtd.readthedocs.io/en/latest/getting_started.html#create-channel
Have you tried to specifiy the orderer address ?
If you are using docker :
CORE_PEER_COMMITTER_LEDGER_ORDERER=orderer:7050 peer channel create -c myc
If it doesn't work, try the Getting Setup, or see the Troubleshooting section
Related
I saw few other posts (in particular this one) about it but there are from last year. I still have this issue right now. I opened the Preview features from the User settings but I can't turn off this feature.
My pipelines use SSH connection to run some commands on a virtual machine (basically, pull a Docker image).
All my pipelines are failing. How can I fix it or update the SSH connections?
Update
I set up the Service connection
and I use it in my pipelines with this YAML code:
- task: SSH#0
displayName: 'SSH: stop shinyproxy'
inputs:
sshEndpoint: $(server)
commands: |
echo $(pwd) | sudo -S docker stop shinyproxy
failOnStdErr: false
continueOnError: true
All pipelines, new and old, get the same error
##[error]Failed to connect to remote machine. Verify the SSH service connection details. Error: Error: All configured authentication methods failed
at doNextAuth (/home/vsts/work/_tasks/SSH_91443475-df55-4874-944b-39253b558790/0.213.0/node_modules/ssh2/lib/client.js:803:21)
at tryNextAuth (/home/vsts/work/_tasks/SSH_91443475-df55-4874-944b-39253b558790/0.213.0/node_modules/ssh2/lib/client.js:993:7)
at USERAUTH_FAILURE (/home/vsts/work/_tasks/SSH_91443475-df55-4874-944b-39253b558790/0.213.0/node_modules/ssh2/lib/client.js:373:11)
at 51 (/home/vsts/work/_tasks/SSH_91443475-df55-4874-944b-39253b558790/0.213.0/node_modules/ssh2/lib/protocol/handlers.misc.js:337:16)
at Protocol.onPayload (/home/vsts/work/_tasks/SSH_91443475-df55-4874-944b-39253b558790/0.213.0/node_modules/ssh2/lib/protocol/Protocol.js:2025:10)
at AESGCMDecipherNative.decrypt (/home/vsts/work/_tasks/SSH_91443475-df55-4874-944b-39253b558790/0.213.0/node_modules/ssh2/lib/protocol/crypto.js:987:26)
at Protocol.parsePacket [as _parse] (/home/vsts/work/_tasks/SSH_91443475-df55-4874-944b-39253b558790/0.213.0/node_modules/ssh2/lib/protocol/Protocol.js:1994:25)
at Protocol.parse (/home/vsts/work/_tasks/SSH_91443475-df55-4874-944b-39253b558790/0.213.0/node_modules/ssh2/lib/protocol/Protocol.js:293:16)
at Socket. (/home/vsts/work/_tasks/SSH_91443475-df55-4874-944b-39253b558790/0.213.0/node_modules/ssh2/lib/client.js:713:21)
at Socket.emit (node:events:527:28) {
level: 'client-authentication'
I have never had this issue before.
Based on the other post, highlighted by Antonia, the solution has to be applied on the Ubuntu machine.
To fix it, open Terminal and edit /etc/ssh/sshd_config and, at the end of it, add this line
/etc/ssh/sshd_config
After that, restart. It is working for me.
my software started saying my giver is not deployed, but it is deployed, obviously.
I guess this is about endpoints. Could you please help me wrap my head around what's to be fixed? THx a lot!
everdev contract deploy FarmingCalculator.abi.json -n dev -s dev_giver -v 250000000 -d _randomNonce:13
Configuration
Network: dev (eri01.net.everos.dev, rbx01.net.everos.dev, gra01.net.everos.dev)
Signer: dev_giver (public 191fb7466066419bb44da39d58c2c1161255da87453b0447dc2500a4927b57db)
Address: 0:9781a951a6c8c8961e7f5467e308c6983189c3746557cf5cc5739d5a2dbc39a2 (calculated from TVC and signer public)
Error: Giver 0:5236a17bd571ad5cf8acda004158e94f97d61833c3a11484e23dd9e97374f9f7 has no code deployed."
try this:
everdev network credentials dev --project ""Project Id""
(Don't forget to install the latest everdev version and you need to be athorized)
When I execute the following command
sudo mn --controller remote,ip=127.0.0.1 --topo=single,4
ONOS shows the following Error
Error while processing message from [127.0.0.1:54080
DPID[00:00:00:00:00:00:00:01]]state WAIT_METER_FEATURES_REPLY
io.netty.handler.codec.DecoderExpeption:
org.projectfloodlight.openflow.exeptions.OFParseError: Wrong length:
Expected=40(40), got=32
Kindly Help, How to resolve....?
This is a problem, most likely, related to the OpenFlow version. As #ikerfah said, try to define OpenFlow 1.3 in the mininet command, like:
$ sudo mn --controller=remote,ip=127.0.0.1,port=6653 --switch=ovs,protocols=OpenFlow13 --topo=tree,depth=1,fanout=2
I am new to aws I was trying to create a pipeline. But it turns this error once it builds
[Container] 2020/05/23 04:32:56 Phase context status code: Decrypted Variables Error Message: parameter does not exist: JWT_SECRET
Even though the token was stored by running this command
s ssm put-parameter --name JWT_SECRET --value "myjwtsecret" --type SecureString
I tried to fix that by adding this line buildspec.yml post build commands. but still does not fix the problem
- kubectl set env deployment/simple-jwt-api JWT_SECRET=$JWT_SECRET
My buildspec.yml contain this added line to configure the pass of my jwt secret to the app
env:
parameter-store:
JWT_SECRET: JWT_SECRET
Check my github repos for more details about the code
Also once I run this under cmd to test the api endpoints kubectl get services simple-jwt-api -o wide I have got this error
Error from server (NotFound): services "simple-jwt-api" not found
Well it is obvious since the pipeline failed to build. Please how can I fix it?
In my case I go this error while I have created my stack in different region than the cluster. So whenever it search for the variable it does not find it. So, be carful to point to the same region in every creation action :).
The best solution I found was to add a region tag when declaring the env variables.
aws ssm put-parameter --name JWT_SECRET --value "myjwtsecret" --type SecureString --region <your-cluster-region>
I also encountered this same issue,
Changing the kubectl version in the buildspec.yml file worked for me
- curl -LO https://dl.k8s.io/release/v<YOUR_KUBERNETES_VERSION>/bin/linux/amd64/kubectl
# Download the kubectl checksum file
- curl -LO "https://dl.k8s.io/v<YOUR_KUBERNETES_VERSION>/bin/linux/amd64/kubectl.sha256"
Note that the <YOUR_KUBERNETES_VERSION> must be the same with what you have on your created cluster dashboard.
Fabric 1.4.3 version. Blockchain network with 1 Oderer (solo) + 1 Org, running on Docker.
Trying to instantiate chaincode, due to PANIC error on PEER0, and peer crashes.
Impossible to instantiate chaincode, because PEER0 crashes doing the process.
At CLI docker prompt, I did this command sequence:
1) $> peer channel create -o $ORDERERNAME -c $CHANNELNAME -f $CONFIGTXFOLDER/devchannel.tx --tls --cafile=$ORDERER_TLSCACERT
Result in Cli: UTC [cli.common] readBlock -> INFO 04e Received block: 0
2) $> peer channel join -o $ORDERERNAME -b $CONFIGTXFOLDER/devgenesis.block --tls --cafile=$ORDERER_TLSCACERT
Result in Cli: UTC [channelCmd] executeJoin -> INFO 03e Successfully submitted proposal to join channel
3) $> peer chaincode install -n $CHCODENAME -p $CHCODEPATH -v $CHCODEVERSION -l node --tls --cafile $ADMIN_PEER_TLSCACERT
Result in Cli: UTC [chaincodeCmd] install -> INFO 04a Installed remotely response:<status:200 payload:"OK" >
4) $> peer chaincode instantiate -C $CHANNELNAME -n $CHCODENAME -v $CHCODEVERSION -o $ORDERERNAME -c '{"Args":["init","a","100","b","200"]}' -P "AND ('GuaraniMSP.admin')" --tls --cafile $ORDERER_TLSCACERT --tlsRootCertFiles $CORE_PEER_TLS_ROOTCERT_FILE
Result before crash in PEER0:
UTC [gossip.state] commitBlock -> ERRO 87e Got error while committing(unexpected Previous block hash. Expected PreviousHash = [c87a4b77e4c790f78b0c2e3c97d97de9907a09daf5dc2f039c7e3b3e1440f5d1], PreviousHash referred in the latest block= [953e31164a84d6d1b9b446130d1e7d5af8ede818284e8fa7c315b2125b519e38]
github.com/hyperledger/fabric/common/ledger/blkstorage/fsblkstorage.(*blockfileMgr).addBlock
[...]
UTC [gossip.state] deliverPayloads -> PANI 87f Cannot commit block to the ledger due to unexpected Previous block hash. Expected PreviousHash = [c87a4b77e4c790f78b0c2e3c97d97de9907a09daf5dc2f039c7e3b3e1440f5d1], PreviousHash referred in the latest block= [953e31164a84d6d1b9b446130d1e7d5af8ede818284e8fa7c315b2125b519e38]
github.com/hyperledger/fabric/common/ledger/blkstorage/fsblkstorage.(*blockfileMgr).addBlock
[...]
/opt/go/src/runtime/asm_amd64.s:1333
panic: Cannot commit block to the ledger due to unexpected Previous block hash. Expected PreviousHash = [c87a4b77e4c790f78b0c2e3c97d97de9907a09daf5dc2f039c7e3b3e1440f5d1], PreviousHash referred in the latest block= [953e31164a84d6d1b9b446130d1e7d5af8ede818284e8fa7c315b2125b519e38]
github.com/hyperledger/fabric/common/ledger/blkstorage/fsblkstorage.(*blockfileMgr).addBlock
[...]
I opened an issue at Hyperledger Fabric JIRA about this situation, and I received the information that I need to clear out the environment to ensure there are no artifacts from prior trials.
Issue FABB-147 at Hyperledger Fabric (My logs are there).
I saw a problem documented close to my, but with differences, at peers get crash after anchor peer update
Now I have to certify that my Hyperledger Fabric environment is clear. But how?
Is there any documented procedure or checklist to verify if there are no artifacts from prior trials in Hyperledger Fabric?
If I suppress the ORDERER_GENERAL_GENESISFILE and ORDERER_GENERAL_GENESISPROFILE settings for orderer.yaml and docker-compose.yaml, will the orderer element start normally, and then the network will understand that it should use the genesis.block informed when creating the new channel?
Thanks in advance for your help.
Run this command docker system prune
Start Your network
again
hope this help u as it helped me
While not an answer to cleaning your environment, here's a possible solution to your underlying problem.
The peer channel create command will generate a $CHANNELNAME.block file in its current working directory. This is the block you need to use when running peer channel join, not a genesis block.
$> peer channel create ... -c $CHANNELNAME
$> peer channel join ... -b $CONFIGTXFOLDER/devgenesis.block
Will ruin your day by causing your peers to crash most of the time, and rarely work after recreating the ledger from a new genesis block. Try this instead:
$> peer channel create ... -c $CHANNELNAME
$> peer channel join ... -b $CHANNELNAME.block
I was using the genesis block from the system fabric network, loaded on the Ordener (from orderer.yaml or docker-compose.yaml), to join the channel, and that was wrong.
The source of my error was that I was using the system genesis block instead of using the genesis block generated in the peer channel create command.
I understood that the peer channel create command uses a transaction block model (.tx) as input, and as an output it generates a genesis block (.block) that must be used as input in the peer channel join command.
The correct sequence is:
Step 1) $> peer channel create -o $ORDERERNAME -c $CHANNELNAME -f $CONFIGTXFOLDER/devchanneltrack.tx --outputBlock $CHANNELFOLDER/devchannelgen.block --tls --cafile=$ORDERER_TLSCACERT
Step 2) $> peer channel join -o $ORDERERNAME -b $CHANNELFOLDER/devchannelgen.block --tls --cafile=$ORDERER_TLSCACERT
I made corrections to the scripts, and now I can join the channel. Then I did the installation and instantiation of new chaincodes on the channel, and they worked perfectly.