I used multiple cards. I got a 2 GB no name one that worked fine previously with raspbian. Then for the images bigger than 2 GB, I used a Samsung 64 GB class 10. Armbian boots fine, Void boots fine using Armbian’s bootloader, but OpenBSD and the Towboot image don’t.
1 Like
And of course something had to go wrong. It looks like the kernel does not detect /usr/lib/firmware and /usr/lib/modules if it’s not running the exact version of the kernel. So obviously the next step was to install kernel 5.16 and replace the symlinks from /boot to point to the new vmlinux and dtbs. What could possibly go wrong? Famous last words.
Currently trying to boot into Void again by using the old Armbian kernel and symlinking back to the old vmlinuz. Aaand, it’s alive, but obviously not all kernel features work.
If only I wasn’t so dumb as to forget to backup the /lib/modules and /lib/firmware after I did the apt upgrade, not before… REEEEEE
2 Likes
After countless tries to relink Image, uInitrd and dtbs to the versions generated by dracut when I installed Void and the initrd images generated by myself with uboot-mkimage, I gave up, extracted the armbian image on the RockPro64, mounted it, chrooted into the image, updated debian, exited, then copied the firmware and modules for the specific version of the kernel that I was booting into. Iptables seems to be working now.
So, if anyone wants to use the Armbian image for the RockPro64 as a base for bootstrapping their distro of choice, remember to update it to the latest version, then copy /etc/alternatives, /etc/fstab, /lib/firmware, /lib/modules and most importantly /boot over to your distro’s rootfs. To be honest, it’s easier to just write armbian on a SD card, update it that way, then use another PC to remove all the folders except the ones I mentioned, then copy your distro’s rootfs on it. You should be able to boot as usual with the existing kernel, just into a different environment.
2 Likes
Hah! I knew I was doing something wrong with OpenBSD. Well, I did RTFM, or I thought I did, but I guess I didn’t RTFM hard enough. The manual INSTALL.arm64 is written in a weird way.
So, OpenBSD supports the RockPro64, however, I did not think I had to go through the section “Install on systems without a supported miniroot.” Apparently the rockpro64 is one of them. So I needed to flipping make an OpenBSD VM (thank Lord I still had my Proxmox x86 server back in Europe) and I needed to install the packages dtb and u-boot-aarch64. Then I could use the miniroot70.img on the SD card, then mount the first partition and copy the board’s dtb and then write the u-boot.itd into the SD card.
I had the OpenBSD VM ready from the previous time, when I tried mounting the img files on OpenBSD in order to read them. Neither of them had the dtb or u-boot anywhere to be found. At least I learned how fdisk works on OpenBSD and how to mount disk images on OpenBSD.
I managed to see the boot screen on the HDMI output on the rkpr64, but after saying
cannot open sd0a:/etc/random.seed: No such file or directory
booting sd01:/bsd:
The screen goes blank, no more text shows up, but the screen is still turned on. Not sure what the deal is. I presume that if I had a serial, I would see what’s going on.
Oh well, I will count that as a success, at least seeing the board boot OpenBSD makes me happy. Interestingly enough, it looks like OpenBSD doesn’t use the white LED as an activity LED like Linux does (well, that’s probably bloat anyway, less is more).
Connecting the board to my LAN did not work in its favor to get an IP address, no changes in the DHCP leases were seen. I’ll try using the install70.img instead and see if I manage to install OpenBSD that way and get it in a working state. But I somewhat doubt that install would be better than miniroot.
4 Likes
I started playing with the Void on the RockPro64 and I had created a virtual tagged interface and created a runit service to start dhcpcd on it. When I rebooted, dhcpcd was not having any of that when the virtual interface was absent (I didn’t make it persistent, it was just a test), I wouldn’t even get DHCP requests for the normal interface either. That was really weird.
I should start looking into getting started with the HC4, I ordered some HDDs, they should be here by tomorrow.
2 Likes
To make matters more confusing, the Odroid HC4 has something called petitboot built into its SPI flash. It functions kinda like GRUB and a BIOS combined. You get system info and other stuff, you get a netboot server where you can specify a manual IP address and a TFTP server if you don’t those from your DHCP server and you can boot into any attached disk. Of course, being the insane individual that I am, I’m going to boot from an SD card, why the snap not?
Anyway, to complicate stuff, petitboot is not compatible with u-boot, which most distros use. So the recommended way of booting OS other than the provided Ubuntu image is to wipe the SPI and get rid of petitboot. That’s so insane… But something like petitboot is exactly what I was looking for to boot the Odroid N2+ from a network location (which will be the HC4 TFTP and NFS server). I haven’t had time to check Wendell’s netboot wiki, I don’t remember how the video went either, but he was using raspberry pis, I want to use other SBCs, so I may need to look into how to netboot those.
I wonder if they can boot from the network without a microSD card first booting into something like petitboot… I need to read so much stuff to finish this project, I seriously did not know the amount of work that was needed to get this finished. But once I have all the steps and backups of the original SPI firmwares, I should be good to go. I’ll probably do a wiki on each SBC and how to get alternative OS going using Armbian as a bootstrap (the kernel, bootloader and other stuff ripped from the Armbian install for each particular SBC).
Also, one of my 2 GB SD cards doesn’t throw errors anymore, I probably didn’t insert it correctly or something, who knows. It’s working just fine now. Managed to boot manjaro on the HC4 with it, but it went into a blank screen after the kernel was trying to get loaded (need to remove petitboot for it to properly display stuff). And it wasn’t getting an IP address.
This comment is a bit more rambly than usual.
1 Like
I have been playing with the HC4. I installed the default Ubuntu image from Hardkernel. Initially I just wanted to backup the SPI, but it appears like that won’t happen, the SPI doesn’t get detected as a device, like /dev/mtdX.
Then, I plugged in my new 10TB HDDs to test them, they are still going (and will for probably a few days). I wanted to install zfs-dkms and play with ZFS after they were done, but I forgot this thing was running linux 4.9, which I remember not working with ZFS. But by the time I realized, it was too late, apt was giving errors about the kernel being used by some chroot environment or something.
I don’t remember if I rebooted after I updated ubuntu and I had kernel 5.4 installed, or if it was automatically installed by zfs-dkms, but that came in somehow. I removed it after it finished failing successfully (lmao), and an autoremove also removed linux 5.4, so I tend to think it was ZFS doing its thing. /boot did not contain anything other than 4.9, so it makes it even more likely that linux 5.4 was installed by zfs.
I can barely wait for the HDD tests to finish and start working on getting a distro with a newer kernel running on The Toaster. I should probably start working on getting OpenBSD to work on the RockPro64, I managed to boot it, but can’t use it if I don’t access to it via anything (SSH or TTY). I may have serial access, but I don’t have a uart connector.
2 Likes
Apparently badblocks writes and reads 4 times with a different pattern each time for each pass. So using -p 2 would make 8 writes and reads instead of 4. I didn’t want to subject my new HDDs to that much of a torture. After writing between 70 and 80 TB on them, I canceled the passes.
Now, trying to get Void on the HC4 using the same method I used for the rkpr64, it doesn’t work. That, or I’m forgetting something.
I booted into petitboot, wiped the mtd (SPI flash), powered off, installed armbian as usual, updated, rebooted, formatted my microSD card, copied /usr/lib/firmware, /usr/lib/modules, /boot and edited both the armbianEnv.txt and /etc/fstab to match the other microSD card’s UUIDs.
The board refuses to boot Void, but does boot Armbian. I even did a dd of the first 16 sectors, skipping the first 512 sectors on the target, just in case the Armbian image had a u-boot written to the SD or something. Worth mentioning that partition 1 on both SDs starts at sector 8192 (as opposed to the default 2048), leaving space for whatever is supposed to reside at the beginning of the disk. What I did was dd bs=512 seek=1 count=16 /dev/souorce-sd /dev/target-sd.
This board gives me even more headaches than the previous 2.
1 Like
Ok, so I wasn’t doing everything as I did previously. I don’t remember for sure, but I think last time I kept the original microSD cards that I have written the image files to, just that I replaced everything on them with the Void rootfs and just added the files mentioned above afterwards (obviously copied them first). Now Void boots.
So, to repeat this process, I believe I may need to write the Armbian to the microSD card that I intend to use as the boot from, copy whatever I need from it, then wipe it out and put out another OS rootfs instead.
I don’t like the fact that I don’t get kernel upgrades. Besides, I need ZFS, so I need to install the ZFS kernel modules. I discovered how to create new u-boot images and stuff from existing kernels that I install (like 5.16), but I am not entirely sure how to boot into it. I will try some experiments with replacing the symlinks in the boot directory to new images, but I’m not sure that will necessarily make u-boot boot into the new kernel images I add. I probably need to get u-boot to load the images in the first place… this is going to be painful, I need to find some documentation about how Armbian or Manjaro updates their bootloaders.
3 Likes
Primary objective achieved. I managed to install Void on the HC4 using the Armbian kernel, then I removed the root, as described above. After I booted into Void, I installed a kernel from the Void repos, I went with the latest 5.16.18, not sure what support this kernel has for the HC4, I haven’t yet checked if everything works correctly.
The install process was a bit painful, I’ll probably need to create one of my easy-to-follow wikis on this, so that I have something to easily refer to when I need to update. I needed to install dracut, make a ramdisk image, then make u-boot images, then move some symlinks around. The process is a bit weird, but I believe I may be able to slightly automate it, except for maybe the symlink creation, but maybe even that could be done.
The kernel update process is a bit manual and I probably need to be careful with new kernel updates, since I always have to reimage u-boot and generate the ramdisk manually (the xbps script, if dracut is present, only creates the initramfs, not a ramdisk). I’m currently installing zfs, I hope this works. For some reason, the zfs package has a dependency on linux 5.15 headers, which is weird, I hope I can get it working on the latest kernel, as I don’t want to use older versions, because I’m afraid it may not contain the necessary support for the C4 and HC4.
Looking online, I couldn’t find anything regarding those SBCs support in the mainline linux kernel, all the supported ones that I know of is 4.9 from hardkernel, 5.10 from armbian and probably 5.16 from manjaro. As much as I hate manjaro, they do have a community that keeps updating the kernel for those SBCs often, I’ll give them that. But that advantage is thwarted by the fact that manjaro uses pacman and that they push updates of 1 to 2GB in size every week or two, that is too much for my tastes.
1 Like
I am in pretty deep trouble. I came home and came back to this output:
Building DKMS module 'zfs-2.1.4' for kernel-5.15.32_1... FAILED!
DKMS module 'zfs-2.1.4' failed to build, please check /var/lib/dkms
for errors in the log file.
Prepare to build modules for kernel-5.16.18_1... FAILED!
Kernel scripts failed to build, please check /lib/modules/5.16.18_1/build/make.log
for errors in the log file.
Building DKMS module 'zfs-2.1.4' for kernel-5.16.18_1... FAILED!
DKMS module 'zfs-2.1.4' failed to build, please check /var/lib/dkms
# tail -n 4 /lib/modules/5.16.18_1/build/make.log
scripts/Makefile.build:44: arch/arm64/tools/Makefile: No such file or directory
make[1]: *** No rule to make target 'arch/arm64/tools/Makefile'. Stop.
make: *** [arch/arm64/Makefile:173: archprepare] Error 2
make: Leaving directory '/usr/src/kernel-headers-5.16.18_1'
# cat /var/lib/dkms/zfs/2.1.4/build/make.log
KMS make.log for zfs-2.1.4 for kernel 5.16.18_1 (aarch64)
Sun Apr 10 19:40:43 UTC 2022
make: Entering directory '/var/lib/dkms/zfs/2.1.4/build/module'
make: *** No targets specified and no makefile found. Stop.
make: Leaving directory '/var/lib/dkms/zfs/2.1.4/build/module'
# cat /var/lib/dkms/zfs/2.1.4/build/build/conftest/build.log
make: Entering directory '/usr/src/kernel-headers-5.16.18_1'
CC [M] /var/lib/dkms/zfs/2.1.4/build/build/conftest/conftest.o
MODPOST /var/lib/dkms/zfs/2.1.4/build/build/conftest/Module.symvers
/bin/sh: 1: scripts/mod/modpost: not found
make[1]: *** [scripts/Makefile.modpost:134: /var/lib/dkms/zfs/2.1.4/build/build/conftest/Module.symvers] Error 127
make[1]: Target '__modpost' not remade because of errors.
make: *** [Makefile:1761: modules] Error 2
make: Leaving directory '/usr/src/kernel-headers-5.16.18_1'
It looks like ZFS dkms module does not have a proper build file for aarch64. This is terrible… I need help in building that myself, or I’ll probably need to run FreeBSD on the Odroid HC4. Well, I wouldn’t really mind that, but BSDs is not familiar territory for me. I wonder if Gentoo has any guides or builds on that, it could be helpful. But I don’t have the knowledge to get myself into that.
This is such a shame. I don’t really trust btrfs yet and I’m not entrusting my data to md, not to drives of this size.
But, to be honest, the NAS OS doesn’t really matter that much, as long as it has ZFS, a NFS server, a TFTP server and maybe an iSCSI server. If anyone has any idea about how to get ZFS working on aarch64, let me know.
2 Likes
Not sure how kernel is packaged on void . It’s as if you don’t have the kernel headers package.
make modules_prepare gets you the modpost utility and other helpers and goodies.
See “external modules” here:
https://www.kernel.org/doc/Documentation/kbuild/modules.txt
But, to be honest, the NAS OS doesn’t really matter that much, as long as it has ...
Armbian (/me ducks). It ships with 5.10 but are you sure you can’t just upgrade to 5.15 or 5.17 on there if that’s the kernel you want.
3 Likes
I don’t mind any kernel, so long as it receives updates. This could be a good opportunity to learn to compile the kernel with whatever modules I want, I guess.
The kernel and the headers are split into 2 packages, I installed both for 5.16.18. Interestingly enough, there is another package called linux-headers, that seems to be a generic one that will upgrade the headers to whatever the maintainer keeps the version at (currently 5.15).
[oddmin@bikyhc4 ~]$ xbps-query -Rs linux |grep headers
[*] kernel-libc-headers-5.10.4_1 Linux API headers for userland development
[*] linux-headers-5.15_1 Linux kernel headers meta package
[-] linux-lts-headers-5.10_1 Linux longterm support kernel headers meta package
[-] linux-mainline-headers-5.16_1 Linux latest mainline kernel headers meta package
[-] linux4.14-headers-4.14.225_1 Linux kernel and modules (4.14 series) - source headers for 3rd party modules
[-] linux4.19-headers-4.19.237_1 Linux kernel and modules (4.19 series) - source headers for 3rd party modules
[-] linux4.9-headers-4.9.261_1 Linux kernel and modules (4.9 series) - source headers for 3rd party modules
[-] linux5.10-headers-5.10.109_1 Linux kernel and modules (5.10 series) - source headers for 3rd party modules
[-] linux5.11-headers-5.11.22_1 Linux kernel and modules (5.11 series) - source headers for 3rd party modules
[-] linux5.12-headers-5.12.19_1 Linux kernel and modules (5.12 series) - source headers for 3rd party modules
[-] linux5.13-headers-5.13.19_1 Linux kernel and modules (5.13 series) - source headers for 3rd party modules
[-] linux5.14-headers-5.14.21_1 Linux kernel and modules (5.14 series) - source headers for 3rd party modules
[*] linux5.15-headers-5.15.32_1 Linux kernel and modules (5.15 series) - source headers for 3rd party modules
[*] linux5.16-headers-5.16.18_1 Linux kernel and modules (5.16 series) - source headers for 3rd party modules
[-] linux5.2-headers-5.2.21_1 Linux kernel and modules (5.2 series) - source headers for 3rd party modules
[-] linux5.3-headers-5.3.18_1 Linux kernel and modules (5.3 series) - source headers for 3rd party modules
[-] linux5.4-headers-5.4.188_1 Linux kernel and modules (5.4 series) - source headers for 3rd party modules
[-] linux5.5-headers-5.5.18_1 Linux kernel and modules (5.5 series) - source headers for 3rd party modules
[-] linux5.6-headers-5.6.19_1 Linux kernel and modules (5.6 series) - source headers for 3rd party modules
[-] linux5.7-headers-5.7.19_1 Linux kernel and modules (5.7 series) - source headers for 3rd party modules
[-] linux5.8-headers-5.8.18_1 Linux kernel and modules (5.8 series) - source headers for 3rd party modules
[-] linux5.9-headers-5.9.16_1 Linux kernel and modules (5.9 series) - source headers for 3rd party modules
[-] odroid-c2-kernel-headers-3.14.79_1 The Linux kernel headers for ODROID-C2 (3.14 series)
[-] pinebookpro-kernel-headers-5.10.46_1 Linux kernel for Pinebook Pro - source headers for 3rd party modules
[-] pinephone-kernel-headers-5.10.12_2 Linux kernel and modules (5.10 series) - source headers for 3rd party modules
[-] rpi-kernel-headers-5.10.92_1 Linux kernel headers for Raspberry Pi (transitional dummy package)
[-] rpi3-kernel-headers-5.10.92_1 Linux kernel headers for Raspberry Pi 3 / Zero 2 (5.10 series [git 650082a])
[-] rpi4-kernel-headers-5.10.92_1 Linux kernel headers for Raspberry Pi 4 (5.10 series [git 650082a])
1 Like
I am about to discover how to get a diskless alpine image to boot on the Odroid HC4 using a LibreELEC image, then slapping alpine’s kernel on top instead, maybe. I know Alpine ships with either Linux 5.10 or 5.15, I believe it’s the later (I think Alpine 3.15 had Linux 5.15.4)
If I can get Alpine and ZFS to work nicely on the HC4, then I’ll be all set to start working on the Odroid N2+ to make it netboot. I wonder if I’ll manage to get OpenBSD to work on the RockPro64 before that, I need my DHCP server to not change every 2 weeks, as it will serve the TFTP location on the HC4… I got lotsawork to do.
1 Like
Ok, the LibreELEC part failed, not sure why, I did everything as was described in an article I read (it was on the internet, so it must have been true).
Anyway, I feel like I am getting closer to getting Alpine to work, I can almost smell Alpine booting on the HC4. I found an article on the Alpine wiki for making booting it using an Armbian image. Well, technically, it details the process almost from scratch, with the SBC in question being “for Allwinner and other ARM SOCs,” more specifically, the guide goes in depth on how to get Alpine working on a NanoPi M1.
The wiki page explains how the boot process actually works. To be honest, it’s a miracle (not really) that I got Void to boot without actually knowing what I was doing and just deducting / reverse-engineering the process from whatever files I found under /boot. Well, Armbian has such a generic u-boot bootloader configuration that it’s almost genius. Someone took a long time to write the boot.cmd script.
I discovered that, instead of using extlinux.conf, u-boot can boot from the boot.scr file under /boot by basically executing boot commands. The file system being basically the same, it wasn’t hard to figure out what needed to be replaced on the rootfs, but alpine is different, unless you want to use the classic /disk install, which will work perfectly fine with the same steps as before, but for the diskless install, I needed to create a modloop and add the parameter to the boot.cmd then “compile” the boot.scr.
Actually, I am a bit worried that I may need to boot into Armbian the first time, install some kernel modules, update the kernel, uInitrd and modloop before I can boot Alpine in diskless mode.
This experience made me realize how Alpine works in diskless mode. For those in the known, it just takes advantage of the ram disk feature and loads all the rootfs in RAM.
2 Likes
While not exactly on the topic of my adventure on the ARM homelab, it is somewhat related to the title. I’ll be ranting and rambling about my Pi 4, my main PC.
I am sick and tired of my Pi failing to detect displays after a period of time if I unplug the monitor to work on the other SBCs and having to force reboot, because killing sway just freezes the whole thing. I am also sick of the Pi not detecting a display when swayidle is set to dpms off after a few days of uptime.
Initially I had a powered USB 2.0 hub plugged into one of the USB 3.0 ports on the PI, then a USB 3.0 HDD connected to the hub. The hub had 2 slightly higher powered ports (1 amp) to which I connected the HDD. Originally I thought that this was causing instabilities with the Pi not detecting the display, because it may draw too much power from the port. So eventually I got tired of having to force reboot the Pi, so I moved the HDD over to the Odroid N2+ as a temporary solution and mounted it via sshfs.
That didn’t solve the issue. It drives me insane. I just now removed the overclock on the Pi and I have a feeling my CPU is running at 600 MHz, but I am not sure how to verify that.
Previously, my OC was meant to keep the CPU at 2 GHz constant, I had force turbo enabled, which disabled the frequency adjustments. I only did that because my script reported the CPU to be running at 0.6 GHz even with the OC and while loading 8 firefox pages.
The Pi is definitely slower now.
#!/bin/sh
#show cpu temp
#cpu="$(doas cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq)"
cpu="$(cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq)"
echo "CPU => $((cpu/1000000)).$(((cpu%1000000)/10000)) GHz"
Running this results in: CPU => 0.60 GHz. Previously, when I forced turbo mode, I had CPU pegged at 2.0 GHz. lscpu does report a max of 1.5 GHz, but I highly doubt that if accurate, at least not on my setup.
I’m thinking of maybe doing an overvolt 2, CPU 1.8 GHz and GPU 600 MHz. I previously had them at overvolt 6, 2 GHz and 750 MHz respectively. At some point I had a stable OC with overvolt 6, 2.1 GHz and 750 MHz, but went lower just in case.
In other news, completely off-topic, but related to this post, I switched to pipewire just for the bragging rights. When I first tried it a year ago, it was painful. Now, it was painless, I just installed pipewire, pipewire-docs and enabled pipewire and pipewire-pulse services. A reboot later, everything seemed to be working as normal, which is pretty neat.
I think I may want to go back to x86 on some low-powered x86 SBC, or maybe just switch to another ARM board full time, but there is nothing with at least 8 GB of RAM out there yet from what I know. Firefox is gobbling up all my RAM and 4 GB is not enough, unless I want to thrash my SSD for overusage of swap.
The only realistic x86 board for me would be the DFI GHF51. With x86, at least I would get access to some convenient software, like LBRY desktop, because odysee seems to suck really badly. I really wish the Khadas VIM4 would show up. Apparently the VIM4 has a launch date on May 10. But I don’t like buying the first versions of a product, I usually wait for about a year, until rev 1.1 or 1.2 come along and fix hardware issues.
Normally, the Pi 4 is all I need, it gets the job done quite well. But if it prevents me from being able to unplug the HDMI to work on other computers, without requiring me to force reboot on it to plug the HDMI back in and get an output, then it’s not worth the hassle. I can always repurpose it as an Android device. I was thinking of running Android on the Pi 3 once I get the RockPro64 to work as my main router.
Today I gave a read to the whole OpenBSD manual. It seems like supposedly, the rkpr64 is supported, it even has the u-boot files and stuff in the install image. But for some reason, those don’t get written to the boot dir. The install70.img does not boot. I need to write u-boot into the SPI flash. I wonder if I can do that from a Linux boot environment, like Armbian.
Again, miniroot70.img boots, but it goes to a blank screen, then the monitor turns off. If I am to flash the SPI, I’d rather try Tow-Boot, like ulzeraj told me twice already. There were no instructions to flash the bootloader to SPI, but the install.arm64 doc was not the most board specific to begin with.
1 Like
So, after 22 days of doing nothing, I got to flashing tow-boot on the RockPro64. Of course, when I tried connecting the display back to my RPi, I got a black screen, because screw detecting outputs, yeah!
Tow-boot was successful. Nothing much to report, other than, it seems to be smarter than u-boot and probably as good as petitboot. It has SD, eMMC, NVME, DHCP, PXE and another boot menu option (I think it was SP? it was not SP, but I don’t remember what it was, it may have been sp0, I don’t know).
I’ll try openbsd on it again.
1 Like
Forgot to mention that tow-boot supports efi payloads, which is a nice touch, I could literally install grub on the SD card if I wanted to.
Anyway, spent the last hour and a half trying to get OpenBSD to boot. At least this time, it doesn’t end in a black screen, but it still doesn’t boot. It’s looking for /etc/random.seed, which it cannot find, then moves on, tries to boot /bsd, and ends up with some numbers on the screen, likely an error, then nothing happens after a few minutes of waiting.
Ok, knowing that 7.1 is out, I download miniroot71.img. Flash it to my SD card, even make a /vendor folder and add the rk3399-rockpro64-v2.dtb in there and on the root of the /boot partition. Still no dice, the same issue with the numbers.
I’ll probably flash install71.img just to see if I can get that to work. At least if I manage to install it, I’ll get a random seed going, in case that’s actually what it’s complaining about (although I doubt it).
1 Like
And of course, after another 30 minutes of pain, when I go to replug my monitor into my Pi, I get no output and have to do another forced reboot. I hate this.
And install71.img does the same error when booting. OpenBSD might be a lost cause until I can get a uart connector and see what the snap is going on on the board.
1 Like
Hello sir, hoping this is a good place to drop this for you. I know your exploring SBC as a solution to carry a cluster around portably. I saw this bit of hardware that might be a good mounting solution for you thats a little more protective than open air plexy options and smaller than the full rack size mounts.
UCTRONICS Upgraded Complete Enclosure for Raspberry Pi Cluster, with 4 Removable Mounting Brackets for Pi 4B, 3B+/3B, and Other B Model and 2 Cooling Fans ,Support 4 2.5" SSD and Switch https://www.amazon.com/dp/B09JNHKL2N/ref=cm_sw_r_apan_i_WZA8DGZ978M5JDCYE2D8
Know its for other than Raspberry Pi, may work with other SBCs with the same form factor.
Thats if you havent moved on to the pi options that have the main board now with compute units you can plug in Ive seen recently. 
3 Likes