Since I’ve had a small adventure with this build, and polluted this forum with some questions and observations, I thought I would write up my progress and observations so far. Maybe someone coming behind me might find this useful.
I bought a V1 carrier board, and mini-ITX adapter plate, some time ago. I also ordered a CM4 (8GB memory and 32GB eMMC), but those were back ordered for a long time. When I finally received the CM4 I was busy with other things and let this stuff sit.
I run an Unraid NAS. I backup my Windows PCs to it. I have a few docker containers and VMs on it as well. As time passed I became more and more nervous about not having a backup for some things on that server. So I decided I’d use the V1 carrier board and CM4 to build a small NAS. A target for backups from my other NAS. (If you’ve already figured out that this home NAS thing is an interesting hobby but also a never-ending rat hole, hold your comments and don’t spoil it for others.)
I acquired a Jonsbo N2 case, small form factor power supply, and a couple of 14TB drives. During the build I decided I needed to find some shorter SATA cables with 90-degree connectors on one end. This was due to the way the Jonsbo case is laid out.
The Jonsbo case is a small cube that holds 5 external 3.5 inch drives, and can also support one or two internal 2.5 inch drives. Power supply cabling comes up and around the mini-ITX adapter plate. SATA cables route down and around the mini-ITX adapter plate. The mini-ITX plate is nice, but the edges are sharp. Rather than pull it out, remove the carrier board, and do some sanding/filing, I cut some plastic tubing, sliced it on one side down the entire length, pushed the tubing over the edges where cables would be, and zip-tied the tubing to the adapter plate.
I ran all 5 SATA cables to the Jonsbo drive interface plate, although I may never use all of them.
Next I had to build a bootable USB thumb drive for some OS. Axzez offers 3 choices:
1. Desktop OS.
2. Open Media Vault (OMV) 7.
3. OpenWRT.
4. Patches for other OSes you might choose.
I opted to try OMV 7 first. I downloaded the image. Used the Raspberry PI Imager software on my Windows PC to image a thumb drive. Put the thumb drive in one of the carrier board USB ports. Connected a monitor, keyboard and mouse. Powered up the carrier board. The system would not boot from the thumb drive. I could see it was trying, and I could see the thumb drive being accessed, but no luck. The solution to this problem is doing the thumb drive imaging work on something other than Windows. I pulled out an old Raspberry Pi 3, updated it, etc. Imaged the thumb drive. This is a painfully slow experience. Armed with the “new and improved” OMV 7 thumb drive, the CM4 booted, and I was able to install OMV 7 on the CM4 eMMC memory.
I logged in to OMV via the browser and did some of the basic configuration stuff. I figured I could scratch this and start over, and probably would. The OMV 7 image reports that it needs about 60 updates, so I do the “update all”. This doesn’t go too well, and I’m pretty disappointed. Fast forward to a few attempts with OMV 7 and it’s updated. I found that after I installed OMV 7, if I let the system sit overnight, the updates would mostly work the next day. I don’t know why this is, but it happened this way twice. During the second install, all the updates except for 9 of them, mostly PHP updates, worked. The next day, those 9 updates worked. I don’t know why this happened. I’m guessing the source for the updates got sick of hearing from me and cut me off for some time, or something is happening behind the scenes in OMV.
Back to OMV attempt number 1. After getting OMV updated, I installed one 14TB drive. I wiped it. I put an ext4 file system on it. At this point, OMV flashed the yellow banner that I should commit my configuration change. I press the button to commit the change, but end up seeing a red long error message that I could not decipher. This was repeatable during the first OMV install. At this point, I could not proceed with OMV and decided to try re-imaging the CM4 with the Axzez Desktop image.
I could not get the CM4 to boot off the USB thumb drive again and do an install. Seems the CM4 firmware boot order was not set to do this. The Axzez FAQ mentions this, so I assumed I could change the CM4 firmware pretty quickly and move on. This is when I learned the Axzez carrier board doesn’t support this. I would need a “official” CM4 carrier board, so I ordered one. Don’t forget the proper 12vdc power supply to go with it. Important note to self – using a CM4 or CM5 likely means you’ll need a carrier board sitting around that you can manage firmware on.
While waiting for the carrier board, I decided to see if I could boot the CM4 in some way, then use dd to make the eMMC non-bootable. This worked but it was ugly. I was then able to boot off the USB thumb drive, and installed the Desktop image. The Desktop image seems pretty nice, but very simple. I decided to try installing gparted. The install appeared to work. gparted was now in the desktop menu, but it wouldn’t run. No idea why. Didn’t dig into it. I knew I could do the gparted things via command line. I decided to wipe and put a file system on the one drive I had installed in the case.
Once the carrier board arrived, I set up my Windows 11 laptop with rpiboot. Unfortunately the CM4 would not appear as a USB drive with this setup. The rpiboot app would see the CM4 start and it appeared to do the things it needed to do. The Windows disk manager would see the new storage, but something was preventing Windows from serving up the storage. More googling tells me I have to use rpiboot on something else. Some Linux-based system.
I didn’t want to repeat the pain of using the very slow Raspberry Pi 3. I also had a Raspberry Pi 4 (bought with the CM4). So I bought an Argon ONE M.2 case and a SSD drive stick. This was actually a pretty snappy Raspberry Pi 4 setup. Next I attempted to follow one of the several guides on using rpiboot on a Linux system. Step one is installing a USB library, and that’s immediately a problem on the new Pi 4. I keep getting some dependency error. I exhaust my google skills over 2 days trying to figure this out, then I decide to give Claude AI a try. My first real use of AI. I paste in the error from the Pi 4 and Claude starts walking me through things. Many were things I’d already done, like apt update and apt upgrade. When those ideas didn’t work, Claude said it would go deeper. There were instructions to delete a few files, then try the update and upgrade again. This time things worked. I was able to use rpiboot to update the firmware and boot order on the CM4.
I decided to try the OMV 7 thumb drive again, and this time it was easy to install over the Desktop image. A small win. OMV install number 2 seemed to go better. I still had some update issues that went away with time and/or reboots. I installed the 2nd 14TB drive. I wiped both drives again. I put ext4 on one of the drives, and was prompted to commit the configuration change. I thought this would go badly again, but it actually worked! I put ext4 on the 2nd drive without a problem.
Next I installed the mergerfs plug-in. This appeared to work, but when I clicked on the storage mergerfs menu button, I received an unknown webpage error. This was consistent. I removed the installed the plug-in again with the same result. Once again, I thought I was done with this experiment.
The next day, I was getting ready to start posting about my mergerfs problem. I logged into OMV so I could screen capture the error, and now things were working. I really don’t understand this behavior. I used mergerfs to merge both large drives. Now I’m doing some backup tests.
So what’s next? I’m not sure. I think I want to do some power measurements. I might buy an N100-based motherboard and repeat this just to see how it goes. My CM4 confidence is a little low because of some behavior issues I don’t understand. I see the V2 board has some indicator LEDs that I wish I had, because doing an OMV shutdown doesn’t really provide any visual indication that it’s safe to turn off the power.
