Smurfix

Members
  • Content Count

    12
  • Joined

  • Last visited

  1. Or maybe only some boards don't. Reports of people sending back 6 of 8 boards because they can't run 24h before going belly-up kindof point towards that cause.
  2. That doesn't look right. You can't use the same divider values for two different max frequencies.
  3. I suggest doing no such thing. Files in /lib don't belong to you and will be overwritten by the next random update of the package they belong to. Instead, copy this file to /etc/systemd/system/ and edit it there. Alternately, systemd has a well-documented mechanism to override things like ExecStartPre= entries.
  4. This may be a stupid question, but why would you do a daemon-reload if you're going to immediately reboot anyway? I
  5. There is no physical interface named "eth0" you could talk on. There are interfaces named "lan1", "lan0" and "wan". However, eth0 is what the CPU uses to multiplex these, so you need to set that to "up" too. I do it with this simple systemd-networkd rule: # cat /etc/systemd/network/49-switch.network [Match] Name=eth0 [Network] DHCP=no Then you can access the three real interfaces normally.
  6. Same here. Of three boards, one is used for routing and seems stable. The other two can't run an hour without ugly memory errors. Like, bash doesn't dynamically link because a symbol name got corrupted. "Reliably". OWCH. I was trying to run a database on that thing??
  7. If you use systemd-resolved, you need to disable resolvconf.
  8. What's wrong with systemctl mask NetworkManager.servce ?
  9. Ah. Found it. The package requires a "make scripts" to be executed in /usr/src/linux-headers-*, which should be done in postinst but isn't (or dies silently). Issue #830 filed.
  10. I do not want to know how to build my own kernel inside a virtualbox or whatever. I want the kernel packages thus built to be usable for everything they're supposed to be usable. This means that the generated kernel-headers package is required to contain a couple of binaries which are required to build new modules on the target. Specifically: /usr/src/linux-headers-4.14.2-mvebu64/scripts/basic/bin2c /usr/src/linux-headers-4.14.2-mvebu64/scripts/basic/fixdep /usr/src/linux-headers-4.14.2-mvebu64/scripts/mod/modpost need to be present for dkms (and other methods to build modules out of tree) to work.
  11. NB: Building modules on the target doesn't work because some programs in kernel_headers/scripts/simple and …/mod need to be compiled (for the target) and included in the kernel-headers package.
  12. The current -next version works for me. Lots of thanks, everybody. One problem, however: no CONFIG_REGULATOR_ARMADA3700 option in the kernel, hence (I assume) no cpufreq support. Which is not cool – literally, as some of the ICs get quite hot. Is it possible to change that? I'd be OK with lowering the frequency permanently at u-boot time.