• Content Count

  • Joined

  • Last visited

About ManoftheSea

  • Rank

Recent Profile Visitors

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

  1. I had hoped the information might be useful for bisecting which kernel update might be responsible. Is the source of the problem known and fixed, or is the fix being referenced only disabling the 5.85 release? Is it useful for me to search for the older nightlies and narrow it down?
  2. @barish, I was recently trying to debug a similar thing. Do you have "verbosity=1" in /boot/armbianEnv.txt? If so, you're telling the kernel not to log. I set mine to 7 based on a very poor understanding of things I read, and it gives me more log. If you already knew this, then maybe my message will help someone else sometime.
  3. I'm perhaps a little late in contributing to this thread, but after a power outage caused a reboot of mine, I was getting nothing in kernel log just after systemd started in kernel .40. I tried reverting kernel packages, and had failures with linux-image-next-mvebu64_5.83.190502_arm64.deb and linux-image-next-mvebu64_5.84.190508_arm64.deb, but success with .34 (that is, armbian 78.190409) No panic message, just a stop of logging to serial. This weekend, I will try the latest next again and capture the log, maybe someone might find it useful.
  4. I would suggest you look in /etc/systemd/network, at the 10-lan[01].network and files In them, apply a declaration to set the MAC address in the [link] section [Match] Name=lan0 [Link] MACAddress=0011.2233.4455
  5. hmm, that reminds me that I have a similar problem, when the system comes up, the wan port doesn't pull an address (ipv4 or ipv6) until I restart systemd-networkd. I think chrisf is on to something about timing.
  6. I feel like you would already know this, but, are you removing the ports from the bridge before you try to bond them? Can you share your config files for how you're trying to bond? With systemd-networkd?
  7. My numbers look very similar to yours. I'm using the 1000-1000 u-boot, and it looks like I'm doing about 6% better
  8. It appears boot.cmd, and the compiled (?) boot.scr are not installed/modified by packages. Therefore, you can set the current line that points to espressobin to your own dtb file, which is generated with my patch to switch the names. The existing espressobin DTB has a lot of patches in the armbian-build system. What I think I want, and maybe FlashBurn does too, is to take the final 3720-espressobin.dtb, build that for legacy users, and then patch it once more to create a 3720-espressobinv7.dtb. Then, we can modify our boot.cmd for our board variant. But I don't understand the kernel compilation and patching well enough to accomplish this on my own. Can I add a dtb that includes the existing one, and simply overwrites the &mdio node? Is there some existing mechanism in the Makefiles that would accomplish this? Lastly, assuming I do get a v7.dtb, I don't know where the file lists are for the debian package builds. So even though I think I've built an (incorrect at the moment) v7.dtb, it isn't being added to the linux-dtb-next-mvebu64 package.
  9. It was my understanding that the whole Topaz switch has only the 1 Gbps connection to the SOC, and that all three ethernet ports were from that switch. The labels for wan, lan0, and lan1 are just labels, on switch ports 1, 2, and 3.
  10. It turned out I had edited the "dev" config rather than the "next" config, also. Since then, I added #1252 which was accepted. However, it seems nothing's built since then. Is that my fault (some error in some log?) Is there somewhere I should look, to assist in fixing the problem? Is there some other reason builds aren't "daily" but are perhaps backlogged?
  11. I have an EspressoBINv7, I'm running Armbian 5.72 (Stretch) with kernel 4.19. It appears to be supported.
  12. If I'm understanding things correctly, the names of the ethernet ports on the espressobin come from the device tree - Specifically: port@1 { reg = <1>; label = "wan"; phy-handle = <&switch0phy0>; }; port@2 { reg = <2>; label = "lan0"; phy-handle = <&switch0phy1>; }; port@3 { reg = <3>; label = "lan1"; phy-handle = <&switch0phy2>; }; But the layout on the board actually has {[wan],[lan0]} {lan1}. A correction would relabel the ports that, I assume, others are using. Armbian's 5.70 image clumps them all together in br0, so new users will not be affected, but upgrades to the DTS would change the naming of ports, potentially catastrophically for users with an Espressobin firewall or in a remote location. Which is to say, I know how to solve the problem for me, but not how to do so for everyone.
  13. The "working board" is a debian stretch amd64 - my personal laptop, on 4.19. From comparing the configs, I have submitted pull request 1234 - However, the build system doesn't let Debian reach the kconfig menu to do it *right*. I will see if I can use the Docker instructions.
  14. Nothing found by that name From running the commands on a system that has a more complete build, the full list appears to be: nft_masq_ipv4 16384 1 nft_masq 16384 1 nft_masq_ipv4 nft_chain_nat_ipv4 16384 2 nf_nat_ipv4 16384 2 nft_chain_nat_ipv4,nft_masq_ipv4 nf_nat 36864 1 nf_nat_ipv4 nf_conntrack 163840 4 nf_nat,nf_nat_ipv4,nft_masq,nft_masq_ipv4 nf_defrag_ipv6 20480 1 nf_conntrack nf_defrag_ipv4 16384 1 nf_conntrack libcrc32c 16384 2 nf_conntrack,nf_nat Of these, my espressobin system has nf_nat_ipv4, but neither nft_{masq,chain_nat}_ipv4. The rest all load on espressobin "4.19.14-mvebu64 #5.70"
  15. Hello, short time reader and first time poster here. Love what you're doing. Got an Espressobin v7 on ARMBIAN 5.70 stable Debian GNU/Linux 9 (stretch) 4.19.14-mvebu64. First thing I discovered, my "wan" port is in the 2-port block with lan0, and lan1 is off by itself. Could someone direct me to where the driver assigns the names? It doesn't seem to be a udev rule. Second, I can't get systemd-networkd to get a dhcp-assigned address on "wan". Running dhclient works. Maybe that's not an Armbian specific issue. systemd says it's version 232. Last (for now), I tried to do ipv4 masquerading with nft. My guess is that some modules are missing from the build. iptables allowed me to apply the masquerade rule alright. I'll look into how to contribute a patch to build, but it may take me some time. I suggest I'm missing "nft_chain_nat_ipv4", but again if someone can tell me how to discover what modules are failing to load when I try to add the nft rule, I'll provide the feedback. Thank you in advance for any help