Problematic raspberry support


Nikos Karamolegkos
 

Works like a charm. Thank you.


Matthew Sykes
 

You'll need to build with "GO_TAGS=noplugin" to disable the plugins when building the docker images.

Should be as simple as 'make clean-all docker native GO_TAGS=noplugin'.
You can verify the peer build with 'docker run --rm -it hyperledger/fabric-peer:latest peer version'

```
$ make clean-all docker native GO_TAGS=noplugin
... 20ish minutes later on a Pi 4...
$ docker run --rm -it hyperledger/fabric-peer:latest peer version
peer:
 Version: 2.4.0
 Commit SHA: aefa755
 Go version: go1.15.7
 OS/Arch: linux/arm64
 Chaincode:
  Base Docker Label: org.hyperledger.fabric
  Docker Namespace: hyperledger
$ docker run --rm -it hyperledger/fabric-tools:latest peer version
peer:
 Version: 2.4.0
 Commit SHA: aefa755
 Go version: go1.15.7
 OS/Arch: linux/arm64
 Chaincode:
  Base Docker Label: org.hyperledger.fabric
  Docker Namespace: hyperledger
$ ./build/bin/peer version
peer:
 Version: 2.4.0
 Commit SHA: aefa755a9
 Go version: go1.16.2
 OS/Arch: linux/arm64
 Chaincode:
  Base Docker Label: org.hyperledger.fabric
  Docker Namespace: hyperledger
```

Hope that helps clarify the build process.

On Fri, Mar 26, 2021 at 6:29 AM Nikos Karamolegkos <nkaram@...> wrote:

Thank you for your time. I just ran the test-network (after your contribution) but the error remains. My steps were: make docker clean, make docker, make native, copy the bin into fabric samples.



--
Matthew Sykes
matthew.sykes@...


Nikos Karamolegkos
 

Thank you for your time. I just ran the test-network (after your contribution) but the error remains. My steps were: make docker clean, make docker, make native, copy the bin into fabric samples.


Matthew Sykes
 

I had some time this morning so I played around with the peer image created on linux/aarch64 (linux/arm64). To get to the bottom of why the program was dying during initialization, I commented out all of the code in the peer main and slowly added back in the package imports until I hit the segfault again. I went to the package introducing the problem and repeated the process until I got to the bottom.

