-1

While reproducing steps from an interesting tutorial found online - Hyperledger Fabric 1.4 Tutorial - FabCar Sample Application, I have installed all Hyperledger Fabric binaries via the Curl command:

curl -sSL https://raw.githubusercontent.com/hyperledger/fabric/master/scripts/bootstrap.sh | bash -s

From the Command Prompt window one can see that, the scripts are run correctly leading to the pull of hyperledger-docker images.

Fabric Images

However, while launching the network from Visual Studio Code through the execution of

./startFabric.sh javascript from the fabcar sub-directory, one ends up with Fabric Images issues, which seems paradoxical. Fabric_Images_Issues

A similar issue has been encountered, while attempting to bring up the network via the command

./network.sh up

from the test-network sub-directory too.

Thus, any relevant feedback would indeed be appreciated, given an absence of rationale to justify this matter.

[EDIT]

As a matter of fact, a synchronization issue might have caused the previously reported issue, since fabric-samples v.1.4.9 is not found from Curl command documented online. Thus the script automatically installs the latest Fabric binaries 2.x.

To rule out this issue, I have re-executed the Curl command by specifying the version 1.4.4 instead. Therefore I can confirm, that the test-network sub-directory is not part of the Fabric binaries pertaining to the version 1.4x. Furthermore, before the installation of this binaries, I had removed all containers, and related images, yielding to:

docker_images

Back to the fabcar sub-directory, running: ./startFabric.sh javascript has still led to the following network issue :

binary_file_issue

What strikes me the most is:

  • firstly, that configtxlator can be found on my C:\Users\...\Documents\test4\fabric-samples\bin as opposed to the path highlighted on the command window.

  • secondly, I do not see the matter of version's incompatibility by scrutinizing byfn.sh:

docker_version_issue

Eventually, the manual amendment of IMAGETAG has not improved the situation.

Best

dark.vador
  • 619
  • 1
  • 6
  • 25

1 Answers1

1

You seem to have the different version.

In hyperledger/fabric-samples, the test-network does not exist in version 1.4. In other words, you are running the code for the master version of fabric-samples (currently the version 2.x version). Since you're running the 1.4 tutorial, run the commands based on the 1.4 documentation and code.

[NOTE] It is also very likely that the different version binary has been installed. In the fabric document, the version can be specified and downloaded, so to download the binary of the corresponding version, you need to execute the command including the input parameter (version) below.

curl -sSL https://raw.githubusercontent.com/hyperledger/fabric/master/scripts/bootstrap.sh | bash -s - 1.4.9 1.4.9 0.4.21

[EDIT - 1] Prior to the explanation, in 1.4.x, first-network/byfn.sh exists, not test-network/network.sh. Change the branch of your fabric-samples to release-1.4. Do not run 2.x code while doing the 1.4 tutorial.

./byfn.sh basically executes the image tag as latest. That is, if you have pulled the 2.x version of the image, even if you proceed to 1.4.x, it will run as 2.x.

cd fabric-samples
git checkout release-1.4

There are two ways.

  1. tag the latest with 1.4.x image Untag all hyperledger latest image tags, and tag 1.4.x images as latest. (In fact, the easiest way is to delete both the 2.x and 1.4.x images and execute the command again.)

  2. Or edit in byfn.sh There is a part to set IMAGE_TAG in byfn.sh.

  • byfn.sh
# default image tag
# IMAGETAG="latest"
IMAGETAG="1.4.9"

Make sure the value of that part matches your 1.4.x version

[EDIT - 2] For binary I don't know where and how you built it. However, you can easily build it on the fabric github.

  1. make binaries
cd $GOPATH/src/github.com/hyperledger
git clone http://github.com/hyperledger/fabric
cd fabric
git checkout release-1.4
make native
  • Makefile native - ensures all native binaries are available configtxgen - builds a native configtxgen binary configtxlator - builds a native configtxlator binary cryptogen - builds a native cryptogen binary idemixgen - builds a native idemixgen binary peer - builds a native fabric peer binary orderer - builds a native fabric orderer binary
  1. Path setting
mv $GOPATH/src/github.com/hyperledger/fabric/.build/bin/* <your_bin_path>

# in my case
# mv $GOPATH/src/github.com/hyperledger/fabric/.build/bin/* usr/local/bin

or

export PATH=$PATH:$GOPATH/src/github.com/hyperledger/fabric/.build/bin
myeongkil kim
  • 2,465
  • 4
  • 16
  • 22
  • Thanks for your feedback. However, please note that whether I use your ```curl``` command or ```curl -sSL ... | bash -s -- 1.4.9 1.4.9 0.4.21``` (https://hyperledger-fabric.readthedocs.io/en/release-1.4/install.html) to point to ```v1.4```, the ```test-network``` does exist for some reasons, leading to the same ```network``` issue as highlighted in the picture. Best Wishes. – dark.vador Dec 31 '20 at 21:41
  • Thank you very much for your comments., and I've amended the ```post``` accordingly since the nub of the matter may lie in a synchronization issue between the ```Fabric``` ```binaries``` and related ```Docker``` images. – dark.vador Jan 01 '21 at 14:41
  • Installing binaries and registering paths is very basic, so I've edited them further in the answer. Also, new questions should be created according to the guidelines in StackOverflow, not modifying the question. (The question is not good if it is broad or contains multiple questions.) – myeongkil kim Jan 02 '21 at 03:11
  • I agree that installing ```binaries``` and ```registering``` ```paths``` are rudimentary tasks. Your latest point ```1.``` could even be performed the single ```curl command``` documented on the ```H. Fabric``` website. ```2.``` could be performed by editing the environment variable. To minimize any synchronization issue, v.2X has been downloaded downloaded and related binaries automatically installed, since the curl performs altogether 4 documented steps. The purpose of editing was to provide additional details to the network issue encountered instead of duplicating the same problem. – dark.vador Jan 02 '21 at 17:08
  • My issue was mainly tributary on the mixed ```Docker containers``` downloaded (for different ```Fabric``` versions) and not cleared/removed, and your suggestions finally raised that awareness. Thus, thank you for all your input(s). Best. – dark.vador Jan 02 '21 at 17:17