That uboot is pretty old, but not as old as the one on my armada 8040 boards... they can't even boot a modern kernel properly without having to compile uboot and ATF and upgrading the firmware.
Building an ARM64 home server the hard way
21–30 of 119 posts
Re: Building an ARM64 home server the hard way
#22> The total cost comes to around €350
A few weeks ago I bought an used intel nuc7 with a 7th gen core i5… for 150€.
It came with a 120gb ssd, 4gb ram and a power brick.
I still don’t see the value in this SBCs used as home servers.
Re: Building an ARM64 home server the hard way
#23You could do this for cheaper (and with more ram) using a raspberry pi 4 with a usb nvme ssd, it’s got gigabit ethernet and is arm64. Sure you have two less cores than this solution but it’s
more likely to be supported over time and once you get the SD card out of the mix the I/O is solid. I’ve been surprised by how much the SD card throughput was limiting the experience.
I run arch Linux arm on mine and it’s a fantastic little device. I wonder if these boards are way faster or just more of the same. I guess the pcie expansion makes this more extensible.
Re: Building an ARM64 home server the hard way
#24Somewhat tangential but is Arch really suitable for servers? Most Arch users I know still prefer Debian for servers. Yet I know at least one company that uses them for servers, which surprised me. I know the Arch breaking meme is overblown but for a server I'd still want something with less moving parts.
That big release upgrades provide more hassle than benifits was also observed by Google, hence they switched to rolling release. The reason Debian breaks more at release changes though is probably more due to them patching and modifying software, which they have sometimes have to change/drop with a new SW release. Or you have a hard time deploying a newer SW version on top of the old binaries. Arch follows upstream very close, which maybe increases the times things could/have to be reconfigured, but it still mostly means running vimdiff against config.conf and config.conf.pac{new,save}. Sure Debian is more reliable if you want do want to really change deployed systems, but if your company strategy is to keep up with upstream, Arch may work better than it's reputation.
And if you'd need stability once, you could just set Archive on a specific day as package mirror on your cache server.
Re: Building an ARM64 home server the hard way
#25> The total cost comes to around €350 A few weeks ago I bought an used intel nuc7 with a 7th gen core i5… for 150€. It came with a 120gb ssd, 4gb ram and a power brick. I still don’t see the value in this SBCs used as home servers.
The Lenovo "Tiny" machines are also cheap on eBay, even one with a Ryzen 5 and 8Gb RAM for ~$140USD.
Though there are reasons to specifically want an ARM64 machine for builds, etc.
Re: Building an ARM64 home server the hard way
#26Earlier quoted context omitted.
It’s a bit of a sledgehammer approach, but a Nuc with Proxmox is pretty excellent. You can even use 10gbe via thunderbolt (or the pci slot on the larger Nucs).
This is the way. An x86 NUC/Mini PC/Thin client smokes the ARM SBC market.
Are there any boxes without a graphics card or at least with a primitive one? So that they would be more economical in case you only need them for the role of a server?
Re: Building an ARM64 home server the hard way
#27Earlier quoted context omitted.
Does this have a mechanism for automatic redundant OS upgrades? I just built a Yocto-based distribution for a board based on rk3399, but the currently integrated U-Boot is not in the best state. This could be a great alternative if it really is a bit easier to integrate/build upon.
It's just a bootloader, with a few tricks up its sleeve. All it does is letting you boot from any storage medium you want (most notably NVMe) instead of being restricted to the hardcoded sequence of the boot ROM.
It is a bootloader bundled with the ARM64 firmware. That means you don't need to add the firmware to each OS that you might want to use so it is easier to switch between them.
Re: Building an ARM64 home server the hard way
#28You could do this for cheaper (and with more ram) using a raspberry pi 4 with a usb nvme ssd, it’s got gigabit ethernet and is arm64. Sure you have two less cores than this solution but it’s more likely to be supported over time and once you get the SD card out of the mix the I/O is solid. I’ve been surprised by how much the SD card throughput was limiting the experience. I run arch Linux arm on mine and it’s a fanta…
> "Looking at the available offerings [...]"
The slight problem with the deservedly often-recommended RP4 is that for most people it's so hard to come by it effectively doesn't exist.
Re: Building an ARM64 home server the hard way
#29Earlier quoted context omitted.
This is the way. An x86 NUC/Mini PC/Thin client smokes the ARM SBC market.
Are there any boxes without a graphics card or at least with a primitive one? So that they would be more economical in case you only need them for the role of a server?
Pretty much all of the small boxes just use the iGPU.
Re: Building an ARM64 home server the hard way
#30Earlier quoted context omitted.
Does this have a mechanism for automatic redundant OS upgrades? I just built a Yocto-based distribution for a board based on rk3399, but the currently integrated U-Boot is not in the best state. This could be a great alternative if it really is a bit easier to integrate/build upon.
It's just a bootloader, with a few tricks up its sleeve. All it does is letting you boot from any storage medium you want (most notably NVMe) instead of being restricted to the hardcoded sequence of the boot ROM.
I understand that part. What I'm talking about specifically is part of a bootloader, see for example this page in the documentation of SWUpdate: https://sbabic.github.io/swupdate/bootloader_interface.html
By adding communication between the OS and the bootloader it's possible to implement redundant updates for whole partitions (specifically A/B-updates with a boot counter). U-Boot supports this (depending on the state of the vendor-provided fork better or worse), and Tow-Boot seems to be based on U-Boot.