blood

I don't use my Clearfog Base as a filer or anything, but I much prefer to have some snappy storage on systems that I access frequently - and since this system is my firewall, I end up working on it often enough. When I'm not at home it's often where I push files - so running off an SD card is right out. For years now I've been using an m.2 SATA drive which has been fine, but it's got a minipcie slot just sitting there that I've never used... it's not particularly fast (PCIe gen 1 x1) but with one of these and an m.2 NVMe drive (the older the better...), you can get much better perf than SATA. You can't boot off it (at least I don't know how to make that happen) but it's easy enough to do that via an SD card or SATA and use one of these for the root filesystem or /home, etc.

Thanks for those that answered. I was hoping someone would bring up a board targeted at networking (router / firewall) that was well supported by modern software, but nothing is really jumping out. Here are some more random thoughts on the matter... since my previous experience was with SolidRun Clearfog Base (and with Armbian it was quite positive!) I am interested in their newer Clearfog CN9130 Base but it's a bit expensive and I'm hesitant to use anything not supported by Armbian due to poor experience with vendor images. But it looks cool! MACCHIATObin double shot isn't new, and doesn't have the best support either from what I can gather - but it also is attractive. And lastly, Honeycomb LX2 is pretty boss as well - but it also is a bit dated now, isn't cheap, and seems to have not caught on well so doesn't have great software support. All of those seem like nice hardware but I don't expect the software experience to warrant buying one. I had an impulse to buy when I saw the new dual 2.5gbe HAT from Radxa as I have a Rock 4a that claims to support it. I've had that little box in use as a container host running simple services like DNS, DHCP, Unifi controller, etc for a long time now and it's been nothing but reliable - though I do need to evacuate it so I can try bringing it up running Bookworm (it's on Bullseye still - but it's stable!). But I just noticed that maybe its own software support is rotting... it's community supported and the last Armbian image for it is quite old, so maybe I shouldn't put any more money or effort into it and let it do its thing. Dunno. But yeah, a tiny system that is quite low power which supports 2 x 2.5gbe and 1gbe along with NVMe sounds pretty nice especially since I already own the SBC... I suppose what I should really do is continue to ride my existing router until it dies. Considering I locked the kernel and firmware I expect it will work for a long while at this point, though I don't figure it to be able to upgrade to the next major Debian release once it's available. Maybe by then the support for Rock 5 ITX will be solid and I can start using it for this. If anyone else runs Armbian systems as their firewall, please chime in with thoughts and experiences!

Thanks - that's a couple options I should keep in mind: adding the router to a hyperconverged setup running one-armed against a switch via VLANs I've enjoyed having a separate WAN and LAN link for so long that I fell into looking for boxes with 2 physical links but that's totally not a requirement and you're right.

I’ve been rocking a Solidrun clearfog base with Armbian for ~10 years now as my home router and was very happy with it until a few months ago when the newer software updates began to break it. I think the software support is beginning to rot due to not many users and thus no push to maintain it. I figure it’s time to start looking for a replacement. I have a Rock 5 ITX that could do it but I’ve been trying to keep it on the vendor kernel so it can transcode in hardware for Jellyfin - but that vendor kernel has issues reliably detecting the SATA controllers - and I don’t want to have to reboot my router multiple times to get the hardware to work after applying updates. i also just got a Radxa Orion o6 which is awesome hardware but still quite raw. I don’t trust it for a router and it’d be overkill anyways. And I have some stupidly powerful x64 systems that eat a bunch of power but are otherwise up to the task. But I don’t want to go that way. What do you use these days for affordable, performant, and low power routers? At least two gbe ports (10g or multigig preferred), enough CPU to NAT and forward for 500m/30m cable connection, and handle wireguard at a good clip. Preferred serial console … support for Debian / Armbian. I don’t care about a GPU. What do people use these days?

As seen in some other threads for mvebu-based boards (helios4, etc), the current images for clearfog base (and I assume) pro are broken in that it appears the initrd can't be loaded. I also haven't been able to use the u-boot for SATA booting in a while. I have been hitting both of these issues for a while and as I showed above in the past you can still flash old images, use an even older u-boot binary for SATA and get up and running - but now (and I'm not sure when it started) any upgrade to current packages renders the system unbootable. It's unfortunate, but it seems these boards are old enough that their support is rotting (and to be clear, I'm not blaming Armbian for this). While this hardware is old it's plenty performant as my home firewall to the Internet and so I don't want to replace it - but it's maybe time to start looking for a replacement anyways. Just a few nights ago, I installed updates for the first time in a few months and when I rebooted it, it failed to come back up. Considering this is my router, that really cramped my style! But I got another box in place in this role and since then I've poked at this a bit. It's easy to reproduce: Flash a copy of Armbian_23.11.1_Clearfogbase_bookworm_current_6.1.63.img to an m.2 SATA drive (if this isn't available any more, ping me and I can post it somewhere). Write a copy of the old u-boot for SATA support to the beginning of the drive (dd if=u-boot.sata of=/dev/foobarbaz bs=512 seek=1) Put the m.2 SATA drive into your clearfog and configure the jumpers to boot off SATA - see here. Plug in ethernet and micro USB to another system and attach to it for console (picocom -b 115200 /dev/ttyUSBFOOBARBAZ) Power it on and hopefully observe it boot - then go through the initial setup Update and upgrade packages (apt update && apt upgrade) Reboot - and watch it stall before it gets anywhere The trick then is to put a "hold" on the kernel and firmware packages before doing #6. The latest kernel I've been able to get running stable is 6.6.63-current-mvebu (installed via armbian-config). for pkg in armbian-bsp-cli-clearfogbase-current armbian-firmware linux-dtb-current-mvebu linux-image-current-mvebu linux-u-boot-clearfogbase-current; do echo "$pkg hold" | dpkg --set-selections done Then you should be able to upgrade everything else and reboot and have it not break. That list of packages is likely larger than it really needs to be, but after rebuilding my drive a couple of times I decided to not take any chances. The rest is either pure Debian or at least things that shouldn't break due to bit rot. If I have more time I'll try to actually dig in and figure out what's wrong with the ramdisk (or whatever it is that causes this) and submit a fix, but this is better than nothing for now.

So I don't know exactly what is wrong with the latest posted clearfog images (other than the u-boot.sata binary doesn't work), but after using the process I detailed above, I just let apt upgrade everything - including the kernel to 6.6.63-current-mvebu) and so far everything seems to be working after a reboot. I might get this back into production as my home router today after all once I run a few more smoke tests!

I should have mentioned, the above output came from using an old u-boot.sata that I rescued off my old install. When I used the one included in the new build, I didn't get any console output from uboot at all. I have since reverted to an older image from the archive (Armbian_23.11.1_Clearfogbase_bookworm_current_6.1.63.img). Using its u-boot.sata I also got no console output, but with my older one, I have been able to at least get this image to boot! So there's a recipe at least for getting something somewhat modern (if you consider an image that's over a year old "modern" - and from where I'm coming from I do!). Do I dare try to move its kernel forward? Or should I just settle with what I have and move along... I'm attaching a copy of the older u-boot.sata file that is working for me in case it's useful to anyone else. Oh, who am I kidding - this is a really old board and nobody is using them now. u-boot.sata

When I attempt to boot I get: U-Boot SPL 2018.01-armbian (Feb 17 2023 - 23:33:49) High speed PHY - Version: 2.0 Detected Device ID 6828 board SerDes lanes topology details: | Lane # | Speed | Type | -------------------------------- | 0 | 3 | SATA0 | | 1 | 0 | SGMII1 | | 2 | 5 | PCIe1 | | 3 | 5 | USB3 HOST1 | | 4 | 5 | USB3 HOST0 | | 5 | 0 | SGMII2 | -------------------------------- PCIe, Idx 1: detected no link High speed PHY - Ended Successfully DDR3 Training Sequence - Ver TIP-1.29.0 DDR3 Training Sequence - Switching XBAR Window to FastPath Window DDR3 Training Sequence - Ended Successfully Trying to boot from SATA AHCI 0001.0000 32 slots 2 ports 6 Gbps 0x3 impl SATA mode Found 1 device(s). U-Boot 2018.01-armbian (Feb 17 2023 - 23:33:49 +0000) SoC: MV88F6828-A0 at 1600 MHz DRAM: 1 GiB (800 MHz, 32-bit, ECC not enabled) MMC: mv_sdh: 0 AHCI 0001.0000 32 slots 2 ports 6 Gbps 0x3 impl SATA mode Found 1 device(s). *** Warning - bad CRC, using default environment Model: SolidRun Clearfog Board: SolidRun ClearFog Base SCSI: AHCI 0001.0000 32 slots 2 ports 6 Gbps 0x3 impl SATA mode Net: Warning: ethernet@70000 (eth1) using random MAC address - d2:63:b4:30:b5:09 eth1: ethernet@70000 Warning: ethernet@30000 (eth2) using incremented MAC address - d2:63:b4:30:b5:0a , eth2: ethernet@30000 Warning: ethernet@34000 (eth3) using incremented MAC address - d2:63:b4:30:b5:0b , eth3: ethernet@34000 Hit any key to stop autoboot: 0 scanning bus for devices... Device 0: (0:0) Vendor: ATA Prod.: TS120GMTS420S Rev: V011 Type: Hard Disk Capacity: 114473.4 MB = 111.7 GB (234441648 x 512) Found 1 device(s). Device 0: (0:0) Vendor: ATA Prod.: TS120GMTS420S Rev: V011 Type: Hard Disk Capacity: 114473.4 MB = 111.7 GB (234441648 x 512) ... is now current device Scanning scsi 0:1... Found U-Boot script /boot/boot.scr 2996 bytes read in 82 ms (35.2 KiB/s) ## Executing script at 03000000 Boot script loaded from scsi 191 bytes read in 80 ms (2 KiB/s) 26870 bytes read in 143 ms (182.6 KiB/s) 10631265 bytes read in 295 ms (34.4 MiB/s) 8551104 bytes read in 253 ms (32.2 MiB/s) Wrong Ramdisk Image Format Ramdisk image is corrupt or invalid SCRIPT FAILED: continuing... Card did not respond to voltage select! mmc_init: -95, time 19 starting USB... USB0: Register 2000120 NbrPorts 2 Starting the controller USB XHCI 1.00 scanning bus 0 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Device 0: device type unknown ... is now current device ** Bad device usb 0 ** ** Bad device usb 0 ** ethernet@70000 Waiting for PHY auto negotiation to complete................. TIMEOUT ! ethernet@70000: No link. ethernet@30000 Waiting for PHY auto negotiation to complete................. TIMEOUT ! ethernet@30000: No link. ethernet@34000 Waiting for PHY auto negotiation to complete. After this, the similar messages repeat for a while trying to network boot. What sticks out to me here is: Wrong Ramdisk Image Format Ramdisk image is corrupt or invalid SCRIPT FAILED: continuing... I don't know this well, but it seems like u-boot is trying to load the initial ramdisk before the kernel is started. On my functioning disk (based on an old Buster install) rather than those errors I get messages about the ramdisk, device tree, and then the kernel loads. So I suspect something is broken with the initrd.

I set about to update my clearfog base last night because it was a few Debian versions behind and I wanted to use some of the stuff in bookworm - and upon flashing the latest image along with the uboot sata, my board now will not boot at all when using this image - either when using it via an m.2 SATA drive or a microsd - and if I go back to my old SATA stick and boot off it, it continues to boot fine. Something seems to indeed be broken in the modern images! As it never seems to get past uboot, I'm going to try grabbing the uboot binary from my old install and see if it works any better.

From what I'm seeing with the latest rk35xx vendor kernel, SATA is mostly broken once again (the SATA controller PCIe device is not detected and thus no drives attached to it). It seems to be a timing issue as occasionally they have showed up though. Also, zfs-dkms results in an actually broken system when used with this kernel; kernel oops on boot. I of course don't blame Armbian for this, but the rk35xx vendor kernel branch seems to be a hot mess. Too bad it's effectively required to use the VPU...

@Werner Thanks for the attention and advice. I've read plenty of your posts in the past and your contributions are really appreciated! Does Armbian have a support path back upstream to Radxa for their vendor kernel? It always takes at least two parties to have an incompatibility so I'm not sure where the ultimate fault lies between ZFS and RK35xx here, but perhaps Radxa could help some here. I know this is the community supported Rockchip forum, but the Rock 5 ITX board is actually in the platinum support category (my fault for misfiling this but I assume it effects all rk35xx boards) which I assume means there's some linkage back to the vendor (but maybe I misunderstand what platinum support really means). In this case, I'm booting and running my root filesystem off of emmc which is soldered onto the board. I'm flashing Armbian to it over USB using rkdeveloptool via maskrom - which means I can't pull the storage and read it on another system unfortunately. I guess I could reinstall to an SD card (or move my root FS to removable storage for a future install) but I'm not there right now. @Turbodid If you have any luck or even just a different experience with this or other approaches, please make sure to update this thread.

I'm using a Rock 5 ITX and noticed after installing the latest rk35xx kernel image (6.1.84-vendor-rk35xx) that my system wasn't booting. So I connected to the debug console and observed a kernel oops being emitted. It dumps out a few pages of data, but the initial messages and call trace are: I have all the hex data if someone would use it but it doesn't seem worth including here. The boot flounders around in systemd for a bit but never gets to a login prompt - and I'm not that savvy with uboot to enter single user mode or otherwise dig in more. So I reinstalled from nothing, upgraded all my packages (including the vendor-rk35xx kernel), rebooted, and everything was ok - until I installed zfs-dkms and built the zfs module and rebooted - at which time I got back into the same busted position. And that's where I am now. I suppose I could go without zfs but I've been using it for a couple decades now and prefer it over the alternatives. As I'm not doing anything critical with this system yet, I don't mind futzing around and providing data or otherwise helping to debug what's up. At least for a few days. It does run my jellyfin instance, but I have plex running on another system so I'm too put out. A few months ago something similar (but different!) occurred after a rk35xx kernel upgrade but in that case, the system would at least boot to a login prompt eventually where I was able to downgrade the kernel and get it working again - and then the next version of the package fixed the problem. But in this case, it is effectively bricking the system for me (I'm sure someone that knows more about uboot could interrupt the boot and maybe recover things) to where I just reinstall - but that's not a good way to iterate and test fixes. I run the rk35xx vendor kernel because jellyfin has support for hardware transcoding when using that kernel - and as far as I know it does not when running against mainline - but this vendor kernel seems to be... less than stable! Any advice?

I have a Clearfog Base but not a Pro - but I utilized the instructions here and have been running Armbian off a SATA m.2 stick for years now without issue. When I attach to the USB console and boot I begin to get console output immediately, first from the firmware, then from uBoot, and finally from the kernel and into userland. Can you share the end of the output that you see? Does it go as far as "Starting Kernel" (or similar, I forget exactly what it says). My first suspicion is that the img (not an ISO per se but I know what you mean) wasn't written to the block device in the manner the board is expecting and so the handoff to the boot loader isn't happening. Do you have a SATA m.2 to USB adapter that you could use to write the image to the media from another system? I'm pretty sure when I set mine up that's what I did rather than writing the image to the SATA drive from within the Clearfog itself (that was booted off SD).

Has anyone made (or bought!) an adapter that takes the 3 pin TTL-level console port and converts it to a DB9 or RJ45 port that can mount in a PCI bracket? If so, what did you use? And what port did you use to power it as the console port does not provide a 3.3V or 5.5V pin for power (there is a pin labeled "RSV" which seems to supply 5V and may be usable but I don't know its capabilities). I've done this before for other systems using these without too much trouble but when I tried with this board it's not working. Admittedly I haven't hooked it up to a scope to look at the signals, but I'm suspicious of the high baudrate being to blame. I have a couple USB adapters that work (so I know the console itself works), but I want to rackmount this box and wire it up to my console server. I need RS232 to do that.