• Content Count

  • Joined

  • Last visited

  1. Hi, thanks for the hint. To be honest I don't get the content of the link, I mean referring to my question about the package dependency armbian-config and iptables. nft list ruleset (without any f2b-entry) is fine, it will be created with the first ban action.
  2. Just stumbled across something inconsistent after replacing iptables with nftables (the default on debian buster 10): A check with lynis gave me a warning about the "leftover" iptables package: -[ Lynis 2.7.5 Results ]- Warnings (2): ---------------------------- [...] ! iptables module(s) loaded, but no rules active [FIRE-4512] https://cisofy.com/lynis/controls/FIRE-4512/ Is this dependency necessary? aptitude purge iptables The following packages will be REMOVED: iptables{p} 0 packages upgraded, 0 newly installed, 1 to remove and 0 not upgraded. N
  3. In the meantime I found a workaround by inserting cat /etc/rc.local [...] systemctl restart nftables exit 0 Anyway, my first idea of a missing driver, is probably not correct: It doesn't explain the correct working restart of nftables.service, when the system is up. Regarding to your approach: raspian and cubox is different hardware, so will the comparison really be helpfull? cubox lshw -c network *-network:0 DISABLED description: Ethernet interface physical id: 3 logical name: dummy0 serial: 92:c8:2f:98:51:2c capa
  4. I just switched from iptables to netfilter. After a reboot I get this kind of status for the service systemctl status nftables ● nftables.service - nftables Loaded: loaded (/lib/systemd/system/nftables.service; enabled; vendor preset: enabled) Active: failed (Result: exit-code) since Fri 2019-07-12 16:04:59 CEST; 4min 28s ago Docs: man:nft(8) http://wiki.nftables.org Process: 287 ExecStart=/usr/sbin/nft -f /etc/nftables.conf (code=exited, status=3) Main PID: 287 (code=exited, status=3) Jul 12 16:04:59 cubox nft[287]: netlink.c:62: Unable to initialize Netlink
  5. I just stumbled across usr/src/linux-headers-4.19.20-cubox$ make scripts scripts/kconfig/conf --syncconfig Kconfig net/Kconfig:89: can't open file "net/wireguard/Kconfig" scripts/kconfig/Makefile:69: recipe for target 'syncconfig' failed make[2]: *** [syncconfig] Error 1 Makefile:539: recipe for target 'syncconfig' failed make[1]: *** [syncconfig] Error 2 Makefile:635: recipe for target 'include/config/auto.conf' failed make: *** [include/config/auto.conf] Error 2 Workaround was to comment this source-statement grep -i wireg net/Kconfig source "net/wireguard/Kconfig"
  6. I just checked, I reinstalled armbian-firmware yesterday to be sure. One idea: could I switch from armbian kernel to regular debian kernel and firmware for a test ?
  7. Ok, I don't use a self-compiled kernel. I am not sure if this helps to find the answer: I performed a /usr/src/linux-headers-4.14.70-cubox# grep -ir "lib/firmware" * drivers/media/dvb-frontends/Kconfig: or /lib/firmware (depending on configuration of firmware hotplug). drivers/media/dvb-frontends/Kconfig: or /lib/firmware (depending on configuration of firmware hotplug). drivers/media/dvb-frontends/Kconfig: or /lib/firmware (depending on configuration of firmware hotplug). drivers/media/dvb-frontends/Kconfig: or /lib/firmware (depending on configuration of firmware hotplug). d
  8. while checking the state of systemd I encountered systemctl is-system-running degraded with systemctl --state=failed UNIT LOAD ACTIVE SUB DESCRIPTION ● systemd-modules-load.service loaded failed failed Load Kernel Modules
  9. I just updated cubox-i and udoo as well to 4.4.71-* . Unfortunately no change armbian on udoo finds the usb-dac, on cubox it doesn't . Well, last year I already changed the cubox-i device due to a similar "failure". At that time I didn't run armbian but volumio and first for test purposes I switched to armbian. The new cubox worked by now and the dealer informed me later that even the complained first device seemed not broken from his point of view and asked me to check my environment. He tested just the usb-connectivity with a keyboard/mouse.
  10. but the udoo machine loads the driver after turning off/on of the dac: May 28 14:21:12 localhost kernel: usb 1-1.1: new high-speed USB device number 4 using ci_hdrc May 28 14:21:12 localhost kernel: input: McIntosh Laboratory McIntosh Labs USB Audio as /devices/soc0/soc/2100000.aips-bus/2184200.usb/ci_hdrc.1/usb1/1-1/1-1.1/1-1.1:1.2/0003:2349:03E8.0001/input/input0 May 28 14:21:12 localhost kernel: hid-generic 0003:2349:03E8.0001: input: USB HID v11.01 Device [McIntosh Laboratory McIntosh Labs USB Audio] on usb-ci_hdrc.1-1.1/input2 May 28 14:21:12 localhost kernel: usbcore: registered
  11. after a few reboots I got the same result (no dac deteted) on th udoo-board as well ;-) . So, it isn't any hardware that cause the problem.
  12. Hi, I run ARMBIAN 5.25 stable Debian GNU/Linux 8 (jessie) 4.9.12-cubox and use an external DAC connected to USB. Additionally and or comparison purposes I use ARMBIAN 5.25 stable Debian GNU/Linux 8 (jessie) 4.4.51-udoo . Since a few days the kernel on the cubox doesn't seem to recognize the USB-DACs as sound device any more. So, "aplay -l" doesn't list it: aplay -l **** List of PLAYBACK Hardware Devices **** card 0: SPDIF [Integrated SPDIF], device 0: S/PDIF PCM snd-soc-dummy-dai-0 [] Subdevices: 1/1 Subdevice #0: subdevice #0 A test with a udoo