组织Peer0加入Hyperledger Fabric通道时遇NOT_FOUND错误求助

错误日志详情 #

kubectl logs -n supplychain-net joinchannel-peer0-allchannel-r6lft --all-containers

加入通道allchannel
TLS状态为true
peer channel fetch 0 allchannel.block -o orderer1.supplychain-net:7050 -c allchannel --tls --cafile /opt/gopath/src/github.com/hyperledger/fabric/orderer/tls/orderer.crt
2024-11-11 13:00:13.898 UTC [grpc] InfoDepth -> DEBU 009 [core] [Channel #1] Channel switches to new LB policy "pick_first"
2024-11-11 13:00:13.898 UTC [grpc] InfoDepth -> DEBU 00a [core] [Channel #1 SubChannel #2] Subchannel created
2024-11-11 13:00:13.898 UTC [grpc] InfoDepth -> DEBU 00b [core] [Channel #1 SubChannel #2] Subchannel Connectivity change to CONNECTING
2024-11-11 13:00:13.898 UTC [grpc] InfoDepth -> DEBU 00c [core] [Channel #1 SubChannel #2] Subchannel picks a new address "orderer1.supplychain-net:7050" to connect
2024-11-11 13:00:13.898 UTC [grpc] InfoDepth -> DEBU 00d [core] pickfirstBalancer: UpdateSubConnState: 0xc00046e1a0, {CONNECTING <nil>}
2024-11-11 13:00:13.898 UTC [grpc] InfoDepth -> DEBU 00e [core] [Channel #1] Channel Connectivity change to CONNECTING
2024-11-11 13:00:13.901 UTC 001f DEBU [comm.tls] ClientHandshake -> Client TLS handshake completed in 1.513094ms remoteaddress=10.244.1.213:7050
2024-11-11 13:00:13.901 UTC [grpc] InfoDepth -> DEBU 00f [core] [Channel #1 SubChannel #2] Subchannel Connectivity change to READY
2024-11-11 13:00:13.901 UTC [grpc] InfoDepth -> DEBU 010 [core] pickfirstBalancer: UpdateSubConnState: 0xc00046e1a0, {READY <nil>}
2024-11-11 13:00:13.901 UTC [grpc] InfoDepth -> DEBU 011 [core] [Channel #1] Channel Connectivity change to READY
2024-11-11 13:00:13.901 UTC 0020 INFO [channelCmd] InitCmdFactory -> Endorser和orderer连接已初始化
2024-11-11 13:00:13.901 UTC 0021 DEBU [msp.identity] Sign -> 签名：明文: 0A9A090A1608051A0608DDFFC7B90622...933DB9B2652712080A021A0012021A00
2024-11-11 13:00:13.901 UTC 0022 DEBU [msp.identity] Sign -> 签名：摘要: 6193885D35D12596D97BEF566BF9634BAAC21C2485D1FC6661C32D86EA2E1189
2024-11-11 13:00:13.902 UTC 0023 INFO [cli.common] readBlock -> Expect block, but got status: &{NOT_FOUND}
Error: can't read the block: &{NOT_FOUND}
加入通道步骤
peer channel join -b allchannel.block

排查指引 #

• 确认通道是否已成功创建
  进入Orderer容器，检查通道数据目录是否存在：

  kubectl exec -n supplychain-net <orderer-pod-name> -- ls /var/hyperledger/production/orderer/channels/
  

  若未找到allchannel文件夹，说明通道未创建，需先执行通道创建命令。

• 检查通道名称匹配度
  确保peer channel fetch和join命令中的通道名称allchannel与创建时的名称完全一致，大小写、拼写无任何差异。

• 验证组织通道权限
  检查通道配置区块，确认当前Peer所属组织已被添加到通道成员列表中：

  # 从Orderer获取通道配置区块
  kubectl exec -n supplychain-net <orderer-pod-name> -- bash -c 'configtxlator proto_decode --input /var/hyperledger/production/orderer/channels/allchannel/channel_config.block --type common.Block | jq '.data.data[0].payload.data.config.channel_group.groups.Application.groups''
  

  若未找到对应组织，需更新通道配置添加该组织。

• 调整区块获取参数
  尝试使用newest参数获取最新区块，再执行join操作：

  peer channel fetch newest allchannel.block -o orderer1.supplychain-net:7050 -c allchannel --tls --cafile /opt/gopath/src/github.com/hyperledger/fabric/orderer/tls/orderer.crt
  peer channel join -b allchannel.block
  

• 校验TLS证书有效性
  确认--cafile指向的Orderer根证书与Orderer节点使用的证书一致，检查证书是否过期、路径是否正确。

• 检查Peer节点MSP配置
  确保Peer的MSP ID与通道配置中组织的MSP ID完全匹配，MSP目录下的证书、私钥路径正确且权限配置正常。

内容的提问来源于stack exchange，提问作者BlockchainGeek