legogris

The interface looks fully up, which makes me think it's actually working as intended and your problem lies elsewhere (network, DHCP server, cables, etc) Notice how it;s changed now as opposed to before

a tail of dmesg could be helpful too

and can you show the output of `ip a` after the first but before dhclient?

Just to make sure, you're still on 5.10 trying this, correct? Just checking since I saw you mentioning downgrading to 4.x in the hardkernel forum thread. I self-built buster on 5.10 (default current) and got it working with the above

This sounds similar to the issue where eth0 comes up during initramfs but fails to come up after startup. See if this solves it for you: ip link set eth0 down; sleep 1; rmmod realtek; sleep 1; modprobe realtek; sleep 1; ip link set eth0 up (And then do dhcp/add ip and routes) Most of that delay is probably unnecessary - I noticed it would sometimes fail without them but didn't bother to pinpoint exactly where and how long is necessary. If it does work, until the issue is solved upstream, you can add and enable this systemd unit to have it done on startup: [Unit] Description=Load Realtek drivers. Before=network-online.target [Service] Type=simple ExecStartPre=/usr/bin/sh -c '/sbin/rmmod realtek && sleep 1' ExecStart=/usr/sbin/modprobe realtek [Install] WantedBy=multi-user.target Separate but similar issue to https://superuser.com/questions/1520212/realtek-ethernet-not-working-after-kernel-update

Great step-by-step guide as an alternative to the build option, and also as a training/education for people less familiar with this in general I guess it should be safe to assume that if `CRYPTROOT_UNLOCK` works, so should this guide? `CRYPTROOT_ENABLE` confirmed working on: * OdroidC4 (current buster and bullseye tested) * OdroidHC4 (current buster tested; interactive prompt does not show at boot and seems to stop at "Starting Kernel..." but remote unlock over SSH still works. Additionally, eth0 will only come up again after boot if you issue `ip link set eth0 down; rmmod realtek; sleep 1; modprobe realtek; ip link set eth0 up` after boot) Thanks to people in IRC for figuring out the points for the hc4.

I don't know if this is related, but I just made a fresh build from current master for Odroid HC4. The networking works fine in initramfs (for cryptroot unlock) but after full boot I can't seem to get the interface up no matter what I try (it stays DOWN, no error messages or anything). e.g. ifconfig eth0 up, ip link set dev eth0 up, and then either static (ip a add) or dhclient, nothing. With or without NetworkManager. initramfs picks up dhcp fine, though. I'll try to rebuild a tagged release and see if anything changes (as this is working fine on my C4s built from an older commit)

> nmcli con mod "Wired connection 1" ipv4.addresses "192.168.2.64/24" ipv4.gateway "192.168.2.1" ipv4.dns "127.0.0.1,192.168.2.1" ipv4.dns-search "lan" ipv4.method "manual" This tells me you're still using NetworkManager - one option as tparys suggested is to configure that properly - but I'm thinking you probably don't need it anyway? Just do `systemctl disable NetworkManager.service` and it should get out of your way.

Did any of you choose a different keyboard layout than default at install perchance? Back 20+ years ago installing my first Linux machine I think I reinstalled more than 5 times until realizing that since I chose a Swedish keyboard at install, the same keypresses would result in different characters between installation and postinstallation. What if you try again and stay on en-us (or do installation and subsequent boots over SSH from the same host)?

bullseye works all right for me when built from master from Aug 6 (b0331a80c97a2f4072229a8c5fad1cac345d4a24). Have not tried other releases. Booting from MMC. A couple of oddities I noticed: No video output on HDMI on boot. This isn't an issue for me as I run them headless so I haven't looked more into it. I have not tried desktop. The boot partition is too small (this is with cryptroot enabled, though). Adding `BOOTSIZE=400` build parameter fixes that. You can probably get away fine with half of that, but I like to have some headroom in case I need to backup images etc in case of future troubleshooting. The hw MAC address gets overridden with a hardcoded one, which is annoying. No stability or performance issues so far. Reboots work fine. For the person(s) with htop issues: Can you run a parallell session with: `sudo dmesg > kernel.log` and post it here after a reboot when htop hangs it?

Never seen this before. Either way on your PostUp/PostDown hooks: If the connections routes properly without it, it shouldn't make any difference for performance with or without. It's just for setting up routing. It looks like the spaces are stripped out. Did you copy/paste it? Sanity check can be to retype manually to make sure it's not some weird unicode space characters that just look like normal spaces. Or try quoting the entire PostUp/PostDowns (even if it shouldn't be necessary) You should remove them from the client config (you can't do iptables on iOS) You can try adding KeepAlive = 25 or similar to ensure the tunnel stays up. MTU can make a difference depending on your network. Maybe check this also https://keremerkan.net/posts/wireguard-mtu-fixes/ The Arch WIki page on Wireguard is also a recommended read.

Specifically for media, it can also be worth considering bullseye (unless you have specific reasons to stay on kernel 4.x and/or need Python2). There are a lot of compatibility and bugfixes that aren't in buster (both in kernel and packages such as mesa). Of course you could also still install these on buster or Ubuntu via backports/build from source/external apt repos/ppas.

It's not a case of arm64 not being as well-supported. In general most modern software has way better support on arm64 than armf. If you're on a 64-bit processor, you can choose. HC2 will simply not do arm64 since it's a 32-bit processor. You can use either distro. I'd personally vouch for buster, or even bullseye. debian's testing is generally relatively stable in this phase of the lifecycle, and buster has old versions with known issues of some packages by now.

Yeah, mining is competitive enough today that you either need an edge (e.g. subsidized electricity) or spend a lot of time on optimization to do better than break-even. Especially true since some are even happy mining at a loss (e.g. circumventing currency regulation or money laundering). You could still look into staking, though - Ethereum is migrating away from PoW(mining) to PoS (staking) and there are already Tezos, Cardano, Cosmos and others. The good news is that a decent SBC or two should be good enough for that.

To answer my own question: For changing the MAC used by initramfs at boot, just change /boot/armbianEnv.txt