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

Flashing odroidc4 images, each installation gets an identical IP address of '00:50:43:84:fb:2f' as specified in https://github.com/armbian/build/blob/7d758026b57380b17b6337e23b053db01c7e0b3d/config/bootenv/meson.txt This gets especially cumbersome with encrypted rootfs. Is there any way to override this without having to rebuild the image? Ideally the hw MAC address would be used, but being able to configure it through a simple change of the boot parameters after flashing would also work.

So, this is how it works (and advance apologies if I misread the conversation and you're talking about something else): First off, if you want to talk semantics, sha1 is technically a cryptographic hash function, not a checksum algorithm. One could even argue that it's overkill for this use-case and that an algortithm made for checksums, such as CRC, is more appropriate (less secure but by far enough to detect random write or read errors, but more performant). The data on the card is read, bit-by-bit (well, on a lover level the reads are buffered for performance reasons, but it makes no practical difference otherwise). The data is then put through the sha1 hash function, which produces a 160-bit hash. A single bit being changed produces a completely different hash. The odds of the hashes matching up in case every single bit doesn't is 1 in ~10^18. For practical purposes, low enough odds to be practically impossible. When we're at those odds, you might as well start thinking about the probability that the read during your verification steps gives you the expected output due to a read error exactly matching the inverse of the write error during the write, RAM errors and cosmic radiation. If you're concerned about well-funded adversaries with a huge dedicated compute cluster deliberately giving you a fake image with the same matching hash, then you might want to look at more cryptographically secure hash functions - in which case replace the `sha1sum` command above with the slower but more secure `sha512sum` (512 bits, or 1 in 10^154). The chances of a collision are small enough that on average, with all the worlds current computing power, we'd be talking millions of years. The number of atoms in the entire universe is believed to be around 10^80. Pick two random atoms in the known universe and the odds of those being the same atom is still vastly higher than SHA-2 producing the same hash after a write error. TLDR; For your purposes, if the checksum validates, so does the written data (given that the checksum verification here is made between data read back from the written card vs the source file and not just between the source file and a website). Etcher did CRC32 until 2018, and is now on SHA512. Looking at the source, usbimager actually reads back the source and the target into memory and does a memcmp (straight-up byte-by-byte comparison): https://gitlab.com/bztsrc/usbimager/-/blob/master/src/main_libui.c#L147 These are all valid approaches, only caveat with the last one being that you need to be able to fit 2x the image size into RAM during the validation

Yes - if those two commands return the same output, it means the data in img file and on the sdcard have the same sha1 hash (and therefore contain the exact same bytes).

I just use vanilla linux tools. To write image: $ dd if=image.img of=/dev/sda bs=4M status=progress && sync To verify sha1sum of the data just written to the card: $ head -c $(stat -c '%s' image.img) /dev/sda | sha1sum $ sha1sum image.img

Awesome, thanks, I somehow missed that despite searching around! Maybe you want to put that in the top post :) (For anyone else: https://github.com/150balbes/Build-Armbian)

@balbes150 Have you, or do you have any plans to release the source (/config/resources and docs necessary to rebuild) for your images? It would be a game-changer if we could do reproducible builds, or at least compile ourselves.

Cool. Already placed an order last week but FriendlyELEC seems hit by coronavirus or something. 7 days now and zero communication despite reachouts over e-mail, forum PMs and phone calls. If it weren't for their track record and the lockdown in Guangzhou I'd just assumed I've been scammed. Thinking if I should do a chargeback or keep waiting :/ EDIT: What do you know, I just logged in on their webshop and the order was marked as shipped today, so I guess things are moving and they're just overwhelmed and low on english-speaking staff.

Nice perk of seeding: Since there is such a large number of torrents targeting individual boards and chipsets, sorting torrents by ratio give nice statistics on board popularity and trends. Can be helpful to see which boards to check out closer

Ok, cool. Was just thinking we may be a bunch of people with Gbit/s downlinks who will occupy bandwidth that'd be better serving those actually downloading releases for themselves and that it might be hard to get people to change it once they've deployed so better nip it in the bud so to speak. But I guess that's just premature optimization, so nvm

I don't really see what the users bandwidth has to do with this..? Initial seeders get hit equally hard by 100MBit/s downloads regardless of if that user is on a 100Mbit or 1Gbit/s connection?