I had a search for Raspberry Pi on Bisq and found that there was a topic for Raspberry Pi 3.
As I’m unsure of some of the details and the last post topic is back in 2019 I began a new thread.
Some details:
Debian Bullseye
Hardware/software arm64
installed
openjdk-11-jdk
gradle-7.6
gradle-8.0
bisq-1.9.9 from github
I ran a make on the code, which told me that
protoc-3.19.1-linux-aarch_64.exe was missing from the validation file which I patched in , but make now gripes about the above file checksum being missing from repository ‘MavenRepo’
I’m inexperienced in Java, hence unless there is some other interest in developing this, I’ll probably give it a bye …
This is not supported as Bisq is intended to work only on amd64 platforms, not even x86 ones… there is this:
but no idea if it works
FYI I got bisq to compile using tmakermans code.
The first time I ran it I seem to recall it complained that a 10000 DAO limit had been exceeded.
I think on subsequent attempts the disk/microchip memory bay have been exceeded.
I’m now running bisq on an external hard disk.
Best result thus far was 41% of the bitcoin network loaded.
A work in progress.
1 Like
Each time bisq runs, it gets Killed with an out of memory error.
The memory that reached the limit is the swap memory as far as I can tell.
This seems to be driven by the search for bitcoin nodes or the search for bisq nodes.
A work in progress.
Increasing the swap memory available from 100Mb to 1Gb allows the process to continue, but no bitcoin nodes are established, one bisq node get established, and bisq then throws up an error page.
I’ll start with a new install and see if tor runs with the initial setup.
I did a new installation.
The attempt to start up without the hidden tor service ran into the problem that tmakerman described with no tor linkages, and with an additional problem of an out om memory crash.
I increased the swap partition to 1000Mb and set up the hidden tor service.
Bisq now runs but quite slowly. It takes forever to shut down, maybe 30 minutes.
I moved my account onto a partition on an external hard disk, and this seemed to help initially, but I suspect that once tor connects, all the work is done from the swap file.
hang in there soldier! 
I commend your motivation, seriously
Thanks!
The machine now has 37Gb of swap space on a hard drive, and hasn’t complained about a lack of attention for maybe 15 minutes.
Here’s the output from $ free -m
total used free shared buff/cache available
Mem: 1849 1503 160 94 185 191
Swap: 38486 378 38107
note the 1.85Gb of memory.
df says this :
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/root 475717064 9334164 446995252 3% /
devtmpfs 781084 0 781084 0% /dev
tmpfs 946812 0 946812 0% /dev/shm
tmpfs 378728 1304 377424 1% /run
tmpfs 5120 4 5116 1% /run/lock
/dev/mmcblk0p1 261108 31292 229816 12% /boot
tmpfs 189360 20 189340 1% /run/user/1000
That top line shows 500Gb on the root filesystem (or therabouts).
If something has fooled the Pi operating system into finding only 1.8GB of RAM, that would explain the use of swap space.
Bummer. My Raspberry Pi 4 is a 2Gb device hence the 1.8Gb restriction.
I can keep running using the hard disk swap file … until something else breaks.
oh well, you did make it in the end though, pi4’s are very expensive lately so a refurbished laptop could cost the same and pack a much stronger punch, but then you wouldn’t get to have fun with making things work 
I’m now attempting an upgrade to bisq-1.9.12.
I patched a couple of files etc and the thing compiles, but bisq-desktop has compiled for X86-64 when the files should be for aarch64.
And btw I am NOT happy about the compile messing with my firewall without telling me.
FYI I made some patches to bisq-1.9.12.
bisq-1.9.12 now running on my Raspberry Pi 4.