After running down the tree, the package that caused the problem was `plugin’ and the only import left in Fabric is from `github.com/hyperledger/fabric/core/handlers/library`. It looks like plugins work with glibc (the native builds and tests seem fine) so it has something to do with musl.

I’ll put together a PR to enable builds without plugins some time today. After that’s in, the images built with alpine and musl should work on linux/aarch64 (linux/arm64). It’s still not something we’ll be testing and supporting at this time but it may unblock your efforts.


Matthew Sykes
 

Yeah, they’re all my commits so I’m very familiar with them. The change you’re referencing this time was required to get through the link phase in the alpine containers but the binaries in the containers still aren’t exercised.

As for clues, I don’t have any. If the binaries are going belly-up with a segfault, I’d start with that. It’s probably related to the musl libc used in the alpine container.


Brett T Logan <development.brett@...>
 

While I hold that those changes do in fact make building Fabric for ARM64 possible, as Matt mentioned it's not officially supported. I can say that I've tested that change on PI4 and when done right with Go chaincode, that change in itself makes it possible to run Fabric on ARM64. There are many threads all over the place with people who have had success doing this.


On Tue, Mar 23, 2021 at 9:46 AM Nikos Karamolegkos <nkaram@...> wrote:

Sorry I misclick the commit link. The correct one is this. Also, this answer made me believe that raspberry pi4 is supported (even at an early stage). I can take a look on the problem but I need some clues. Where should I start?

-- 
Nikos Karamolegkos
R & D engineer at ICS-FORTH
Telecommunications and Networks Lab (TNL)


Nikos Karamolegkos
 

Sorry I misclick the commit link. The correct one is this. Also, this answer made me believe that raspberry pi4 is supported (even at an early stage). I can take a look on the problem but I need some clues. Where should I start?

-- 
Nikos Karamolegkos
R & D engineer at ICS-FORTH
Telecommunications and Networks Lab (TNL)


Matthew Sykes
 

Nikos, the Fabric team doesn’t do anything to support Raspberry Pi. The commit you’re referencing enables _development_ of Fabric on the new arm64 based M1 macs using the code in the core Fabric tree. That should not be interpreted as “added support for fabric in raspberry.”

We do not build and publish images for linux/arm64, we do not run CI on linux/arm64, we don’t exercise the samples and test networks on lnux/arm64, and we certainly don’t do anything with Java chaincode on linux/arm64. Since we don’t exercise the paths, it’s not surprising that you’re running into difficulties.

If the containers are exiting with a 139, it’s dying with a segmentation fault. That means it’s a bad binary. Given everything above, that’s not a huge surprise. If you end up finding the cause of these problems and wish to deliver a fix upstream, we’d be happy to work with you.


Nikos Karamolegkos
 

In latest commits you added support for fabric in raspberry as described here. I am trying so many days to build fabric-chaincode-java without success (the help in the chats or the list was almost zero). So I decide to check the test-network in GO. Thus the steps are:

1) In latest fabric folder: make docker, make native
2) I ignored the fabric-ca
3) copy bin/ from fabric folder to samples folder, same for the config/
4) In latest fabric-samples/test-network folder:  ./network down, ./network up

Starting nodes with CLI timeout of '5' tries and CLI delay of '3' seconds and using database 'leveldb' with crypto from 'cryptogen'
LOCAL_VERSION=2.4.0
DOCKER_IMAGE_VERSION=
Local fabric binaries and docker images are out of  sync. This may cause problems.
/home/ubuntu/fabric-samples/test-network/../bin/cryptogen
Generating certificates using cryptogen tool
Creating Org1 Identities
+ cryptogen generate --config=./organizations/cryptogen/crypto-config-org1.yaml --output=organizations
org1.example.com
+ res=0
Creating Org2 Identities
+ cryptogen generate --config=./organizations/cryptogen/crypto-config-org2.yaml --output=organizations
org2.example.com
+ res=0
Creating Orderer Org Identities
+ cryptogen generate --config=./organizations/cryptogen/crypto-config-orderer.yaml --output=organizations
+ res=0
Generating CCP files for Org1 and Org2
Creating network "fabric_test" with the default driver
Creating volume "docker_orderer.example.com" with default driver
Creating volume "docker_peer0.org1.example.com" with default driver
Creating volume "docker_peer0.org2.example.com" with default driver
Creating orderer.example.com    ... done
Creating peer0.org2.example.com ... done
Creating peer0.org1.example.com ... done
Creating cli                    ... done
CONTAINER ID        IMAGE                               COMMAND             CREATED             STATUS                       PORTS                                            NAMES
fb943546dc4f        hyperledger/fabric-tools:latest     "/bin/bash"         3 seconds ago       Up Less than a second                                                         cli
d0a9bed586c3        hyperledger/fabric-peer:latest      "peer node start"   6 seconds ago       Exited (139) 2 seconds ago                                                    peer0.org1.example.com
a2bd075ecac5        hyperledger/fabric-orderer:latest   "orderer"           6 seconds ago       Up 2 seconds                 0.0.0.0:7050->7050/tcp, 0.0.0.0:7053->7053/tcp   orderer.example.com
67f4a76afb85        hyperledger/fabric-peer:latest      "peer node start"   6 seconds ago       Exited (139) 1 second ago                                                     peer0.org2.example.com

DOCKER_IMAGE_VERSION is empty, and the peer containers are exiting with code 139.

Is this a bug?

-- 
Nikos Karamolegkos
R & D engineer at ICS-FORTH
Telecommunications and Networks Lab (TNL)