Live data from Hacker News

Building an ARM64 home server the hard way

jforberg.se

101–110 of 119 posts

Re: Building an ARM64 home server the hard way

#101

Earlier quoted context omitted.

> The main issue: spamhaus block lists, they are hostile to all self-hosted people Allow me to correct that for you. There is nothing wrong with spamhaus. They provide one of the best anti-spam options amongst all the commercial providers. Spamhaus have many lists, I suspect the one you are referring to is the PBL, in their words "DNSBL database of end-user IP address ranges which should not be delivering unauthentic…

You're trying to argue sense with someone who thinks they can sue someone for greylisting, and is screeching about insecurities in GUI browsers and being "forced" to use an Apple or Google browser: > "If you want to make spamhaus remove your IP from their block list, you must engage in a chat working only with google/apple javascript browsers (I am a noscript/basic (x)html user)." Amazing that I've been on the intern…

> and never once had my shit jacked

Not that you know of, anyway.

Re: Building an ARM64 home server the hard way

#102

What's with arm sbc users not setting up any disk encryption? I have yet to see a guide / tutorial / experience reports that do not totally skip the subject.

Check this out, even has SSH unlock - https://gist.github.com/devgioele/e897c341b8d1c18d58b44ffe21...

I had setup mine with tiny-ssh because last time I checked dropbear only supported rsa keys.

My point was not that I was looking for a guide, but I have the feeling that subject is totally ignored by most of the sbc-arm community.

I take the risk of being victim of burglary as a when, not an if. I totally don't want anyone to have easy access to my data. If an SBC is used for server purpose and not for embedded/domotic use, it will likely contain data and/or secrets.

Re: Building an ARM64 home server the hard way

#103
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…

The tow-boot software devs goes out of the way to say they are offering a boring PC boot loader experience so I wouldn’t expect any advanced features other than booting from devices.

Re: Building an ARM64 home server the hard way

#104
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.

Run wathever on sd card on its most basic thing. Run lxc and mount storage on /var/lib/lxc.

Well… at least its what I’ve wish I could say.

Truth is I’m using manjaro (arch based) on a similar board and then one day after an upgrade they just decided to migrate from eth0 to the current naming scheme based on nic driver. Had to plug in a monitor and keyboard to fix the situation. Home stuff so its all good in my case.

Re: Building an ARM64 home server the hard way

#105
post #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 Li…

For pine stuff I had more issues with hardware than software. So in the end you’d still have to babysit a bit even if using fedora hat enterprise serious edition.

Re: Building an ARM64 home server the hard way

#107
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…

DTB = Device Tree Blob?

EDIT: Probably yes. I see this term appears in the article.

Re: Building an ARM64 home server the hard way

#108
post #97
post #5

Earlier quoted context omitted.

The beefier alternative you're looking for is possibly the Radxa Rock5B, which has proper M.2 slot and comes in a 16GB version. Hardware support for it isn't entirely mainlined yet, but a lot of development is happening week by week. Debian runs well on it.

Or any of the Rockhip 3588 boards. Better CPU, better PCIe, some have dual 2.5gbe, 4, 8 or 16gb ram, etc. I got the NanoPi R6s. Seems silly to save $25 on the slower CPU and half the ram.

The Rock5B is an RK3588 SBC, with up to 16GB RAM. Might not be the most "pimped" such.

Re: Building an ARM64 home server the hard way

#109
I tried the really hard way with a RK3288 (Asus TinkerBoard).

After about a month I had a barely working uboot built from unpatched official sources.

After two months I still didn't have a bootable kernel built from unpatched official sources.

- with power regulator drivers, the board powers itself off while booting

- without power regulator drivers, it boots the kernel, but there's no power to usb, ethernet and wifi.

What I learned: To stay away from Rockchip.

Post reply on HN