legogris

  • Content Count

    33
  • Joined

  • Last visited

About legogris

  • Rank
    Advanced Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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)?
  2. 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 i
  3. 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)
  4. 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.
  5. 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.
  6. 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.
  7. To answer my own question: For changing the MAC used by initramfs at boot, just change /boot/armbianEnv.txt
  8. 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.
  9. 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
  10. 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).
  11. I just use vanilla linux tools. To write image: $ dd if=image.img of=/dev/sda bs=4M status=progress && sync To verify sha1sum: $ head -c $(stat -c '%s' image.img) /dev/sda | sha1sum $ sha1sum image.img
  12. 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)
  13. @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.
  14. 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.
  15. 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