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:
--
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:
|
|
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 Starting nodes with CLI timeout of '5' tries
and CLI delay of '3' seconds and using database 'leveldb' with
crypto from 'cryptogen' 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) |
|