Live data from Hacker News

Building an ARM64 home server the hard way

jforberg.se

61–70 of 119 posts

Re: Building an ARM64 home server the hard way

#61
post #18

The hard way? Copy bootloader from somewhere, partition, extract readymade rootfs, setup bootloader, reboot. Sounds more like the Arch way . :) The only ARM specific thing here is probably the need to use a DTB. This just shows that manual Linux installation on random ARM board is not more complex than on x86_64. Perhaps even simpler, since you're just extracting a pre-made rootfs instead of using a package manager d…

Right? With that article title you figure the author had written his own bootloader in Typescript then transpiled to Rust, ultimately cross compiling to his Arm64 target from a homebrewed x86 CPU fabricated in his garage. For real though, what the author did is much harder than downloading and booting an official OS image from Pine. The article also documents all the successful steps and skips any missteps or debuggi…

Writing your own bootloader is an option if you want to play hard level, sure. I did follow that path, at one time https://xnux.eu/p-boot/ for another Pine64 device. ;)

Anyway, I didn't say the things you're criticizing my reply for.

Re: Building an ARM64 home server the hard way

#63
post #13

Somewhat 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.

Depending on what you use it for, you'll have to babysit your servers more and you'll not be able to do it on your own timeline.

Eg. if major postgresql update comes, you'll have to upgrade your DB cluster very soon. If major update to some program requires configuration changes, or if scripting language has deprecations that you've ignored for years, etc. you'll run into trouble, too.

I've been running a few Arch Linux servers for ~5 years and it's been quite pleasant. Being able to use the latest features in various programs or scripting languages is a very nice benefit.

Re: Building an ARM64 home server the hard way

#64

Earlier quoted context omitted.

If this was going to be used for some "big and serious" application, maybe different choices would have been made. Hopefully it was clear from the post that my goals here were the exact opposite! In my own anecdotal experience of running a hobby server on Arch for several years, I haven't experienced anything to make me think the distro is unsuitable for server work.

I've used debian for almost twenty years and arch for over half that, despite being comfortable with Arch, I would not sleep well at night if anything mission critical depended on it. You install a rig with Debian on it and touch nothing, it will last longer than you.

No, it will not last longer than you. If you want security updates, you have to do major ditro upgrades when the support for previous Debian release is over. And these are somewhat tricky.

You'll just have your upgrade dance clustered into a single event once every N years, instead of spread over randomly, based on major releases of SW your server depends on.

Re: Building an ARM64 home server the hard way

#66
post #23

You 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…

RK3399 is completely FOSS, from bootloader, to firmware, to Linux drivers and mainlined. It will be supported as long as someone wants to run software on it.

Re: Building an ARM64 home server the hard way

#67

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.

It's possible to just build the uptodate one. The support for rockpro64-rk3399 is mainline in U-Boot. The same for TF-A.

Re: Building an ARM64 home server the hard way

#68
post #62

Don't know how you missed that but Pine64 has official EU store: https://pine64eu.com/

I had to check, but ALL products in that store are "out of stock". This does not look like useful store at the moment.

Sure, I just wanted to mention that it exists, not making any claims about its usefulness. Yes, they are running out of stock on a regular basis, but they usually have re-stocking dates, so you know what to expect. Also their main store often is out of stock on many items as well. That's just how they operate.

Re: Building an ARM64 home server the hard way

#69
post #30

Earlier quoted context omitted.

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 stat…

One problem with opinionated builds of U-Boot is that you'll have more work figuring out what's enabled in its config. Configure and build your own if you want this kind of control.

Re: Building an ARM64 home server the hard way

#70
post #2

For the Pine family of SBCs I highly recommend installing Tow-Boot - https://tow-boot.org/ - on the SPI flash memory to allow yourself much better boot options, including booting directly from NVMe so you don't need to keep the MicroSD card plugged-in.

Does the U-boot in the SPI-NOR not support booting from NVMe? It might also be possible to patch that in from mainline if it exists. You can also often provide a “boot script” in the vfat partition that overrides the boot config in non volatile memory. This was something Freescale did with the i.MX6 that became a relatively standard thing for vendor-supplied U-boot.
Post reply on HN